4 ms·

While this post is supposed to be about GraphQL, it seems to focus more about the benefits of having a centralized request broker / gateway for your APIs and no

by meritt 8y ago

While this post is supposed to be about GraphQL, it seems to focus more about the benefits of having a centralized request broker / gateway for your APIs and nothing unique to GraphQL. Their rule of "AVOID NESTING OBJECTS, JUST RETURN IDS OF RELATED OBJECTS" definitely is missing out one of the core benefits of GraphQL: being able to fetch related resources in a single request. Feels to me like they decided to switch to GraphQL cause it's supposedly better but are still utilizing it exactly like you would a REST API.

joekur 8y ago
My understanding is that they are keeping their REST endpoints flat, however their gateway graphql layer can still respond with nested resources - it would require aggregating multiple REST requests together.
- andrewingram 8y ago
  Right, this is the approach I've always advocated. I don't mention it specifically in this post I wrote a while ago about optimising GraphQL, but my implicit assumption was that you're building your GraphQL server on top of an underlying platform: https://blog.apollographql.com/optimizing-your-graphql-request-waterfalls-7c3f3360b051 https://blog.apollographql.com/optimizing-your-graphql-reque... In real-world UIs, I've found that queries rarely end up being more than a few levels deep and are relatively easily optimised as long as your internal APIs can handle batches (easy for entities, harder for pagination). Additionally, even though the only-return-IDs-for-relations pattern means you can't utilise joins effectively, the upside is that you end up with much simpler database queries that area easier to optimise at scale. My rule of thumb was that as long as the query representing an entire screen could typically return in sub 100ms in production, it was acceptable (this was without any caching at the GraphQL level, which I had planned but left the company before I could implement it).
barrystaes 8y ago
> it seems to focus more about the benefits of having a centralized request broker / gateway for your APIs Exactly my thought. From article, about REST API: > Any API change had to be deployed simultaneously to all services using that API to avoid downtime, which often went wrong and resulted in long release cycles. Using GraphQL in a single API gateway, we would simplify the service landscape drastically.
- Udik 8y ago
  Why didn't they simply use api versioning?

by meritt 8y ago

joekur 8y ago

My understanding is that they are keeping their REST endpoints flat, however their gateway graphql layer can still respond with nested resources - it would require aggregating multiple REST requests together.

andrewingram 8y ago
Right, this is the approach I've always advocated. I don't mention it specifically in this post I wrote a while ago about optimising GraphQL, but my implicit assumption was that you're building your GraphQL server on top of an underlying platform: https://blog.apollographql.com/optimizing-your-graphql-request-waterfalls-7c3f3360b051 https://blog.apollographql.com/optimizing-your-graphql-reque... In real-world UIs, I've found that queries rarely end up being more than a few levels deep and are relatively easily optimised as long as your internal APIs can handle batches (easy for entities, harder for pagination). Additionally, even though the only-return-IDs-for-relations pattern means you can't utilise joins effectively, the upside is that you end up with much simpler database queries that area easier to optimise at scale. My rule of thumb was that as long as the query representing an entire screen could typically return in sub 100ms in production, it was acceptable (this was without any caching at the GraphQL level, which I had planned but left the company before I could implement it).

barrystaes 8y ago

> it seems to focus more about the benefits of having a centralized request broker / gateway for your APIs Exactly my thought. From article, about REST API: > Any API change had to be deployed simultaneously to all services using that API to avoid downtime, which often went wrong and resulted in long release cycles. Using GraphQL in a single API gateway, we would simplify the service landscape drastically.

Udik 8y ago
Why didn't they simply use api versioning?