gRPC

If you want the implementation flow instead of the reference view, start with gRPC Workflow.

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

The maintained gRPC example boots the server like this:

use nestforge::NestForgeGrpcFactory;

NestForgeGrpcFactory::<AppModule>::create()?
    .with_addr("127.0.0.1:50051")
    .listen_with(|ctx, addr| async move {
        nestforge::tonic::transport::Server::builder()
            .add_service(GreeterServer::new(GreeterGrpcService::new(ctx)))
            .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.

let config = self.ctx.resolve::<AppConfig>()?;

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.