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.
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:
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).
Reverb.com - Chicago, IL - Full Time / Intern (Local position)
We're a heavily curated marketplace for musical instruments and gear. Check us out - http://reverb.com
We've got lots of positions open. Our user-base continues to grow and we need a team to keep up with it. We're looking for product-minded self-starters. You don't have to be a musician/gear-head, but it's a plus!
Looking for skills in: Rails, iOS, Android, UI/Mobile Design, Frontend/Javascript, Elastic Search, Marketing, Customer Service
Really cool, but it seems I don't have authorization to manage the issues of someone else's repo on which I am a collaborator. Maybe just a limitation of Github's api?
