In the left panel you’ll notice that the REST API server acts as the point of contact between the web app and the backend. In a lot of scenarios, the REST server does little more than translate HTTP calls from the client into gRPC calls to backend services.

Let’s walk through an example: a client wants to authenticate using a gRPC backend server by POST ing JSON to the HTTP server’s /auth endpoint. The HTTP server translates that POST request into an AuthRequest Protobuf message, sends that message to the backend gRPC auth server, and finally translates the AuthResponse message from the auth server into a JSON payload for the web client. As I stated in the blog post I wrote for the CNCF blog, there’s nothing wrong with this approach per se. It’s a well established pattern that plenty of developers have used quite successfully; if it works for you, keep it.

But let’s face it: it would save you a lot of work if the web clients could cut out the HTTP intermediary and just send requests directly to the backend (imagine the JavaScript auth client sending an AuthRequest message and getting an AuthResponse message back). That would mean no HTTP status codes, no JSON SerDe, and no deployment and management burden for the HTTP server itself.

In the right panel you see the new gRPC-Web alternative. You’ll notice: fewer pieces of the puzzle, one protocol throughout (yay green lines!), no HTTP logic anywhere, all data interfaces defined using .proto files. The client sends a Protobuf message to the gRPC backend and gets a Protobuf message back, period.

In order to get this benefit, there’s just one other thing you need to have in place…

The role of Envoy

Confession: I fibbed a little. Earlier I said that with gRPC-Web clients can make gRPC calls “directly” to backend services. That’s not quite true. With gRPC-Web, client calls still need to be translated into gRPC-friendly calls, but that role is now filled by Envoy, which has built-in support for gRPC-Web and serves as its default service gateway.

Figure 2 below presents a basic picture of where Envoy fits into the gRPC-Web picture. Here, a web app interacts with a backend gRPC service, which in turn relies on two other gRPC services. Envoy translates the HTTP/1.1 calls produced by the client into HTTP/2 calls that can be handled by those services (gRPC uses HTTP/2 for transport). HTTP is still going on under the hood, but neither the client nor the server need to think in HTTP terms.