Skip to content

feat(core): Configure NestForge Framework Deployment for Vercel #30

Description

@vernonthedev

Area

core

NestForge Version

3.0

Rust Version

1.87

Summary

As NestForge nears its stable v3.0 milestone, we need to provide a first-class deployment target for serverless environments. This issue tracks the implementation of official support for hosting NestForge applications on Vercel. By leveraging Vercel's native Rust runtime support, we will enable developers to deploy high-performance, modular NestForge APIs alongside their Next.js frontends seamlessly.

Technical Spec

The implementation requires adapting NestForge's Axum-based runtime architecture to match Vercel’s API Gateway proxy rules:

  1. Vercel Configuration Framework:
    • Define a global vercel.json structure that routes all incoming /api/* traffic to the NestForge handler.
  2. Serverless Entry Point:
    • Create a specialized compilation target (e.g., src/api/index.rs) that exports the standard Vercel lambda handler function using the vercel_runtime crate.
  3. Routing Adapter:
    • Implement an architectural bridge that maps NestForge’s dependency injection (DI) container and modular router to process individual incoming Vercel Lambda events rather than running as a persistent 127.0.0.1 background daemon.
  4. CLI Integration:
    • Update the NestForge CLI tool with a nestforge deploy --vercel command to automate the scaffolding of deployment configs.

Breaking Change Analysis

  • Core Engine: None. Persistent server engines (Axum/Tokio loops) will remain intact for traditional VPS/Docker setups; this adds a secondary compilation branch for serverless environments.
  • State & Lifecycles: High conceptual impact. State management inside modular instances must switch from in-memory cache architectures to stateless connection strings (e.g., Supabase, Redis) since Vercel spin-ups are ephemeral.

Performance Impact

  • Cold Starts: High priority. We must minimize the framework binary size by turning off heavy default features during Vercel builds to keep cold-start latency under 200ms.
  • Execution Speed: Once warmed, execution speed will maintain sub-millisecond Rust efficiency levels inside Vercel's secure micro-VM execution model.

Alternatives Considered

  1. AWS Lambda Layer with Cargo Lambda: Considered, but will be implemented later on
  2. Docker-based Serverless (Google Cloud Run): A Considered but will be implemented later on

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

  • Status
    In Development

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions