gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

Is this SOAP 2.0 ?

Nothing says you can’t have clients use the same APIs as backend services with GraphQL, and GraphQL proper doesn't require JSON; it just requires a map content type (more or less, per https://facebook.github.io/graphql/#sec-Serialization-Format).

gRPC has some benefits over REST. Since it's declarative, the entire API can be expressed as an RPC block in the .proto file, so your clients in multiple languages can be generated from this spec. With REST, you'd have to tell clients what protobuf structs to use with what endpoints. But of course the end result is roughly the same, once you've built clients and servers.

gRPC's built-in streaming and support for out-of-band data ("header" and "trailer" metadata) is also nice. For example, a gRPC server can emit trailing metadata containing an error, if something goes wrong halfway through a streaming request. Without this, you'd have to build a custom "protocol" on top of your Protobuf REST stuff; the stream would/could emit oneOf-structs that contain either payloads or metadata.

One downside to gRPC/Protobuf is that it's much less convenient to perform quick and dirty interactions against the servers. There's no standard, I think, for exporting the gRPC API to a client that doesn't already have the .proto file; I could be wrong, but don't think you can build a generic client that can talk to any gRPC server, list its available endpoints and so on.

The gRPC project is surprisingly shoddy, given that it's Google's "next-generation" client protocol that's being slowly implemented across all Google products.

The state of the various Protocol Buffers projects isn't great, either. Google's Go implementation produces some awkward Go code, but efforts to increase user-friendliness are generally being knocked down (by Googlers, I think). Pull requests are lying untouched.

There's a fork called Gogo-Protobuf [1] that tries to evolve the Protobuf project and make it friendlier and faster. One way in which it is nicer is that it makes some attempts to make the generated Go code more idiomatic Go. But it's also hobbled by the above problems. The biggest challenges revolve around two areas: The canonical JSON mapping (which is particularly bad at "oneOf" structs), and custom types (Gogo adds things like better date/time support).

The Gogo team (understandably) doesn't want to diverge too far from the mainline, but that means open issues are stagnating while the PRs in the upstream Google project are stagnating.

These issues of course then also leak into related projects that extend Protobuf, such as the Go gRPC gateway, which implements a REST proxy on top of gRPC. Since the JSON mapping is so lacking, the JSON data you get out isn't quite idiomatic JSON, which makes the gateway pretty much useless for a lot of applications. (Note: It's been about 6 months since we tried to use it and had to give up, it may have improved since.)

We also ended up forking the official JSON marshal code to work around the various issues with it. Other projects such as CockroachDB also do this.

[1] https://github.com/gogo/protobuf

What's a gateway API? I acknowledge, I don't do a lot of frontend work. As I see it, GraphQL is just a query syntax that uses a JSON like language and where the query engine is built in code on the backend. You could replace all queries by REST requests, or build your own query language on top of JSON or RPC.

In my experience though, anything approaching a query language was too expressive for an API, and it was better to offer one API per query, and encapsulate the queries on the backend themselves.