You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This guide outlines the strategy for deploying the API server to a production environment. The recommended method is to use Docker, which creates a portable and consistent container for your application.
8
+
This guide outlines the process for deploying the API server to a production environment. The server is built with Dart Frog and packaged as a Docker container, making it portable and easy to deploy to any hosting provider that supports Docker.
9
9
10
10
<Aside>
11
-
The world of cloud hosting and deployment tools evolves rapidly. Instead of providing specific commands that could become outdated, this guide focuses on the essential steps and links to the official documentation for the relevant services. This ensures you always have access to the most current and accurate instructions.
11
+
To ensure you have the most reliable and up-to-date instructions, this guide focuses on the project-specific configuration you need to complete. For the deployment itself, we will refer you to the excellent official documentation from the Dart Frog team, which is the definitive resource.
12
12
</Aside>
13
13
14
-
<Steps>
15
-
1.**Configure Production Environment Variables**
14
+
### Pre-Deployment Configuration
16
15
17
-
Your first step is to prepare the production configuration for the server. Unlike local development which uses a `.env` file, in production you will use your hosting provider's interface to set environment variables securely.
16
+
Before you can deploy, you must complete two essential configuration steps.
18
17
19
-
For a detailed explanation of each required variable, please see the [Configure Environment Variables](/docs/api-server/guides/configure-environment-variables) guide.
20
-
21
-
2.**Choose a Deployment Strategy**
18
+
<Steps>
19
+
1.**Configure Production Environment Variables**
22
20
23
-
The API server repository includes a `Dockerfile`, which allows for two main deployment strategies:
21
+
In your production environment, you will not use a `.env` file. Instead, you must configure the environment variables directly in your chosen hosting provider's interface. This is a critical step for security and proper configuration.
24
22
25
-
-**Deploying a Pre-built Image:** You build the Docker image on your local machine or in a CI/CD pipeline, push it to a container registry (like Docker Hub, Google Container Registry, or Amazon ECR), and then your hosting provider pulls the image from the registry.
26
-
-**Deploying from Source:** You connect your Git repository directly to the hosting provider, and it uses the `Dockerfile` to build and deploy the image for you.
23
+
For a detailed explanation of each required variable, please see the [**Configure Environment Variables Guide**](/docs/api-server/guides/configure-environment-variables).
27
24
28
-
3.**Deploy to a Hosting Provider**
25
+
2.**Configure CORS**
29
26
30
-
Choose a hosting provider that supports Docker container deployments. Popular and well-documented options include:
For the Web Dashboard to communicate with your API in production, you must correctly configure Cross-Origin Resource Sharing (CORS) by setting the `CORS_ALLOWED_ORIGIN` environment variable.
35
28
36
-
Follow the official documentation from your chosen provider to deploy your container. During the setup process, you will be prompted to configure the environment variables from Step 1.
29
+
For instructions, see the [**Configure CORS Guide**](/docs/api-server/guides/configure-cors).
30
+
</Steps>
37
31
38
-
4.**Configure CORS**
32
+
### Deployment with Dart Frog
39
33
40
-
For your web-based dashboard to communicate with the API in production, you must correctly configure Cross-Origin Resource Sharing (CORS).
34
+
Once your configuration is ready, you can proceed with the deployment. The Dart Frog documentation provides comprehensive guides for various hosting providers and deployment strategies (e.g., using Docker, deploying to Google Cloud Run, etc.).
41
35
42
-
For instructions, see the [Configure CORS](/docs/api-server/guides/configure-cors) guide.
36
+
Following the official documentation is the recommended and most reliable path to a successful deployment.
Copy file name to clipboardExpand all lines: src/content/docs/api-server/guides/implement-alternative-email-client.mdx
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,10 +13,10 @@ This guide demonstrates the value of this architecture by walking you through th
13
13
14
14
The core of this flexibility is the `EmailClient` abstract class, defined in the `email_client` package. Any email service you wish to use must have a corresponding class that implements this interface.
15
15
16
-
The contract is simple:
16
+
The contract, defined in the `email_client` package, is simple:
Let's create a simple "logging" email client that doesn't actually send emails but instead prints the details to the console. This is useful for local development or testing.
35
35
36
36
1.**Create the Implementation File:**
37
-
Create a new file, for example, `packages/email_logging/lib/src/email_logging.dart`.
37
+
You can create a new implementation anywhere, but for this example, let's assume you create a new local file for testing purposes.
38
38
39
39
2.**Implement the `EmailClient`:**
40
40
@@ -71,7 +71,7 @@ Let's create a simple "logging" email client that doesn't actually send emails b
71
71
72
72
Swapping the implementation is the easiest part. You only need to change a single part of the dependency injection setup.
73
73
74
-
Open the dependency configuration file: `apps/flutter-news-app-api-server-full-source-code/lib/src/config/app_dependencies.dart`.
74
+
Open the dependency configuration file within the API server project: `lib/src/config/app_dependencies.dart`.
This toolkit was not just built to work; it was architected to last. Every component, from the backend API to the mobile client, is built on a foundation of production-ready principles. Understanding this philosophy is key to appreciating the long-term value and maintainability of the source code you've acquired.
9
+
10
+
Our goal is to provide a codebase that is a pleasure to work with—one that you can confidently build upon, customize, and scale.
11
+
12
+
### The "Make it Right" Principle
13
+
14
+
Our guiding principle is to **default to production-ready patterns**, even when simpler alternatives exist. This prioritizes long-term code quality, testability, and maintainability over short-term implementation speed.
15
+
16
+
Key aspects of this principle include:
17
+
18
+
-**Dependency Injection:** We consistently use dependency injection (DI) throughout the toolkit. Services, repositories, and clients are injected rather than instantiated directly. This decouples our components, making them easy to test in isolation and simple to swap out. For example, the default SendGrid email client can be replaced with another provider by changing a single line in the DI container.
19
+
20
+
-**Immutability:** All data models and state classes are immutable. This leads to more predictable state management, eliminates a whole class of potential bugs related to side effects, and makes debugging easier.
21
+
22
+
-**Testability by Design:** The entire system is structured to be easily testable. With clear boundaries between layers and the use of DI, you can write targeted unit tests for business logic without needing to run the entire application. We mandate a high test coverage standard across all packages.
23
+
24
+
### A Clean, Layered Architecture
25
+
26
+
The toolkit follows a classic layered architecture, ensuring a clear separation of concerns. This structure is applied consistently across all applications.
27
+
28
+
1.**Data Layer (Clients):** The lowest layer, responsible for all communication with external sources (like the database or third-party APIs). It handles the raw data fetching and maps external errors to a set of standardized exceptions.
29
+
30
+
2.**Repository Layer:** This layer abstracts the data sources. It provides a clean, consistent API for the business logic layer to consume, without needing to know *how* or *where* the data is stored.
31
+
32
+
3.**Business Logic Layer (BLoC / Services):** This layer contains the core application logic. In the Flutter apps, this is implemented using the **BLoC pattern**. In the backend, it's handled by **Services**. This layer orchestrates data from repositories and enforces business rules.
33
+
34
+
4.**Presentation Layer (UI / Routes):** The top layer, responsible for presenting data to the user and capturing their input. In the Flutter apps, this is the widget tree. In the API server, these are the route handlers. This layer is kept as "dumb" as possible, reacting to state changes from the business logic layer.
35
+
36
+
<Aside>
37
+
This clean separation means you can change the UI without touching business logic, or swap a database without affecting the UI. This is the key to a maintainable and scalable application.
38
+
</Aside>
39
+
40
+
### Standardized and Predictable Code
41
+
42
+
-**Shared `core` Package:** A central `core` package contains all shared data models, enumerations, and a standardized set of `Exception` classes. This ensures that the mobile client, web dashboard, and API server all speak the same language.
43
+
44
+
-**Consistent Error Handling:** All errors are mapped to the standardized exceptions from the `core` package at the data layer. This means BLoCs and services can handle errors in a predictable way, regardless of their origin.
45
+
46
+
-**Strict Data Modeling:** All data models follow strict rules: they are immutable, use `camelCase` for JSON serialization, and forbid optional properties to prevent null-related errors.
47
+
48
+
By adhering to these principles, we've created a toolkit that is not only functional but also robust, testable, and ready for you to build your business on.
Once you have the ecosystem running locally, the next step is to deploy the components to production. These guides provide step-by-step instructions for preparing and deploying each part of the toolkit.
8
+
Once you have the toolkit running on your local machine, the next step is to go live. These guides provide clear, step-by-step instructions for preparing and deploying each component of the toolkit to a production environment.
9
9
10
10
<Steps>
11
11
1.**Deploy the API Server**
12
12
13
-
Learn how to configure and deploy the Dart Frog backend to a production server using Docker.
13
+
Learn how to configure and deploy the Dart Frog backend to a production server.
14
14
15
15
[Go to API Deployment Guide →](/docs/api-server/deployment/)
16
16
17
17
2.**Deploy the Web Dashboard**
18
18
19
-
Follow these steps to build and deploy the Flutter web dashboard to a static hosting provider.
19
+
Follow the steps to build and deploy the Flutter web dashboard to your preferred hosting provider.
20
20
21
21
[Go to Dashboard Deployment Guide →](/docs/web-dashboard/deployment/)
Welcome to the Flutter News App Full Source Code Toolkit. This is more than just an app template; it's a complete, three-part toolkit designed to work seamlessly together, giving you everything you need to launch, manage, and scale a modern news application from a solid, well-architected foundation.
24
24
25
-
Welcome to the Flutter News App Full Source Code Toolkit. This is more than just an app template; it's a complete, three-part ecosystem designed to work seamlessly together, giving you everything you need to launch, manage, and scale a modern news application.
25
+
<divid="toolkit-components">
26
+
### The Toolkit Components
27
+
</div>
26
28
27
29
<CardGrid>
28
30
<Cardtitle="Mobile Client App"icon="phone">
@@ -46,7 +48,7 @@ Welcome to the Flutter News App Full Source Code Toolkit. This is more than just
The **API Server** is the central brain. Both the **Mobile Client** and the **Web Dashboard** communicate with it to fetch data, authenticate users, and retrieve configuration. The **Web Dashboard** is used to populate the content that the **Mobile Client** displays.
106
+
107
+
This separation of concerns makes the toolkit robust and flexible. You can manage your entire platform from the web and deliver updates to your mobile users instantly.
108
+
109
+
## Get Started: Try, Evaluate, and Launch
110
+
111
+
This toolkit is source-available, allowing you to explore the code and ensure it meets your standards before making a commitment.
102
112
103
113
<CardGrid>
104
-
<Cardtitle="Start Your 32-Day Trial"icon="laptop">
114
+
<Cardtitle="Start Your Free Trial"icon="laptop">
105
115
Download the complete source code and run the entire system on your local
106
-
machine. The trial license allows for a full evaluation of the project's
107
-
quality and features for 32 days.
116
+
machine. The PolyForm Free Trial license allows for a full evaluation of the project's
117
+
quality and features.
108
118
<divstyle={{ marginTop: '1.5rem' }}>
109
-
<LinkButtonhref="/docs/getting-started/">Begin Local Setup</LinkButton>
119
+
<LinkButtonhref="/docs/local-setup/">Begin Local Setup</LinkButton>
110
120
</div>
111
121
</Card>
112
122
<Cardtitle="Purchase a Lifetime License"icon="rocket">
113
-
A one-time purchase grants you a lifetime commercial license to build,
123
+
Ready to go live? A one-time purchase grants you a lifetime commercial license to build,
114
124
customize, and deploy unlimited applications, complete with lifetime
0 commit comments