Hacker News new | past | comments | ask | show | jobs | submit login

So let's take the most trivial case. Pretend you can query a Person object with both familyName and personalName.

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.

Very much true. My point though is that I'd expect that complexity to get "built in" at a lower level over time — analogous to how we can submit SQL to a DB server, which has a query planner built-in to figure out how to actually execute the query. App developers don't have to write a SQL query planner.

I've been reading the stuff folks have recommended here. I can explain comonads to a teenager but even I thin that these programming models are pretty intense.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact