[meritt]

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]

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]

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-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]

> 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]

Why didn't they simply use api versioning?