Both protocols let client and server push to each other over a single long-lived connection. The right choice depends on who the client is, what schema discipline you want, and how much polyglot support matters.
The 30-second comparison
| Aspect | WebSocket | gRPC Bidi |
|---|---|---|
| Browser-native | Yes | Needs grpc-web proxy |
| Schema | BYO (often JSON) | Protobuf enforced |
| Backpressure | Manual | HTTP/2 flow control |
| Auth | Token in URL or first msg | Standard gRPC interceptors |
| Polyglot SDK | Manual | Generated stubs in 10+ langs |
Pick WebSocket when
your primary client is a browser (no proxy hassle), payloads are JSON, and you control both ends — chat apps, live trading UIs, multiplayer.
Pick gRPC bidi when
your clients are services or mobile apps with generated stubs, you want schema enforcement, and you have polyglot teams. Microservice-to-microservice streaming is the canonical fit.
The middle ground
grpc-web bridges the gap — it lets browser clients talk to gRPC servers via an HTTP/1.1 fallback. You lose true bidi streaming (server-streaming only over HTTP/1.1) unless you also enable the gRPC-Web bidi extension behind an Envoy proxy.