gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
spatialos.improbable.io
gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
1–10 of 139 posts
Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
#2Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
#3Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
#4Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
#5And for me "the next big thing" is something like GraphQL.
Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
#6gRPC-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
#7If 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].
Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
#8There is a reason why more and more people left RPC and use REST. And for me "the next big thing" is something like GraphQL.
Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs
#9The 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.
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.