Infrastructure

If you haven't read 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.

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).

Nitric separates platform-specific cloud and infrastructure interaction away from core application code, while allowing developers to define their application's requirement explicitly.

Sometimes it's easier to explain IfC by exploring the benefits.

Rapid Development

Nitric significantly reduces or removes cloud-specific code. For example, accessing a file in a cloud storage bucket with Nitric is just a few lines of code, while the equivalent code using cloud provider SDKs is much more verbose and error prone:

import { bucket } from '@nitric/sdk'

const receiptDocs = bucket('receipt-docs').allow('read')

export async function getReceiptDoc(filename) {
  return await receiptDocs.file(filename).read()
}

Decoupled Applications and Infrastructure

Nitric keeps application code independent of specific cloud services. Developers focus on designing the application architecture and building features, without first making long-term technology choices.

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:

import { topic } from '@nitric/sdk'

const myTopic = topic('my-topic').allow('publish')

export const publishMessage = async (message) => {
  await myTopic.publish(message)
}

We can change the underlying messaging service through a simple configuration change—which plugin to use, without modifying the application code.

provider: nitric/aws@1.1.1

Automate Application Infrastructure Requirements

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.

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.

Infrastructure lingers in production that's no longer in use, permissions are too broad creating security risks, or too strict causing application failures. Environment variables used to determine resource names can be can be broken by a simple typo. It's a mess.

Nitric solves this by automatically generating a requirements specification from the application code. This specification describes the resources used by the application, their hierarchy, and how the application intends to use them at runtime.

If you want to see the spec for your application you can run nitric spec:

nitric spec

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.

No Rogue Resources or Permissions

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.

import { queue } from '@nitric/sdk'

// Delete this line and the queue disappears from the IaC
const myQueue = queue('my-queue').allow('enqueue')

// It's easy to tell when `enqueue` is no longer needed
export const enqueueMessage = async (message) => {
  await myQueue.enqueue(message)
}

No Broken Environment Variables

The name of a resource is defined once (in the code), instead of twice (in the code and the IaC). IaC configuration is generated, so it's never out of sync with the application code.

sql('profiles')

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.

Don't Change App Code for Infrastructure Changes

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.

So when changes are needed for performance, cost, or compliance, you can make them instantly. Like we mentioned before, that part is just config.

provider: nitric/aws@1.1.1

nitric up