44 ms·

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, y

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

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