gRPC Generates Code From a Schema, Communicates in Binary, and Supports Streaming
With gRPC, you define a service's methods and message shapes in a schema file called .proto. Both the client and the server generate code from that file. The contract isn't just written down as a document; it is built into both sides as generated code.
gRPC encodes messages as binary in Protocol Buffers rather than as JSON text. Encoded messages are smaller and faster to parse, but unlike a REST response, they can't be read by a person on the wire.
Beyond a single request getting a single response, gRPC also supports streaming. The client or the server can send a sequence of messages over one connection. This suits data that keeps updating better than polling repeatedly.
This combination fits internal service-to-service calls. The client and the server can both use code generated from the same schema, which cuts implementation work and keeps communication fast. It fits public APIs less well, where broad client compatibility and human-readable responses matter more.
Explain what makes gRPC binary and schema-driven, what streaming adds beyond a single request/response, and when gRPC fits better than REST or GraphQL.
A backend needs to stream continuously updating stock prices to another internal service at high frequency, with both services under the same team's control. Which trait makes gRPC fit especially well here?