|
|
|
|
|
by feifan
3238 days ago
|
|
Why does "a single endpoint" matter? It seems like the endpoint essentially becomes an implementation detail. True, resolvers can be complicated. But would you bet against improvements to tooling/languages/frameworks making it palatable? IMO GQL's value is compelling enough for something analogous to Rails (something that abstracts away much of the mechanics through convention) to emerge |
|
A single GQL query resolver must be able to recognize which field you want and ideally construct the minimum query that meets the requirements. This is much harder than simply recognizing the correct parameters out of the URL, body and queryParams and execute it.
While the stakes are low for overfetching in this case (odds are the DB doesn't notice and maybe it's not a problem for your network link), as a general problem (in particular when fields have subfields) this gets frustrating very quickly.
My concern is not that this is bad for clients. It makes a ton of sense for clients. It's just much harder for servers to schedule optimal queries. Suddenly you're not only managing unreliable resources and minimizing latencies you don't own, you're also a compiler or interpreter for a language with more than one valid query.
For some types of backing stores it may not matter (ECKRV's such as Dynamo, for example). For others it may matter a lot (Postgres). And I think a lot of server owners ship backends that maybe do 2x more querying than they have to, given the "best practices" and examples I see online for the NodeJs bindings.
I've heard the Erlang bindings are very good. I haven't tried them yet, as Erlang isn't very high on my list of tools to use these days (not because it's bad). Maybe they have a silver bullet.