[andrewingram]

I first saw this one a few weeks ago, and have been trying to weigh up its pros and cons over GraphQL (my tool of choice).

gRPC-Web:

* Speaks protocol buffers, a fast and compact format compared to JSON

* Allows clients to use the same APIs as backend services.

GraphQL:

* Enables a client-centric view of the system. I have abstractions in my GraphQL server that only make sense to clients. It's a query-centric implementation of the Backend-for-frontend pattern, where the owners of the service are also the consumers.

* Enables an entire UI's requirements to be fetched in one go (or optionally split up, if some content is less important). To achieve the same level of aggregation performance in gRPC would require building something analogous to GraphQL.

The other benefits of gRPC-Web outlined in the article (generating typescript bindings) are equally possible with GraphQL (Relay Modern generates flow types, and is probably just one pull request from supporting TypeScript too)

The status code standardisation only makes sense for single-purpose endpoints/calls, once you're dealing with aggregations, the semantics of a downstream status code will vary depending on the use case the query fulfills.

I think both solutions have use cases, and can even happily co-exist. I don't believe gRPC-Web to be as much of a game-changer as GraphQL, but for certain scenarios (needing to rapidly fetch streams of data that don't have cross-dependencies) I can definitely see the benefits of a solution based on gRPC.

[al2o3cr]

    Allows clients to use the same APIs as backend services.

Whether this counts as a bug or a feature depends on your APIs. I'm currently unfucking a suite of applications which bought into "your SPAs can just call backend services directly!" without getting a better security model - so the SPAs use hard-coded tokens that don't do any authorization, just like the backend services... facepalm

[euyyn]

Sounds like those backend services needed better security too. It seems orthogonal to whether you have 3 different API surfaces (one for web, one for mobile app, one for backend servers), or the same for all. At Google, gRPC allowed us to move from the former to the latter.

[andrewingram]

Personally I consider it a bug, but I was trying to avoid being too dogmatic in my comment, given it's clear i'm already decidedly biased in favour of GraphQL.

[decwakeboarder]

> Speaks protocol buffers, a fast and compact format compared to JSON

This is definitely important at Google-scale, but for the rest of us compressed JSON typically isn't that bad.

[euyyn]

If your users access your website from their phones, the latency and CPU benefits of proto become important for them.

[kybernetikos]

You should also test the speed. JSON.parse is surprisingly fast in modern browsers and binary access is surprisingly slow.

[krona]

Unless you're, you know, streaming anything other than UTF8.

[zepolen]

Last time I tried protocol buffers it was dog slow, json was pretty fast, and msgpack was insane fast. This was on a heavily nested dict of dicts structure.

[rco8786]

does graphql come with its own serialization protocol? I would have thought that the comparison of gRPC to GraphQL is apples/oranges.

[e1g]

GraphQL defaults to JSON over HTTP, but you can funnel it through sockets or protobuf or anything else. The conflict here is that gRPC goes beyond a serialization protocol - it's a full strongly typed RPC layer. You define your objects, methods, fields, types, relationships, data resolvers, execution pathways, etc. Just like GraphQL.

I see no meaningful advantage in binary serialization - JSON is fast enough not to be an issue, and HTTP2/GZIP minimize any bandwidth advantage. I do see a bit advantage of GraphQL in tooling and query composition, but I gRPC provides the building blocks required to rebuild that. gRPC-web is GraphQL of 12 months ago - it's definitely on the right path to help with complex data wrangling. My question is - does it do something important better/differently to GraphQL to warrant new players to enter the game and catch up to make it a strong competitor?

[ddorian43]

it uses json ? so you compare it to that

[andrewingram]

The default is JSON, but the spec doesn't mandate that it be JSON over the wire, or that even that it be over HTTP.

[throwaway2016a]

Also in the Json the "query" is actually a string that is in GraphQL language. So GraphQL is an encoded format embedded inside Json.

{ "query": "mutation Foo() { ... }" }

As such type safety is dependent on the query langauge (graphQL) not Json. As far as the Json goes, it might as well be multi-part form encoded.

[halostatue]

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).