What this prompt does
This prompt asks the AI to build a Node.js gRPC microservice in TypeScript for a [service_domain], generated from Protocol Buffers and ready to deploy. It produces proto definitions for your [rpc_methods], TypeScript types generated with [codegen_tool], a server built on [server_framework], a client with connection pooling and load balancing, streaming support for the [streaming_use_case], deadline and cancellation propagation, interceptors for logging and [auth_method] auth, the gRPC health-checking protocol, graceful shutdown with a drain period, and integration tests — plus a Dockerfile and Kubernetes YAML.
The structure works because gRPC's value is strong, fast, typed contracts between services, and that only holds if the proto, generated types, and interceptors stay consistent. Naming your real [rpc_methods] and [streaming_use_case] grounds the proto in your actual API surface, while the health-check and graceful-shutdown steps make the service behave correctly under an orchestrator instead of just running locally. Deadline and cancellation propagation matter for the same reason: without them, a slow downstream call keeps consuming resources upstream long after the caller has given up, so the prompt wires them through from the start.
When to use it
- You have services that call each other frequently and want typed, low-latency contracts instead of REST and JSON.
- You need streaming (server-side, client-side, or bidirectional) for something like a real-time activity feed.
- You are deploying to Kubernetes and want health checks and graceful drain wired from the start.
- You want cross-cutting concerns (logging, auth, error mapping) handled in interceptors rather than scattered in handlers.
- You are standardizing how new microservices are scaffolded across a team.
- You need deadline and cancellation propagation so a slow call does not pile up upstream.
Example output
Expect a .proto file defining your [rpc_methods], generated TypeScript types, a server implementation with interceptors and health checks, a reusable client with pooling, streaming handlers for the [streaming_use_case], integration tests, and deployment artifacts (Dockerfile plus Kubernetes manifests). It is organized as a deployable service skeleton rather than a single demo file.
Pro tips
- List
[rpc_methods]precisely, since they define the proto and therefore every generated type and stub. - Match
[codegen_tool]to your toolchain — ts-proto produces different output shapes than other generators, and the server code assumes one. - Pick
[streaming_use_case]carefully; specifying whether it is server, client, or bidirectional streaming changes the handler signatures significantly. - Set
[auth_method](for example, JWT in metadata) so the auth interceptor reads credentials from the right place. - Confirm the
[server_framework]choice matches what your team maintains, as the interceptor and shutdown wiring is framework-specific. - Iterate by asking it to add a specific interceptor or to show how a deadline propagates from client through to a downstream call.
