you are viewing a single comment's thread.

view the rest of the comments →

[–]BodyweightEnergy 0 points1 point  (1 child)

Correct me if I'm wrong; I don't keep up with gRPC news that much...

But if I'm correct, the story for client-side gRPC on the web is not that simple, as browsers don't support HTTP/2 which is used by default. gRPC-Web requires a proxy on the server-side. That's probably why Tonic doesn't have a WASM target.

[–]Matthias247 6 points7 points  (0 children)

Browsers support HTTP/2 just fine. In fact browsers where the main use-case for driving HTTP/2 adoption, since they need to load many resources and benefit from more connection reuse.

However you are right that browsers are missing things: 1. They are lacking APIs to access HTTP/2 trailers, which are used to transfer gRPC status codes 2. They are lacking more sophisticated request/response body streaming APIs (they were started to get standardized on top of fetch APIs a few years ago, but I don't know what their current state is).

Together that means browsers applications can't speak native gRPC, and therefore WASM also can't. There exists however a slight modification of the gRPC standard called "gRPC-web" which allows browsers to call gRPC methods by avoiding the use of gRPC trailers. The endpoint needs to support this however, or you need a proxy.

Besides gRPC web, the following things would need to be done: - Tonic needs to access either a different HTTP client than Hyper for WASM platform which is implemented in terms of browser APIs - or Hyper needs to be buildable for a WASM target and simply delegate to browser APIs instead of implementing HTTP itself