gRPC Reflection and grpcurl

The gRPC Server Reflection service (grpc.reflection.v1alpha, or grpc.reflection.v1 in newer implementations) is itself a gRPC service that a server can expose alongside its regular RPCs, letting any connected client ask 'what services do you host, what methods does each have, and what do the request and response messages look like' entirely at runtime, without the client needing a copy of the .proto file. This is what makes tools like grpcurl and Postman's gRPC client able to construct and send valid calls against a server they've never seen source code for, by walking the reflection API's ServerReflectionInfo bidirectional stream to fetch FileDescriptorProto definitions on demand.

Enabling reflection in Go is a one-line addition — import google.golang.org/grpc/reflection and call reflection.Register(grpcServer) after creating your grpc.Server but before calling Serve — which registers the reflection service alongside whatever business services you've already registered via RegisterXxxServer. Because reflection literally hands out your entire API's method signatures and message schemas to anyone who can open a connection, most teams gate it behind an environment check so it's registered in development and staging but conditionally skipped (or placed behind auth) in production builds.

grpcurl is the gRPC equivalent of curl for HTTP: grpcurl -plaintext localhost:50051 list enumerates every service the server exposes via reflection, grpcurl -plaintext localhost:50051 describe mypackage.MyService.MyMethod prints that method's request and response message shape, and grpcurl -plaintext -d '{\"id\": 42}' localhost:50051 mypackage.MyService/GetItem actually invokes the RPC with a JSON-encoded payload and prints the JSON-encoded response. Dropping -plaintext and instead passing -cacert or -insecure controls how grpcurl handles TLS, mirroring the same trust decisions a real gRPC client library would make when dialing a TLS-secured server.

Because reflection exposes your complete API surface — every method name, every field, every nested message type — to anyone who can reach the port, it's a meaningful information-disclosure risk on a public-facing production endpoint, roughly equivalent to leaving OpenAPI's swagger.json unauthenticated on a REST API. The safer production pattern is to disable reflection entirely and instead distribute the compiled FileDescriptorSet (via buf build -o or protoc --descriptor_set_out) to the specific teams and tools that need it, letting grpcurl target the server with grpcurl -protoset my.protoset instead of relying on the server volunteering its own schema.