GraphQL has been my holy grail for this. Easy to grok, easy to build types for various languages and keep everything in sync.
GraphQL has been my holy grail for this. Easy to grok, easy to build types for various languages and keep everything in sync.
GraphQL is awesome if you are a frontend engineer. GraphQL is terrible if you are a backend engineer - https://bessey.dev/blog/2024/05/24/why-im-over-graphql
Eh, a lot of those problems have solutions, and some are more theoretical.
Yes, if you design your graph to allow something like `tags -> relatedTags -> relatedTags` ad infinitum you can let your clients build a performance problem. So why not have just a top-level `getRelatedTags(tagName)` query? Or a `getRelatedArticles(articleId)` query? Just because you can have things nested doesn't mean you need to have all the things nested.
The bulk of our REST API is backed by some Rails gem, which allows for a `fields` param. Those `fields` can be deep. As in you could write `getComments?id=1234fields=user.orders`, but do you know what we do? Don't expose `orders` as a field on `User`.
> Don't expose `orders` as a field on `User`.
Why not use Open API then?
- I've never found any openapi/ swagger generated client as easy to use as a graphql client
- graphql solves a lot of other problems when querying microservices
- graphql gives us PR-level alerts on whether any schema changes are safe
- graphql actually manages our front-end query caching / updating quite nicely