[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.