Challenge 3: gRPC Bidi or WebSockets? — Possible Solution
====================================================================

RAW WEBSOCKETS is the better fit here.

The deciding factor from this chapter's own distinction: "the browser
is one of the two endpoints." gRPC — as established back in Chapter
1's gotcha — does NOT run natively in a browser; a browser cannot
perform the low-level HTTP/2 framing gRPC's bidirectional streams
require without an intermediary proxy (gRPC-Web), which adds real
infrastructure complexity and, even then, gRPC-Web's browser support
for true bidirectional streaming is more limited than raw
gRPC-to-gRPC communication between two backend services.

Raw WebSockets, by contrast, are natively supported in every modern
browser with no proxy or translation layer needed at all — a browser
can open a WebSocket connection directly. For a multiplayer game
needing low-latency, full-duplex communication between a browser
client and a server, WebSockets is the mechanism actually designed for
exactly this endpoint pairing, while gRPC bidirectional streaming was
designed first for service-to-service communication where BOTH ends
are backend code the team controls (per Chapter 1's "why Google built
gRPC" framing) — not a browser talking to a server.

If this same game instead needed two BACKEND services (e.g. a game
server talking to a matchmaking service) to exchange real-time,
bidirectional, schema-typed messages, gRPC bidirectional streaming
would be the stronger choice there — but that's a different pairing
than "browser is one of the two endpoints."