DOCSEARCHbyAlgolia
Submit Docs

Nitric Framework

repository·main·Indexed 11 days ago

https://github.com/nitrictech/nitric

A multi-language framework for 'infrastructure from code' that allows developers to declare infrastructure requirements like databases, buckets, and APIs directly in application code. Nitric automatically orchestrates and deploys these resources across cloud providers including AWS, GCP, and Azure using tools like Pulumi and Terraform.

Tokens
384.9K
Snippets
1.3K
Records
1.6K
Agent score
79%

What's inside Nitric

  3. Overview of the Nitric Python SDK

    main
    The Nitric Python SDK allows developers to define and interact with cloud resources and build application logic, such as services and handlers, within a Python environment. It abstracts the underlying cloud infrastructure, allowing you to write code that is portable across different cloud providers.

  4. Key benefits of using Nitric

    main

    Nitric provides several core advantages for cloud-native application development:

    • Developer-Centric Workflow: Focus on what infrastructure is needed rather than how to deploy it. Declarations in your code drive the automation.
    • Explicit Requirements: Turns implicit dependencies (like an S3 bucket access) into explicit declarations, automating provisioning and permission configuration.
    • Cloud-Agnostic Portability: Decouples application logic from specific cloud providers (AWS, Azure, GCP, or Kubernetes). You can map requirements to different services without changing your application code.
    • Automated Best Practices: Automates security policies and configurations (e.g., least privilege access) via platform-specific plugins, reducing misconfiguration risks.
    • Reduced Boilerplate: Eliminates the need to write and maintain extensive IaC scaffolding, allowing more focus on application logic.
    • Plugin-Based Architecture: Uses a plugin system that can leverage existing tools like Pulumi or Terraform, or allow for custom provider implementations.

  5. What is a Nitric project?

    main

    A Nitric project is a collection of services, resources, and configurations that constitute your application. Projects are lightweight and flexible, allowing you to structure them according to your needs (e.g., monoliths or microservices).

    To define a project, you must include a nitric.yaml file at the root. This file identifies the project name and specifies the entrypoints (services) that handle API routes, scheduled events, async message subscriptions, or batch workloads.

  6. What is a Nitric service?

    main

    In Nitric, a service is the core deployable unit of code. It is typically a single container image that can be deployed to various cloud compute resources, such as serverless functions (e.g., AWS Lambda, Google Cloud Run), long-running containers, or VMs.

    Key characteristics:

    • Language Agnostic: Services can be written in any language that can be compiled into a container image.
    • Core Building Block: Services are responsible for handling API requests, processing messages, and executing tasks. Most other Nitric resources are declared by or interact with services.
    • Composition: An application can consist of a single service or multiple services (potentially written in different languages) working together.

  7. How Nitric Topics are deployed to Azure

    main

    When you use Nitric Topics with Azure, Nitric leverages Azure Event Grid to manage message routing.

    During the deployment process, the Nitric CLI performs the following actions:

    1. Infrastructure Provisioning: Creates Event Grid Topics based on your Topic definitions.
    2. Containerization: Builds your subscriber services into container images.
    3. Image Registry: Pushes these images to an Azure Container Registry (ACR) as private images.
    4. Compute Setup: Configures Azure Container Apps to run your subscriber containers.
    5. Event Routing: Sets up Event Grid Subscriptions so that the Container Apps receive messages from the defined Topics.

  8. Implement a Topic-based Research Pipeline with Nitric Topics

    main

    To build an iterative research pipeline, use Nitric topic and bucket abstractions. You can define a topic to handle different stages of the research process as asynchronous messages.

    In the implementation:

    1. Subscribe to the topic to listen for different message types (e.g., create_query, query, summarize, reflect).
    2. Publish new messages to the topic to move the pipeline to the next stage (e.g., after summarizing, publish a reflect message).
    3. Use a Bucket to store the final synthesized research report once the iteration limit is reached or no more knowledge gaps are found.

    Example message types for the pipeline:

    • create_query: Initiates the research for a topic.
    • query: Triggers the search engine.
    • summarize: Processes search results into a summary.
    • reflect: Analyzes the summary to decide if more research is needed.
    import { api, topic, bucket } from '@nitric/sdk'

const researchApi = api('research')
const researchTopic = topic<TopicMessages>('research')
const researchTopicPub = researchTopic.allow('publish')
const researchBucket = bucket('research').allow('write')

// Subscribe to handle the pipeline stages
researchTopic.subscribe(async (ctx) => {
  const message = ctx.req.json()
  switch (message.type) {
    case 'create_query':
      await handleCreateQuery(message)
      break
    // ... other cases
  }
})

// Trigger the start of the pipeline via an API endpoint
researchApi.post('/query', async (ctx) => {
  const query = ctx.req.text()
  await researchTopicPub.publish({
    type: 'create_query',
    originalTopic: query,
    // ... other initial state
  })
  ctx.res.body = 'Query submitted'
  return ctx
})

  9. Define cloud resources in Nitric

    main

    Nitric allows you to define cloud resources (APIs, Jobs, Buckets, Topics) in your code. These definitions act as the blueprint for the infrastructure Nitric will provision.

    Common resource types include:

    • api(name): Defines an HTTP API endpoint.
    • job(name): Defines a batch job for asynchronous processing.
    • bucket(name): Defines a storage bucket.
    • topic(name): Defines a Pub/Sub topic for asynchronous messaging.

    Example resource definitions in common/resources.py:

    from nitric.resources import api, bucket, job, topic

main_api = api("main")
gen_audio_job = job("audio")
clips_bucket = bucket("clips")
models_bucket = bucket("models")
download_audio_model_topic = topic("download-audio-model")

  10. Configure storage bucket event handlers

    main

    Nitric allows you to trigger application logic based on file changes within a bucket. During the build sequence, if you register an event callback in your code, Nitric configures the necessary cloud infrastructure to support notifications.

    Build Sequence for Notifications

    1. Register Callback: The App Worker registers an event callback with the Nitric SDK.
    2. Forward Spec: The SDK notifies the Nitric CLI, which forwards the requirement to the Nitric Provider.
    3. Provision Infrastructure: The Provider uses IaC to:
      • Provision the Bucket.
      • Provision Event Rule(s) (e.g., S3 Event Notifications or GCS Pub/Sub notifications).
      • Provision IAM permissions to allow the event to trigger your function/service.

  11. What the Nitric Service Module manages

    main

    The Nitric Service Module is an abstraction layer that handles the complexities of deploying containerized services. It automates several operational tasks:

    • Infrastructure as Code: Configures Terraform to manage containerized services without requiring provider-specific manual setup.
    • Registry Management: Dynamically creates and manages container registries for storing service images.
    • Image Lifecycle: Automates authentication and tagging for container image pushes.
    • Security (IAM): Creates roles with least-privilege permissions, including necessary trust relationships and policies for resource interaction.
    • Runtime Configuration: Configures environment variables, memory limits, and execution timeouts.
    • Networking: Supports advanced configurations like VPC settings for isolated deployments.
    • Abstraction: Provides a consistent interface for developers to focus on logic while operations teams manage the underlying infrastructure.