Live data from Hacker News

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

spatialos.improbable.io

1–10 of 139 posts

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

#6
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.

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

#7
The reference implementation of gRPC on github[0] has 998 open issues and 215 open pull requests. Every time I've tried to use this package I have encountered a previously-reported issue which has remained unfixed for months.

If you need to interact with Google platform it's hard to avoid using gRPC, since many "official" libraries seem to be migrating towards this library, while it remains fragile and bug-ridden. My "days since gRPC problem" counter is currently on "2", after hitting an issue which /crashed my python interpreter/ and required altering apache config to workaround[1].

[0] https://github.com/grpc/grpc/issues

[1] https://github.com/grpc/grpc/issues/9223

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

#9
post #2

The title ("by Google and Improbable") is a bit misleading since it implies a collaboration between the two, when it's actually Improbable's own implementation that they released ahead of Google's pending spec.

One of the authors here.

This is indeed our own implementation of the pending spec. We are in touch with the gRPC team to make sure that their (still unreleased) implementation is cross-tested with ours.

The benefit of our implementaiton is a relatively light-weight client-side lib for Typescript and >=ES5, and a "ready-to-go" Go middleware.

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

#10
I think I like gRPC, but have several reservations regarding replacing REST with it. REST web services often return multiple mime formats, not just pure structured data. Some services return images, others return HTML, and then you also have cache... Maybe I just don't know enough about gRPC, but I can already imagine many people passing images around as byte arrays inside protocol buffers and when we look back, we have reinvented SOAP, which reinvented Corba.
Post reply on HN