Storage (Buckets/Object Storage)

1. System Context

Developers use Nitric to define required buckets within their application.

  • App code uses the Bucket resource from the Nitric SDK.
  • Developers define buckets their application requires and implement logic to securely store/retrieve/delete files.
  • Developers request the level of access they require for the bucket in their application logic e.g. read, write, delete.
  • Developers can implement handlers for file change events such as write or delete.

Operations use default or overridden IaC (e.g Terraform modules) to provision the necessary resources for their target cloud.

Example AWS Provider
  • AWS S3 serves as the storage backend.
  • AWS Lambda functions are used to process events triggered by S3.
  • AWS IAM provides roles and policies for secure access to S3 buckets and Lambda functions, enforcing least privilege access based on the developers request.
Code
Terraform
Create S3 Bucket
Configure Notifications
Allow Lambda Invocation
Store/Retrieve Data/Trigger onEvents
Provide Access
Developer
Operations
nitric up
AWS S3 Bucket
AWS Lambda Functions
AWS IAM
Example GCP Provider
  • Google Cloud Storage serves as the storage backend.
  • Google Cloud Pub/Sub is used to publish events triggered by Cloud Storage notifications.
  • Google IAM provides roles and policies for secure access to Cloud Storage buckets and Pub/Sub topics, enforcing least privilege access based on the developer's request.
Code
Terraform
Create Storage Bucket
Configure Notifications
Allow Pub/Sub Publishing
Publish Events
Deliver Notifications
Provide Access
Store/Retrieve Data/Trigger onEvents
Developer
Operations
nitric up
Google Cloud Storage Bucket
Google Pub/Sub Topic
Google Pub/Sub Subscription
Google IAM
AWS Lambda Functions

2. Sequence

Build Sequence

Below is a sequence diagram showing the sequence of events that occur when a developer registers a bucket with Nitric. Including, optionally registering event handlers for file change events.

App Worker(s)Nitric SDKNitric CLINitric ProviderIaCopt[Notifications]opt[Notifications]Register BucketRegister BucketRegister Event CallbackRegister Event HandlerForward Nitric SpecProvision BucketProvision Event Rule(s)App Worker(s)Nitric SDKNitric CLINitric ProviderIaC

Runtime Sequence

Below is a sequence diagram showing the runtime flow of a storage operation in a Nitric application, using the Nitric SDK. The SDK forwards the request to the Nitric runtime, which converts the request and forwards it to the cloud storage API. The plugin nature of the Nitric runtime allows for seamless integration with different cloud providers.

App CodeNitric SDKNitric RuntimeCloud Storage (e.g. S3)ReadForward RequestConvert RequestStorage API RequestApp CodeNitric SDKNitric RuntimeCloud Storage (e.g. S3)

3. Component

Bucket Module

  • Ensures storage buckets have unique names by appending a randomly generated identifier. This avoids naming conflicts and aligns with best practices for globally accessible cloud resources.
  • Supports the addition of metadata tags for resource identification, management, and tracking, enabling better governance.
  • Configures storage bucket notifications to trigger functions or message queues based on specified events (e.g., object update or deletion).
  • Implements least privilege access by only assigning requested permissions to functions or services that interact with the storage bucket.
  • Uses templates or dynamic blocks to handle multiple notification targets, allowing scalability and flexibility for different workflows.

4. Code

Developers write application code that uses the Bucket resource from the SDK, configures the bucket, and implements the application logic to read, write and delete files.

SDK Reference by language -

Operations will use or extend the Nitric Terraform reference modules:

Edit this page on GitHub
Last updated on Feb 10, 2025