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:
- Vercel Configuration Framework:
- Define a global
vercel.json structure that routes all incoming /api/* traffic to the NestForge handler.
- 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.
- 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.
- 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
- AWS Lambda Layer with Cargo Lambda: Considered, but will be implemented later on
- Docker-based Serverless (Google Cloud Run): A Considered but will be implemented later on
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:
vercel.jsonstructure that routes all incoming/api/*traffic to the NestForge handler.src/api/index.rs) that exports the standard Vercel lambda handler function using thevercel_runtimecrate.127.0.0.1background daemon.nestforge deploy --vercelcommand to automate the scaffolding of deployment configs.Breaking Change Analysis
Performance Impact
Alternatives Considered