Hello NestForge gRPC

Run the example

Example location:

examples/hello-nestforge-grpc

Run it from the repository root:

cargo run -p hello-nestforge-grpc

The service listens on 127.0.0.1:50051.

Example purpose

This example demonstrates how NestForge can provide module wiring and dependency injection while tonic remains the concrete gRPC transport boundary.

Files included

The example currently includes:

• src/main.rs
• src/app_module.rs
• src/app_config.rs
• src/grpc/mod.rs
• src/grpc/patterns.rs
• src/grpc/service.rs
• src/grpc/proto/mod.rs
• src/grpc/proto/hello.rs
• proto/greeter.proto

Recommended reading order

Read the example in this order:

1. proto/greeter.proto
2. src/app_module.rs
3. src/grpc/patterns.rs
4. src/grpc/service.rs
5. src/main.rs

What each file does

src/main.rs

Creates NestForgeGrpcFactory::<AppModule>, binds to 127.0.0.1:50051, and mounts the generated tonic GreeterServer.

src/app_module.rs

Registers application config and a GrpcPatterns provider, then exports both.

src/grpc/patterns.rs

Builds a MicroserviceRegistry with the hello.say message pattern. This is a key design detail: the example uses the microservice pattern layer as business logic behind the gRPC transport.

src/grpc/service.rs

Implements the tonic-generated Greeter trait. It validates the request, resolves the pattern registry from GrpcContext, dispatches the request through dispatch_grpc_message(...), and maps the payload back into a gRPC response.

proto/greeter.proto

Defines the public transport contract.

Important current-state note

In this workspace snapshot, the example already includes generated bindings under src/grpc/proto/ and does not currently include a local build.rs file. That means the docs should be read against the checked-in example as it exists now, not against an older generic tonic template.

What users learn from this example

• how NestForge DI works in a gRPC-first app
• how to keep transport code thin
• how to bridge gRPC and transport-neutral microservice patterns
• how config providers remain available inside the service layer

What to verify

When running the example, verify:

1. the contract is defined in proto/greeter.proto
2. GrpcPatterns resolves through GrpcContext
3. the service dispatches into hello.say
4. the tonic server is mounted by NestForgeGrpcFactory