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].
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/
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
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
[2] https://facebook.github.io/relay/docs/graphql-mutations.html...
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/
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