gRPC

Feature activation

Enable gRPC support:

nestforge = { version = "1", features = ["grpc"] }

Core types

The gRPC surface centers on:

• NestForgeGrpcFactory
• GrpcContext
• GrpcServerConfig
• re-exported tonic and prost

Bootstrap pattern

use nestforge::NestForgeGrpcFactory;

NestForgeGrpcFactory::<AppModule>::create()?
    .with_addr("127.0.0.1:50051")
    .listen_with(|ctx, addr| async move {
        tonic::transport::Server::builder()
            .serve(addr)
            .await
    })
    .await?;

Provider resolution inside services

Your tonic service stays the transport boundary, but it can still resolve providers from NestForge through GrpcContext.

That keeps the transport-specific code focused while reusing the same DI model as the rest of the application.

Code generation

The gRPC-first example shows the expected toolchain:

• proto/*.proto defines the contract
• build.rs compiles it through tonic-build
• generated code is loaded with tonic::include_proto!(...)

Because the setup follows the normal tonic workflow, protoc is part of the practical build requirements for generated apps.

gRPC plus microservices

If both grpc and microservices are enabled, RPC handlers can dispatch into a transport-neutral MicroserviceRegistry. That is a good fit when you want a typed gRPC edge but a shared message-pattern core.