[strken]

As I understand it, the problem GraphQL and related query languages are trying to solve is that in single page web apps and native apps, there's a trade-off between long round trip time on one hand and creating one-off RESTless endpoints that mirror the visual structure of your app on the other. GraphQL allows you to put work into defining resolvers for everything in the hope that it eliminates maybe 90% of your RESTless routes. Instead of complicating the server to make things a little easier for the client, it simplifies the server by removing knowledge of the client's ui. I'm not sure what you mean by every api endpoint, because graphql should pretty much only have one.

Regarding nodejs and overfetching, the canonical solution is Facebook's DataLoader library. I think it might even be in the docs somewhere.

Regarding jrGQL, I'm not sure the use case is the same. They look like different tools for different problems, but I'd be interested in hearing more about what problem it solves.

[alvis]

As a GraphQL user, hardly I can say it is perfect, but it does solve many current challenges arisen from the surge of mobile use, namely the waste of bandwidth on headers and unused content, as well as latency between requests.

From the server point of view, using GraphQL may not sound great since any single tiny update on the schema also implies an update on the single endpoint, rather than just one of many. Until there is an implementation of dynamic modularization, maintaining the integrality of a service is a constant pain.

Fairly enough, I think the tradeoff is balanced. GraphQL solves problems on the client side and yet it creates problems on the server side.

Meanwhile, I am more concerned about the future of GraphQL as http2 has arrived. With http2, the biggest selling point of reducing latency by using one single endpoint does not sound anymore. Then for the flexibility of limiting the scope of return, you can always specify it on the conventional RESTful API. So there is not much practical benefit. (Oh yes, there are some more goodies like subscription, but let's face it that not many use it) So to make GraphQL more useful, I think it needs a bigger evolution.

[lewisl9029]

> Meanwhile, I am more concerned about the future of GraphQL as http2 has arrived. With http2, the biggest selling point of reducing latency by using one single endpoint does not sound anymore. Then for the flexibility of limiting the scope of return, you can always specify it on the conventional RESTful API. So there is not much practical benefit. (Oh yes, there are some more goodies like subscription, but let's face it that not many use it) So to make GraphQL more useful, I think it needs a bigger evolution.

GraphQL's most significant latency gain isn't achieved through the use of a single endpoint to minimize parallel requests. As you mentioned, HTTP2 makes this a non-factor in terms of latency. The single endpoint part is only an implementation detail, and most follow it simply by convention.

Rather, GraphQL's major breakthrough in latency reduction is achieved through the use of the graph query language to completely bypass the multiple client-server roundtrip problem for interdependent data (i.e. having to wait for a user request to return the organization id, before being able to send a request to find some property off the organization the user belongs to). HTTP2 isn't able to help at all for this use case.

[KirinDave]

> Instead of complicating the server to make things a little easier for the client, it simplifies the server by removing knowledge of the client's ui. I'm not sure what you mean by every api endpoint, because graphql should pretty much only have one.

Well I've yet to work with a set of server-side tools that actually deliver on this promise. I really don't like the tools I have.

I'm now attempting to synthesize and optimize SQL queries in python. Messy business. Way more defect-prone.

> DataLoader

I'm a haskell programmer and even I think that programming model is pretty brutal.