Hacker News Reader

> Which kind of feels worse from a complexity standpoint from where we were previously, especially if the queries are dynamic instead of largely static.

Agreed on increased complexity, but isn't the point largely the dynamic queries? You setup all this extra architecture, but in response you don't have to write as many "controllers" with custom API response. Just let the frontend request what it needs via GraphQL. So it's more upfront work, less down the line. Or is writing all the API level sanitizers and query resolvers more work?

> Agreed on increased complexity, but isn't the point largely the dynamic queries? You setup all this extra architecture, but in response you don't have to write as many "controllers" with custom API response. Just let the frontend request what it needs via GraphQL.

What about cases like: "The user should only be able to see the data of their own submitted requests, when the parent document is any of the given statuses: FOO and BAR and there is no related BAZ request that's been saved and is approved in the system by the manager. In cases, where the BAR request exists, ..." (a long list of other edge cases that might affect the visibility of any particular document or even individual fields in some form)

My point is that in many systems the cases where you might want to just give someone the ability to retrieve the data they need is rather limited. So in those cases the dynamic nature of everything is more of a risk than anything else.

At large scale, the queries you can handle are limited by the indexes you have in place, and you can’t index everything. So you already have to think about which queries you’ll really need.

There’s also caching, which is another side of the same coin as indexing. You may want to cache certain common/expensive queries. You’ll probably need to think about the granularity of what gets cached, and how to invalidate it. Hard problems for a dynamic, “query anything” API.

Also you probably need to control which data can be retrieved. KronisLV covered that.

Indeed in most cases replacing simple code with GraphQL only adds complexity.

The old approach has been more like this:

  [client] <- RESTful request -> [your API] <- Your data fetching logic -> [DB] <- SQL query (with parameters) -> [DB]

Replacing your data fetching logic with GraphQL just means translating your JS/Python to GraphQL - something that isn't as flexible, turing complete, or predictable (in execution).

If anything, I'd prefer to go the other way and get rid of SQL altogether - let me express queries in code:

  books.filter(book => book.author === "Alice")
       .group(book => book.year)
       .map(group => group.reduce(({ sum = 0 }, { year, sales }) => ({ year: year, sales: sum + sales }), {}))
       .sort((a, b) => b.year - a.year)

which translates to:

  SELECT year, SUM(sales) FROM books WHERE author = 'Alice' GROUP BY year ORDER BY year DESC

but is far more composable, debuggable and potentially more deterministic - I'd like more control over query execution planner, not less.

> except that they forgot to include the bit that actually talks to your data store

Which stands to reason given that GraphQL was designed for talking to services, not data stores. It was built for BFF. The backend is responsible for talking to the data store, as usual.

[client] <-dynamic GraphQL query-> [GraphQL resolver] <-boring old RPC/REST/whatever-> {Set of backend services}

But doesn't that essentially mean that you've simply shifted the problems of fetching data (overfetching, N+1 problems and resource expansion) a little bit to the right, without solving the actual issue?

It would technically be faster because of lower latency between services in the same data center and sending the final results to the user in one go, but at the same time if your DB is hit 50 times to service that request, you still have a problem.

Essentially you just give the client the ability to run dynamic queries (with the complexity of which, the resolvers and their logic, you now need to deal with), without actually improving anything else, at the cost of noticeably increased complexity and yet another abstraction layer.

That tradeoff seems like a tough sell to me, much like an SQL engine that's not tightly coupled with a solution to actually store/retrieve the data would be like. Then again, there are solutions out there that attempt to do something like that already, so who knows.

> It would technically be faster because of lower latency between services in the same data center and sending the final results to the user in one go

Which is a pretty big deal when you have practically the whole planet as users, many of whom are found where low latency is a luxury.

> but at the same time if your DB is hit 50 times to service that request, you still have a problem.

Maybe. Or when you are Facebook maybe you don't care. Just throw another datacenter at the problem.

> without actually improving anything else

They found it improved discoverability for designers and non-technical folk.

> That tradeoff seems like a tough sell to me

If your organization doesn't look like Facebook, I imagine it wouldn't sell. It's very much designed for a purpose.

> Which is a pretty big deal when you have practically the whole planet as users, many of whom are found where low latency is a luxury.

This is an excellent point!

Different scales will need vastly different approaches and the concerns will also differ. Like the anecdotes about a "Google scale problem", where serving a few GB of data won't phase anyone, whereas some companies out there don't even have their prod DBs be that size.

Another thing to consider is that while a query may be dynamic during the discovery/development phase, once it is solidified in the application for deployment it becomes static and is able to be optimized as such.

If you are a small team of developers that is no doubt a lot of unnecessary indirection. When you are small you can talk to each other and figure out how to create a service that returns the optimized results right away. At Facebook scale, if everyone tried to talk to each other there would be no time left in the day for anything else.

Conway's Law strikes again.