[pithic]

> But the notion of JrGQL and GQL as query languages means that the servers handling these calls must be query resolvers. Unlike most restful interfaces which tend to devote a single uniform interface per endpoint with only minor modifications, a full query model of your domain means an explosive quantity of potential strategies piped through a single endpoint.

GQL does seem to encourage, if not assume, a type-theoretical graph datastore as the backend. (Who couldn't whip such a thing together, if it were lacking?)

But it does not require one. This point may be lost in the tutorial and examples shown on graphql.org. There is no reason one could not map a basic GQL service onto an existing set of REST endpoints, with each one a type, and the return of their fields controlled by the request.

[KirinDave]

> There is no reason one could not map a basic GQL service onto an existing set of REST endpoints, with each one a type, and the return of their fields controlled by the request.

I know you meant this to be rhetorical but unless this added some fundamental features (e.g., abstracting a distributed transaction negotiation) besides a new awkward interface I think I'd lose my mind writing GQL proxies over all my existing services.

Why just add a layer of waste and latency, along with a whole new intermediate serialization? Seems like make work. Just to adopt a technology for no real reason.

[strken]

It depends on what your UI is. If your page displays information that can be loaded with a few concurrent calls to a single RESTful endpoint each, then by all means stick with that.

On the other hand, if your page loads information from ten different endpoints across three different services, and some calls depend on the results of previous calls, then you have four options: take a massive performance hit, go back to rendering everything on the server, create an endpoint for each page, or implement some way of querying embedded resources.

GraphQL acting as an intermediary for multiple REST apis is one way of doing the latter.

[KirinDave]

Or move to http2 for services?

[tehbeard]

Assuming you have control over the api servers. And you have clients that support http2.

[KirinDave]

Don't (E/A)LBs support http2 now? It's at over 80% client coverage globally, right? Seems pretty safe to IE6 the stragglers and stop worrying about their optimized experience, imo.

Also, http2 push is VERY interesting for application servers.