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/further-reading/how-devs-use-nitric.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ Projects can have as many service files as desired, and each one will map to a c
14
14
15
15
The Nitric SDK offers a comprehensive set of tools, including handlers for events/topics, queues, storage, key-value (KV) stores, schedules, APIs and secrets. These components are the essential building blocks for building cloud applications.
16
16
17
-
SDKs communicate with the Nitric Server using gRPC and Protocol Buffers, which enables the framework to support [many languages](/reference/languages). Resources defined in the SDK do not require low-level configuration, which means that application code will never contain parameters or annotations for config, such as the replication policies for data stores. This fine-grained control is handled by [Providers](/foundations/deployment/providers), which are described in the Ops workflow.
17
+
SDKs communicate with the Nitric Server using gRPC and Protocol Buffers, which enables the framework to support [many languages](/reference/languages). Resources defined in the SDK do not require low-level configuration, which means that application code will never contain parameters or annotations for config, such as the replication policies for data stores. This fine-grained control is handled by [Providers](/foundations/deployment#providers), which are described in the Ops workflow.
@@ -4,17 +4,18 @@ description: Nitric allows applications to declare infrastructure requirements a
4
4
5
5
# Infrastructure
6
6
7
-
Infrastructure from Code (IfC) is an extension of Infrastructure as Code (IaC) that takes runtime application code into consideration and enhances Separation of Concerns (SoC).
7
+
If you haven't read [Why Nitric](/get-started/foundations/why-nitric) yet, you might want to start there. It explains the 'why' behind Nitric, which can help you understand the 'what' and 'how' of Nitric.
8
+
9
+
Nitric applies the concept of Infrastructure from Code (IfC) in a very specific way, to enhance Infrastructure as Code (IaC) and help applications with platform specific Separation of Concerns (SoC).
8
10
9
11
<Note>
10
-
Several products describe themselves as "Infrastructure from Code" (IfC), but
11
-
they're not all like Nitric. Many are platforms/SaaS products, not a
12
-
framework. Those products have different benefits and trade-offs.
12
+
"Infrastructure from Code" (IfC) is an emerging term and sometimes refers to
13
+
proprietary platforms/SaaS products. Instead, Nitric is an open source
14
+
application framework, that integrates with existing IaC tools, to automate
15
+
the creation of infrastructure from application code.
13
16
</Note>
14
17
15
-
Nitric's Infrastructure from Code (IfC) automates the creation of infrastructure from your application code, ensuring a clear separation between application logic and deployment concerns.
16
-
17
-
It abstracts the infrastructure layer, allowing developers to define what their application needs without getting bogged down in the specifics of cloud services or infrastructure configurations.
18
+
Nitric separates platform-specific cloud and infrastructure interaction away from core application code, while allowing developers to define their application's requirement explicitly.
18
19
19
20
Sometimes it's easier to explain IfC by exploring the benefits.
20
21
@@ -28,41 +29,201 @@ Nitric significantly reduces or removes cloud-specific code. For example, access
28
29
29
30
<TabItemlabel="Nitric SDK">
30
31
31
-
```javascript
32
+
This code works equally with AWS S3, Google Cloud Storage, Azure Blob Storage, or any other storage service:
final client = S3(region: 'us-west-2'); // Adjust region
215
+
final request = GetObjectRequest(
216
+
bucket: receiptDocumentsBucket!,
217
+
key: filename,
218
+
);
219
+
220
+
final response = await client.getObject(request);
221
+
return await response.body.toBytes();
222
+
}
223
+
```
224
+
225
+
</CodeSwitcher>
226
+
66
227
</TabItem>
67
228
68
229
</Tabs>
@@ -75,7 +236,9 @@ Nitric keeps application code independent of specific cloud services. Developers
75
236
76
237
For example this same code would work equally well backed by AWS SNS, AWS EventBridge, Google Cloud Pub/Sub, Azure EventGrid, Apache Kafka, or any other messaging service:
Using Infrastructure as Code (IaC) tools like Terraform, Pulumi, or AWS CDK, developers can define the infrastructure requirements for their application. You can even create reusable modules for common infrastructure patterns. For example, you could create a pattern for async messaging, which includes a topic, and a subscription bound to a compute function.
354
+
Using Infrastructure as Code (IaC) tools like Terraform, Pulumi, or AWS CDK, developers can define the infrastructure requirements for their application. You can even create reusable modules for common infrastructure patterns. For example, you could create a pattern for async messaging, which includes a topic, and a subscription bound to a serverless function.
140
355
141
356
The problem is that these tools in isolation require manual processes to keep the infrastructure in sync with the application code. Processes that are error-prone and time-consuming.
142
357
@@ -150,9 +365,11 @@ If you want to see the spec for your application you can run `nitric spec`:
150
365
nitric spec
151
366
```
152
367
368
+
This spec can be automatically forwarded to plugins that generate the IaC configuration and implement a runtime API adapter the chosen services. This way, the IaC configuration is always in sync with the application code and the code always works on the target platform.
369
+
153
370
### No Rogue Resources or Permissions
154
371
155
-
Resources and access requirements are defined as close as possible to where they're used - so it's easy to see when they're no longer needed or permissions are too broad.
372
+
Resources and access requirements are defined as close as possible to where they are used, making it easy to see when they are no longer needed or when permissions are too broad.
156
373
157
374
```javascript
158
375
import { queue } from '@nitric/sdk'
@@ -174,10 +391,50 @@ The name of a resource is defined **_once_** (in the code), instead of twice (in
174
391
sql('profiles')
175
392
```
176
393
177
-
and the framework maps the requirements specification to plugins written with existing IaC tools. These tools are still responsible for provisioning the resources, roles, and permissions.
394
+
Nitric maps the requirements specification to plugins written with existing IaC tools like Terraform, Pulumi or CloudFormation. These tools are still responsible for provisioning the resources, roles, and permissions, those things are never directly embedded in the application code.
178
395
179
396
### Don't Change App Code for Infrastructure Changes
180
397
181
-
You haven't imported the AWS SDK, Google Cloud SDK, or Azure SDK. You haven't written any cloud-specific code. You haven't written any mocks or tests for these cloud services, or anything that makes your code less portable.
398
+
At this point you haven't imported the AWS, Google Cloud, or Azure SDK. You haven't written any cloud-specific code in your application. You haven't written any mocks or tests for these cloud services, or anything that makes your code less portable.
399
+
400
+
So when changes are needed for performance, cost, or compliance, you can make them instantly. Like we mentioned before, that part is just config.
0 commit comments