การสะท้อนข้อมูลของเซิร์ฟเวอร์และไคลเอนต์แบบไดนามิก

Normally a client needs the .proto files compiled into stubs to call a service. That is inconvenient for debugging tools and generic clients.

Server reflection lets a server describe its own API at runtime.

The reflection service answers questions like:

• Which services does this server host?
• What methods does a service have?
• What are the request/response message schemas?

It returns the underlying FileDescriptorProto data.

Register the reflection service on your gRPC server with a single call.

In Java add the ProtoReflectionService when building the server.

With reflection on, grpcurl can list services without a proto file.

You can inspect a method's input and output schema directly from the server.

Reflection lets you invoke methods by sending JSON; the tool maps it to protobuf using the discovered schema.

Libraries can build messages dynamically from descriptors fetched via reflection, enabling generic gateways and admin tools that work against any gRPC server.

Reflection is itself a gRPC service: grpc.reflection.v1.ServerReflection. It uses a bidirectional stream where clients ask and the server streams back descriptors.

Reflection reveals your entire API surface. In production:

• Disable it on public-facing edges, or
• Restrict it to internal networks / authenticated callers

It is invaluable in dev and staging.

Reflection shines for debugging, building generic UIs (like BloomRPC/Postman), and admin tooling. For high-throughput app clients, precompiled stubs are still faster and safer.

You learned server reflection and dynamic clients:

• Reflection lets a server describe its own API at runtime
• Enable it with reflection.Register (Go) or ProtoReflectionService (Java)
• Tools like grpcurl can list, describe, and call without stubs
• Dynamic clients build messages from fetched descriptors
• Restrict reflection in production for security