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

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?

You're still breaking and forcing a refactor by all your clients and there's no way to track that with type safety.

That said, this use case seems to be for a single web front end and go back end but that part is left out of the title.

Protos are fine, google likes protos, gRPC works for Google because they have that insane CI system that builds every project at once...but any schema would work and you can be generating and checking against a schema for a JSON API as well. You don't need to move past REST and JSON to get what you're asking for.

If you want a type safe RPC, you have to use proper RPC system in the first place. It doesn't matter if it is gRPC, SOAP, XML-RPC, JSON-RPC, or Apache Thrift. REST doesn't even define serialization format or error reporting.

> you have to use an RPC system that at least has types! What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system?

So you claim that JSON doesn't have types, right? And, by extension, Python and Lisp don't have types, too, because of the very same arguments? You know you're being ridiculous now, right?

> What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system?

Nothing. And the same applies to a typed RPC. You don't have to use the typed client. Or you could be using an old version, or it could be misconfigured, etc. You can enforce schema on the server and client side, but you'll never really know if it works statically, since you don't compile and deploy the server and client atomically.

Client code for PB+JSON has been a part of Google’s Closure library in fact (open source), and they used it in production for Gmail’s RPC, but I’m not sure if it’s still supported/recommended for PB 3.

The reason to use JSON instead of compact binary representation has been because JSON.parse is fast and doesn’t require any additional code. But nowadays JS is fast enough in most cases (unlike you’re doing something like streaming with media exts), but you can also ship Web Assembly/NACL library and (soon) delegate parsing to Web Worker with shared memory which should altogether give best possible performance.

Our experience of using gRPC in Java, C++ and Golang is pretty good. While it had some initial teething issues (when it was first released), the libraries have generally been a non-issue since the gRPC General Availability (GA-1.0 version).

If you're considering using it in Go, check out the https://github.com/grpc-ecosystem/go-grpc-middleware helper libraries that we've contributed back to gRPC Ecosystem.

At least by August 2015 I was working on automatic window size tuning, which I've not seen in another HTTP/2 implementation to date. July 2016 it was implemented in Java, but remains disabled due to interoperability concerns that we need to spend time addressing. C now implements something similar and it may be enabled in 1.3.

For flow control to work promptly the window size should be only as large as necessary, so there is cause for keeping it small. Since the lower value is appropriate for many networks, it isn't completely outrageous.

I think the biggest failure on gRPC's part here is not having a notice in a widely-read part of documentation informing users to be aware of the limitation. That's easier said than done, but that doesn't negate its importance.

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.

https://addons.mozilla.org/en-US/firefox/addon/amf-explorer/

This compatibility pattern also leads me to conclude that protocol buffers aren't a suitable model for generating a client-side type system. You'll just end up with structures where everything is a Maybe type, so you end up needing tons of bespoke client-side code to handle the possible permutations.

You need a layer on top of of them to express the true type system suitable for clients, and I believe GraphQL does a great job of this (but I hasten to add that even GraphQL's type system is relatively limited and isn't a magic bullet).

- For all of them you need to know the remote addresses (IP/hostname, port) upfront or use an external service discovery solution.

- For both you can implement some service introspection, which delivers you a list of available services/methods. Afaik for grpc there even exists some standardized introspection mechanism. For other HTTP APIs you might want to download some swagger description from a well-known address. Or WSDL scheme. Or GraphQL schema.

- Standards on which layer? On transport layer you are following the HTTP standard, independent of whether you are using grpc, GraphQL, json-rpc or some handmade REST API. On application layer you are mostly on your own anyway, there's not a lot things one could standardize. There are some exceptions, like the standardization of Webdav on top of HTTP, but most applications have their own specific set of requirements. If we are talking about standardization without meaning offical-standardization, then we can argue that grpc provides a more rigid (standardized) model for an application than the definition of some ad-hoc APIs: It is standardized how APIs and exchanged data types are defined (.proto files), how they can be accessed and how data is transferred over the wire (mapping to HTTP). All of that without the application developers on both sides needing to care for it.

That is why SDKs are so popular with developers. They just want to call a method and not be concerned with how the bits get across the wire.

And please do not cite the browser as a good example of a REST client. The browser is driven by an advanced AI (namely a human). We are not there yet with machine to machine interactions, and it isn't clear that REST is the magic bullet that will enable this kind of system.