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
{{ message }}
This repository was archived by the owner on May 20, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: docs/architecture/index.mdx
+89-86Lines changed: 89 additions & 86 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,22 +6,31 @@ description: "Learn about Nitric's architecture and how developers, operations t
6
6
7
7
Nitric allows your team to work together to build an application:
8
8
9
-
-**Developer**: Writes application code with built-in support for APIs, file storage (bucket), secrets, key/value store, and RDS, leveraging the Nitric SDK.
10
-
-**Operations**: Customize, extend or use Nitric's generated IaC (Terraform or Pulumi) to provision and manage the resources that the developer needs for their application.
11
-
-**SRE**: Configure environment/region/policy specific details, they also are heavily involved in overseeing that the Terraform modules themselves adhere to governance standards.
12
-
-**Nitric**: Automatically generates a specification for resource declarations and fulfills them by orchestrating a cloud deployment using IaC modules and container images tailored to the runtime requirements of the application code. While many examples focus on AWS as the target cloud, Nitric's flexibility allows providers to support any cloud environment or even multiple clouds simultaneously.
9
+
-**Developers**: Writes application code with built-in support for APIs, storage (bucket), secrets, key/value store, SQL databases and other cloud resources, leveraging the Nitric SDK.
10
+
-**Automation Engineers**: Customize, extend or use Nitric's generated IaC (Terraform or Pulumi) to provision and manage the resources needed to support applications.
11
+
-**Operations**: Configure environment/region/policy specific details, they also are heavily involved in overseeing that the Terraform, Pulumi or other IaC modules adhere to governance standards.
13
12
14
-
The roles above may overlap depending on your organization structure, for example, it is not abnormal for Developers to assume all roles, or for Operations and SRE responsibilities to be handled by the same team.
13
+
<Note>
14
+
These roles are only representative, they often overlap or further divide
15
+
depending on team structure. For example, it's not unusual in smaller teams
16
+
for Developers to assume all roles, or for Automation and Operations to be
17
+
handled by the same team.
18
+
</Note>
19
+
20
+
**Nitric** interacts with code to generate a specification of the resources required by each application. It then uses one or more IaC/cloud-specific plugins to turn those requirements into Infrastructure-as-Code (e.g. Terraform) or fully automate cloud deployments, which fully satisfy all of the applications infrastructure requirements. Effectively, Nitric is a cloud-agnostic way to define and deploy cloud applications, which automates the transition from code to cloud resources.
21
+
22
+
While many Nitric examples focus on AWS, Nitric's flexibility allows plugins (providers) to support any cloud or on-prem environment, even multiple clouds simultaneously if that's required.
- The **Client Browser** opens a WebSocket connection.
128
-
- The **WebSocket** handles the connection lifecycle:
129
-
- When the connection opens, it triggers the **onConnect** service.
130
-
- Once the connection is established, messages from the client trigger the **onMessage** service.
131
-
- When the connection closes, it triggers the **onDisconnect** service.
132
-
- The **onMessage**, **onConnect** and **onDisconnect** handlers:
138
+
- The **Client** opens a WebSocket connection.
139
+
- The **WebSocket API** handles the connection lifecycle:
140
+
- When the connection opens, it triggers the **onConnect** callback function.
141
+
- Once the connection is established, messages from the client trigger the **onMessage** callback function.
142
+
- When the connection closes, it triggers the **onDisconnect** callback function.
143
+
- The **onMessage**, **onConnect** and **onDisconnect** callbacks:
144
+
- Are contained within one or more Services, accepting events from the WebSocket API.
133
145
- Interact with other cloud resources e.g. Buckets, KeyValue stores and APIs.
134
146
135
147
## Example: Sharing resources
136
148
137
-
Deploy multiple APIs and other entrypoints into an application that can access shared resources.
149
+
Deploy multiple services, behind shared API Gateways and interact with other shared resources.
138
150
139
151
```mermaid
140
152
flowchart TD
141
153
%% Actors
142
-
Browser[Client Browser]
154
+
Client1[Alice]
155
+
Client2[Bob]
143
156
144
157
%% Nitric Application Containers (APIs)
145
-
API_Read[HTTP API - Read API Gateway]
146
-
API_Write[HTTP API - Write API Gateway]
147
-
148
-
Other[Other Resources]
158
+
Api[api.example.com]
149
159
150
160
%% Services for respective API routes
151
-
ReadService[GET Route]
152
-
WriteService[POST Route]
161
+
UserSrv[Orders Service]
162
+
AdminSrv[Orders Mgmt Service]
153
163
154
164
%% Backend Services / Resources
155
-
Bucket[AWS S3 Bucket]
156
-
RDS[AWS RDS/Aurora]
165
+
Bucket[Invoices Bucket]
157
166
158
167
%% Interactions from the client to each API
159
-
Browser -->|Sends HTTP Request| API_Read
160
-
Browser -->|Sends HTTP Request| API_Write
168
+
Client1 -->|HTTP Request| Api
169
+
Client2 -->|HTTP Request| Api
161
170
162
171
%% API triggers to their respective services
163
-
API_Read -->|Triggers Service| ReadService
164
-
API_Write -->|Triggers Service| WriteService
172
+
Api -->|GET: /orders| UserSrv
173
+
Api -->|PUT: /users/1/orders/2| AdminSrv
165
174
166
175
%% Common backend resource interactions from the read service
167
-
ReadService -->|Retrieves files| Bucket
168
-
ReadService -->|Queries data| RDS
176
+
UserSrv -->|Read| Bucket
169
177
170
178
%% Common backend resource interactions from the write service
171
-
WriteService -->|Uploads files| Bucket
172
-
WriteService -->|Updates data| RDS
173
-
WriteService -->Other
179
+
AdminSrv -->|Read/Write| Bucket
174
180
classDef default line-height:1;
175
181
classDef edgeLabel line-height:2;
176
182
```
177
183
178
-
-The **Client Browser**sends HTTP requests to the **API Gateways**.
179
-
-**API Gateways**and their respective service handlers are established with least privileges:
180
-
- The Read API Gateway invokes the GET Route Service, which is granted read-only permissions.
181
-
- The Write API Gateway invokes the POST Route Service, which is granted write-only permissions.
184
+
-**Client Browsers**send HTTP requests to a shared **API Gateway**, which routes requests to the appropriate service.
185
+
-The **API Gateway's** respective route handlers (services) are established with least privileges:
186
+
- The `Orders Service`, can be restricted to read-only permissions to the Invoices Bucket.
187
+
- The `Orders Management Service`, is instead granted both read and write permissions to the Invoices Bucket.
182
188
183
189
## Example: Multiple entry points
184
190
185
-
A Nitric application can have multiple entry points, such as an**HTTP API Gateway**, a **Scheduled Event**, and a **WebSocket API** all sharing the same resources.
191
+
A Nitric application can also have multiple entry points, such as multiple**HTTP API Gateways**and a **Schedule**, all sharing specific common resources.
186
192
187
193
```mermaid
188
194
flowchart TD
195
+
%% Actors
196
+
Client1[Alice]
197
+
Client2[Bob]
198
+
Schedule[Archive Orders]
189
199
190
-
Browser[Client Browser]
191
-
WSClient[WebSocket Client]
192
-
Scheduled[Scheduled Event]
193
-
194
-
API_Read[HTTP API - Read]
195
-
API_Write[HTTP API - Write]
196
-
WS_API[WebSocket API]
197
-
198
-
ReadService[GET Route]
199
-
WriteService[POST Route]
200
-
ScheduledJob[Scheduled Task]
201
-
202
-
Bucket[AWS S3 Bucket]
203
-
RDS[AWS RDS/Aurora]
204
-
Other[Other Shared Resources]
205
-
206
-
Browser -->|HTTP Request| API_Read
207
-
Browser -->|HTTP Request| API_Write
208
-
WSClient <-->|Bi-directional messages| WS_API
209
-
210
-
Scheduled -->|Triggers| ScheduledJob
200
+
%% Nitric Application Containers (APIs)
201
+
UserApi[public.api.example.com]
202
+
AdminApi[internal.api.example.com]
211
203
212
-
API_Read -->|Invokes| ReadService
213
-
API_Write -->|Invokes| WriteService
214
-
WS_API -->|Invokes| WriteService
215
-
WS_API -->|Invokes| ReadService
204
+
%% Services for respective API routes
205
+
UserSrv[Orders Service]
206
+
AdminSrv[Orders Mgmt Service]
207
+
ArchiveSrv[Archive Service]
216
208
217
-
ReadService -->|Query| Bucket
218
-
ReadService -->|Query| RDS
209
+
%% Backend Services / Resources
210
+
Bucket[Invoices Bucket]
211
+
Bucket2[Archive Bucket]
219
212
220
-
WriteService -->|Write/Upload| Bucket
221
-
WriteService -->|Create/Update| RDS
213
+
%% Interactions from the client to each API
214
+
Client1 -->|HTTP Request| UserApi
215
+
Client2 -->|HTTP Request| AdminApi
216
+
Schedule -->|3am daily| ArchiveSrv
222
217
223
-
ScheduledJob -->|Read| Bucket
224
-
ScheduledJob -->|Read/Query| RDS
225
-
ScheduledJob --> Other
218
+
%% API triggers to their respective services
219
+
UserApi -->|GET: /orders| UserSrv
220
+
AdminApi -->|PUT: /users/1/orders/2| AdminSrv
226
221
222
+
UserSrv -->|Read| Bucket
223
+
AdminSrv -->|Read/Write| Bucket
224
+
ArchiveSrv -->|Read/Delete| Bucket
225
+
ArchiveSrv -->|Write| Bucket2
227
226
classDef default line-height:1;
228
227
classDef edgeLabel line-height:2;
229
228
```
230
229
231
-
-**Backend resources** (e.g. Key/Value Store, Bucket, RDS) are shared and accessed with **least-privilege** access from each service.
230
+
-**Client Browsers** send HTTP requests to different **API Gateways**, which route requests to the appropriate service.
231
+
- The **API Gateway's** respective route handlers (services) are established with least privileges:
232
+
- The `Orders Service`, can be restricted to read-only permissions to the Invoices Bucket.
233
+
- The `Orders Management Service`, is instead granted both read and write permissions to the Invoices Bucket.
234
+
- A **Schedule** triggers the `Archive Service` to read and delete from the Invoices Bucket and write to the Archive Bucket.
0 commit comments