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).<p>gRPC-Web:<p>* Speaks protocol buffers, a fast and compact format compared to JSON<p>* Allows clients to use the same APIs as backend services.<p>GraphQL:<p>* 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.<p>* 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.<p>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)<p>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.<p>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.
I don't understand this, to be honest. What does type safety have to do with serialization formats or application protocols? I've used Servant (Haskell) to define the REST API for my backend, which gives me type safety, server stubs and generated client code for free. In my view, type safety is about what you internally use to represent your API, and has nothing at all to do with the underlying protocol(s). There's nothing about REST+JSON that prevents type safety, as far as I'm aware.<p>I plan to switch to protobuf3 for the serialization format, since this offers both a JSON and binary representation. Why would I want to choose gRPC+proto3 over REST+proto3?
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.<p>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].<p>[0] <a href="https://github.com/grpc/grpc/issues" rel="nofollow">https://github.com/grpc/grpc/issues</a><p>[1] <a href="https://github.com/grpc/grpc/issues/9223" rel="nofollow">https://github.com/grpc/grpc/issues/9223</a>
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.
Another hammer to a multifaceted problem, keep in mind that people have a lot of different use cases where JSON REST API's are the lesser evil.<p>I only skipped through the spec for gRPC, but the protocol seems very limited. I dont like the 'gRPC status codes', where HTTP status codes at least can be grouped in ranges.<p>The abstraction from the technology/protocol should not be the issue compared to the abstraction from the core business logic. When handling multiple consumers, customers and technologies I tend to worry more about where logic is handled and where data is stored, compared to how its transferred.
REST + JSON is simple, easy to debug, and it does the job. Web clients speak JSON, servers speak JSON, humans can read JSON usually. JSON can be gzipped so you get some benefit there.<p>gRPC is another large pile of foreign C code that's essentially a black box. If there is a buffer overflow there that your code hits only somehow, you'd have to know how to debug it and fix it.<p>Also chances are you are not Google, Facebook or Amazon , and you don't really do BigData just your know, regular data.
Just saw this during the morning reading. Without a deep dive, this looks very promising. We have recently been moving to k8s and grpc for our node work and the last piece was how to get to the browser. If this ties it all as one straight protocol from db to browser it will be very welcome and could not have come at a better time. We were evaluating the alternative (GraphQL etc) but our experiences with node and grpc have been excellent so far.<p>Immediate evaluation planned.
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.
Unless I need high throughput, I am sticking with JSON Rest as it's good enough for most things and easier to debug by sticking a proxy in the middle or using ngrep.
This kind of stuff couldn't happen soon enough. REST is so arbitrary and less than useful for building UIs. It's just bad.<p>I've got Relay talking to a GraphQL service built in graphql-java which then talks to a gRPC service layer. The gRPC service layer is a great fit for GraphQL. Some type safety all around, but there could always be more. And there could always be less JSON. Please, no more JSON. The only thing it's good for is debug logging.
I'm using my own gRPC services and Google's speech recognition gRPC API and I absolutely love it. Protobuf/types, generated code, clear API contract.
I'm not sure why you need to modify your serialization or protocol to get type safety.<p>I've been using NSwag (<a href="https://github.com/NSwag/NSwag" rel="nofollow">https://github.com/NSwag/NSwag</a>) to generate TypeScript clients from .ASP.NET controllers and it works great. It can generate TypeScript request/response handlers, and interfaces or classes for any public facing models.
Personally I'd prefer a promise based api.
eg. stub.QueryBooks(qbr).then(...)<p>A benefit of grpc coming to the web means someone will inevitably build a tool to parse a .proto file and generate a ui to test your microservices during dev. That will be cool.
I acknowledge it could just be me and the specific projects I worked on, but I've never been encumbered by an API style. RPC, Rest, GraphQL, I almost find them all to simply differ in syntax.<p>I've managed to solve all my use cases using all three with equal effort, time and with comparable outcomes.<p>There's value in compression and faster serialization/deserializarion formats when and only when micro-performance becomes an issue. Other then that, I think programmers spend way too much time debating over these, where I don't see any one of them providing an ROI advantage over the others.
Don't forget to protect against malicious user input! There are both pros/cons for 'non-human-readable' in the security department for sure.<p><i>Finding a $5,000 Google Maps XSS by fiddling with Protobuf</i> | <a href="https://news.ycombinator.com/item?id=13829925" rel="nofollow">https://news.ycombinator.com/item?id=13829925</a>
One cautionary tale is to avoid generating code that exists at run time with Typescript. We managed to cause a severe page load regression for a while by generating Typescript for each DbObject and Projection (similar to a persistent GraphQL query).<p>My advice is to only generate types and interfaces if possible.
There is also Google's own implementation of this that has been in the works for some time. See <a href="https://github.com/grpc/grpc/issues/8682" rel="nofollow">https://github.com/grpc/grpc/issues/8682</a>
It is still a bit shocking to see how many people are not getting the distinction between an API and a RESTful service.<p>They are very different things and they have very different goals. The hint is in: how much do you value the client?<p>If you have full control over both client/server or if we don't care about any 3rd party developing a client library for your service, then go with something like GraphQL or gRPC or SOAP with a nice, typed spec you can generate your code from and optimize the heck out of the bytes coming through the tubes.<p>If OTOH you have an interest to create a RESTful service that is discoverable, that doesn't require constant client changes, that offer a wider variety of resource representations, that need to stand the test of time, then use HATEOAS and a RESTful architectural style.<p>gRPC is yet another ... RPC.
Nothing good or bad about that. Just make sure you understand the consequences.
But I always thought speaking HTTP with a server can be considered RPC. We can pack our message in XML, JSON, or whatever serialization we choose, passes on to the destination, unmarshall, do something, return.
RPC has its own set of limitations, which if your application qualifies, might be a good fit:<p>* Coupled server and client. gRPC uses protocol buffers which have zero backwards compatibility.<p>* Zero discoverability. The client knows in advance what the server can do.<p>* No standards to follow. You make up your own specs, like Google did.<p>These constraints are orthogonal to REST, the architectural principles behind the web. What they're doing is tunneling RPC over the web, which is what most HTTP APIs are doing already. There are only superficial differences like the use of protobuf, lack of verbs and URIs, etc.