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.
description="Build cloud backends that run anywhere, fast."
13
13
/>
14
14
15
+
---
16
+
15
17
Nitric is a cloud framework with common resources like APIs, websockets, databases, queues, topics, buckets, and more.
16
18
17
19
However, Nitric is unique - it doesn't just deploy the resources, it helps you interact with them. It also makes them pluggable, so you can swap services or even whole clouds without changing your code.
@@ -24,6 +26,8 @@ Oh, and it supports basically any language, like JavaScript, TypeScript, Python,
24
26
<Librariesminimal />
25
27
</div>
26
28
29
+
---
30
+
27
31
## Services
28
32
29
33
Services are the heart of Nitric apps, they're the entrypoints to your code. They can serve as APIs, websockets, schedule handlers, subscribers and a lot more. You create services by telling Nitric where to look for your code and how to run it.
@@ -37,6 +41,8 @@ services:
37
41
38
42
You might have one service that handles everything, or a service for each route. It's up to you.
39
43
44
+
---
45
+
40
46
## Resources
41
47
42
48
Resources are the building blocks of your apps. They're the databases, queues, buckets, etc. that your services interact with. If you want a resource, you just ask for it.
@@ -94,6 +100,8 @@ Nitric collects everything your services request. When you deploy, the deploymen
94
100
That probably sounds like magic, but it's more like a compiler for Infrastructure-as-Code - you can read about it in the [Concepts](/docs/concepts) section.
95
101
</Note>
96
102
103
+
---
104
+
97
105
## Providers
98
106
99
107
Nitric is designed to be independent of any platform, so you can run your apps anywhere. You can deploy to AWS, Azure, GCP, or even your own Kubernetes cluster. You can even deploy to multiple clouds at once.
We have a few providers built-in with IaC from Pulumi or Terraform, but you can build your own with any tools you prefer and to anywhere you want.
140
148
149
+
---
150
+
141
151
## Projects
142
152
143
153
Projects built with Nitric don't have many restrictions. You can use most languages, most libraries, most tools, most clouds, most services, mostly anything you like. But, you need to have a `nitric.yaml` file in the root of your project.
@@ -196,6 +206,8 @@ example/
196
206
197
207
</CodeGroup>
198
208
209
+
---
210
+
199
211
## CLI
200
212
201
213
Nitric has a CLI to help you create, manage, run and deploy your projects. We recommend installing it with a package manager:
@@ -259,19 +271,97 @@ You can tear down your project with the `down` command.
259
271
nitric down
260
272
```
261
273
262
-
## Dashboard
274
+
---
263
275
264
-
Nitric has a local Dashboard UI (hosted by the CLI) to help you interact with your resources. You can typically access it at [http://localhost:49152](http://localhost:49152/) after running `nitric start` or `nitric run`.
276
+
## Local development
277
+
278
+
Sometimes you just want to run your app locally and we let you do just that. And we don't mean "binds to a cloud environment and syncs your code, but doesn't work without Wifi" local, we mean "runs on your machine, on a desert island" local.
279
+
280
+
`nitric start` hosts entrypoints like APIs, websockets, and schedules, as well as resources like databases, topics, queues, key/value stores and buckets.
281
+
282
+
It also provides a Dashboard to interact with your resources, so you can trigger schedules without waiting, or topics without a publisher, or upload test files to a bucket. It even produces a real-time architecture diagram of your services and resources.
alt="screen shot of the local development dashboard"
270
288
/>
271
289
272
-
## Extension
290
+
---
291
+
292
+
## Extension & Escape Hatches
293
+
294
+
The services of cloud providers are vast, we can't cover everything and we shouldn't. Many services are unique enough that abstraction would be a disservice. Nitric aims to make common "table stakes" services easy to use, but we never want to limit you.
295
+
296
+
### Runtime
297
+
298
+
If you need to access a service in a way Nitric doesn't support, you can always use the provider's SDK directly. Code like this will always work:
final response = await s3.listObjectsV2(Bucket: 'my-bucket');
340
+
341
+
print(response.contents);
342
+
```
343
+
344
+
</CodeGroup>
345
+
346
+
### Overriding
347
+
348
+
If you need to change how Nitric deploys a resources or how it interacts with a service at runtime, you can [extend or modify a provider](/reference/providers/custom/extend-standard-provider).
349
+
350
+
<Note>
351
+
For example, here's a [project that swaps SNS for EventBridge](https://github.com/jyecusch/iac-ifc-comparison) on AWS.
352
+
</Note>
353
+
354
+
### Full Customization
355
+
356
+
If you need to deploy to a cloud or new set of services that Nitric doesn't support, you can [build your own provider](/reference/providers/custom/building-custom-provider). This is a bit more advanced, but it's the ultimate escape hatch.
357
+
358
+
The included providers are written in Go and built using Terraform or Pulumi, but you can use any language or tool you like.
359
+
360
+
### Additional Resources
361
+
362
+
If you need to use a service that Nitric doesn't support, you just do that like you always would. Nitric doesn't get in the way of you using the cloud, it just makes it easier.
0 commit comments