Ask HN: Is the future of server-client communication gRPC or GraphQL? - billykwok
======
niftich
Neither.

gRPC is an RPC mechanism, IDL, and codegen that uses HTTP2 as a transport, but
by design requires the designer to control (and/or supply) both the server and
the client -- or provide ample, ample documentation of the binary
serialization format and the interface for a third-party to be able to
implement a client, which is considerably more effort than today's typical
scenario of loosely, best-effort parsing some JSON and pluck out a field or
two. Therefore gRPC is _most_ useful for internal (i.e. server-to-server in
the same org) communication and for server-to-official-client communication
(like from Google's servers to the Official Gmail App on multiple platforms).

GraphQL is a query language. It's a way of structuring requests, similar to
how SQL is a way of structuring requests you then send to a database engine to
evaluate. Just like SQL is a perfectly acceptable interface of interacting
with certain applications (like databases), GraphQL is too, which treats the
executor as a big datastore.

However, mutations in GraphQL read much the same way as Document-Wrapped style
WSDL: you define VerbInput as the incoming message/Object, and VerbPayload as
the response message/Object. While GraphQL is otherwise really neat, I fail to
see the innovation here; this is simply RPC over an object-oriented wrapper
using a syntax that's clearly not amenable to it [1][2].

[1]
[https://facebook.github.io/relay/graphql/mutations.htm](https://facebook.github.io/relay/graphql/mutations.htm)

[2] [https://facebook.github.io/relay/docs/graphql-
mutations.html...](https://facebook.github.io/relay/docs/graphql-
mutations.html#content)

I believe that JSON-on-the-wire, HTTP(2)-as-a-protocol will remain the most
common form of client-to-server (and vice versa) interaction in the future.
Note that this _isn 't_ the same thing as REST, albeit many such APIs are
colloquially called 'Restful'. This style of APIs is typified by up-and-coming
codegens like Swagger, RAML; the ones that look on the wire like
[http://jsonapi.org/](http://jsonapi.org/)

And the reasoning is:

\- it's easy to produce as a server

\- it's easy to consume partially (as it's often done), or in entirety

\- it's plausibly human readable, and thus, debuggable without special
instrumentation

\- it's (mostly) emittable and consumable by a wide range of programs and
environments, like the browser address bar, XHR, Fetch API, the browser JS
console, curl, wget, and a myriad HTTP clients

