Hacker News Reader

Comment by striking | Hacker News Reader

I really wish GraphQL weren't named in a way that seems to cause confusion about what it's for and its relation to SQL.

It's not a replacement for SQL. It's a replacement for REST. And the intent is to provide a statically typed, holistic interface and encourage best practices in API design. It's also quite nice because there are clients that plug into it and offer substantial benefits as a result, like Relay.

There are lots of ways people write resolution methods for GraphQL, and this article provides a good number of them. You can think of them as query optimization approaches if it helps. But it's not quite like SQL, where in SQL you say whatever you like and it just gets figured out. GraphQL forces an amount of intention and asks schema writers to consider the most concrete use cases possible rather than just enabling super generic ones.

View on HN

I don't think GP is confused.

GraphQL lets you write queries for objects. This fundamentally changes how you architect your app and database.

In a REST API, you turn known a finite list of known query patterns (endpoints) into DB queries, which you can test, hand-write, and optimize.

If you let end users query your object model, it takes far more work to ensure they don't do something very expensive.

The amount of work it might take is generally proportional to the amount of flexibility you give the user. You don't have to (and in fact are generally discouraged to) offer end users a degree of flexibility that makes your life harder. To be especially clear about this: do not mirror your DB schema in your GQL schema; it's not worth it.

But, even should you have to support a complex schema, the fine article showcases a number of great mitigations that cover basically every possible issue.

The only issue that I don't think is covered here is that collecting all this data up and sending it all at once can sometimes be slow or even time out, and there's no mechanism really to allow GraphQL to defer the collection of some fields until they're ready. It's coming very soon (in the form of @defer; to the spec, to graphql-js, to Relay, and to others) but it's not quite here yet.

There seems to be a lot of Engineering practices you need to understand and follow to use GraphQL effectively which makes me naturally suspicious of the technology. I do judge technologies for most use cases (not niche) by how easy it is to shoot yourself in the foot - the easier it is the less I rate the technology for broad usage.

The article assumes simple schemas as well - a parent with many child relationships in this article could lead to some complex resolvers. Unless I misunderstand the article many of the strategies here are in ORMs (e.g. lazy subselects) which often don't perform as well as a crafted query given the still multiple roundtrip's to the db. They also require more code, and exhibit branching which means that performance is a function of the users query. If you know your user that's fine, but then again I don't see the advantage vs a straight REST or RPC call which would result in simpler code anyhow. It seems to work IMO in cases I guess when service isn't critical, your model/schema is simple, or you prefer flexibility of data access over reliability/predictability.

> If you let end users query your object model, it takes far more work to ensure they don't do something very expensive.

How so? There are existing tools that prevent both N+1 problems (Dataloader) and complex, recursive queries (depth and complexity limits).

My cynical take is that frontend devs will do this anyways, just with api calls from the client and probably repeat the same calls a few times per page load. But hey, the backend metrics look great, who cares that the page takes 10 seconds to load.

Totally agree, Graphql pushes the problem to the backend, where arguably, it's easier to mitigate after bottlenecks are discovered.

Seems like it postpones premature optimisation... which is a good thing in my opinion

If GraphQL asks one to consider the most concrete use cases possible... what is the point? I'm aware it's just an alternative to bespoke endpoints, REST or otherwise, but the problem is it promises a lot of stuff that is really hard to actually fulfil in reality. At which point, what is it actually getting you?

+1 on this. GraphQL is a great way to actually decouple your API from underlying database schema. When you start thinking not about specific REST endpoints, but about API data model in general, it turns out that it is much better to hide many database-level specifics and provide more natural data model to clients.

The same advice applies to REST.

It seems dangerous to assume that GraphQL decouples your API from the database, considering that there are still performance implications.

If your GraphQL schema requires expensive queries because it has a different schema than your database, is it really decoupled?

But you're still actually getting that data from somewhere (maybe even several places). You absolutely have to consider deeply the performance characteristics of complicated operations across these datastores to be able to deliver a sane API. There's only so much you can hide when you allow arbitrary joins and filters etc.

Reply on news.ycombinator.com