REST and JSON are the bread and butter of developers creating web APIs. Once apps reach a certain size, though, the lack of type safety and other issues start to grate. Michal Witkowski and Marcus Longmuir over at Improbable (the company that recently raised $500m) explain how they learned to stop loving REST and move to gRPC.
Improbable had started with REST like everyone else, but the importance of strongly typed, well-documented APIs, along with the pain of maintaining API clients for many different languages convinced them to go with gRPC. gRPC (remote procedure call) is a new framework recently open-sourced by Google that runs on the new HTTP2 protocol. Its support for types and code-generating clients convinced the team to adopt it company-wide.
The only exception to that was the web app team. gRPC was not supported by the browser but since the web developers needed access to these gRPC-powered APIs anyway, the team found a way to expose them with the gRPC REST Gateway that generates REST and JSON bindings for gRPC. This worked but turned out to be a bad idea. New API methods and fields would only be accessible to web apps if the platform API and the gateway were redeployed.
Once the prototype was up-and-running, Improbable wanted to push its gRPC-Web solution for TypeScript and Go to production. The goal was to make it easy for web apps written in strongly typed languages to consume gRPC APIs. To this end, it built four components: grpcweb, a Go Package to wrap a Go gRPC server; grpcwebproxy, a reverse proxy for gRPC servers in languages other than Go; ts-protoc-gen, a TypeScript plugin for the protocol buffers compiler (protoc); and finally grpc-web-client a gRPC-web client library for TypeScript.
The Improbable team conclude their article by saying they think gRPC is a real game-changer for web app development. Among the advantages, they enumerate: ease in generating and finding API docs, the ability to generate response objects automatically rather than hand-crafting JSON, and finally the chance to avoid dealing with low-level networking details and tedious things like request headers.