6 ms·

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

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.

jtmarmon 6y ago
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.
- Kaze404 6y ago
  > 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).
- striking 6y ago
  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.
  - akra 6y ago
    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.
- dropofwill 6y ago
  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.
  - gitgud 6y ago
    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
Envek 6y ago
+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.
- mattmcknight 6y ago
  The same advice applies to REST.
- ZephyrBlu 6y ago
  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?
- thom 6y ago
  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.
thom 6y ago
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?

jtmarmon 6y ago

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.

Kaze404 6y ago
> 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).
striking 6y ago
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.
- akra 6y ago
  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.
dropofwill 6y ago
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.
- gitgud 6y ago
  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

Envek 6y ago

+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.

mattmcknight 6y ago
The same advice applies to REST.
ZephyrBlu 6y ago
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?
thom 6y ago
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.

thom 6y ago

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?