| There are patterns that can get you the same benefits without having to use GraphQL. Even on a REST API, you can achieve the same pros > - It makes working with describing the data you want easy
> - It can save you bandwidth. Get what you ask for and no more You can describe the fields you need (and I assume that is what reduces the bandwidth) GET /users?fields=name,addresses.street,addresses.zip > - It makes documentation for data consumers easy I don't think so in practice. You can see Shopify's GraphQL documentation [1]. If anything it is more complex than their REST API docs > - It can make subscription easier for you to use Not too different from using something like SSE or even websockets and every decent web framework seems to have a decent implementation > - Can let you federate API calls So many ways to achieve this at the application layer (which is what GraphQL federation does with a Router). In the python world this could be separate WSGI apps or racks in ruby? And makes no difference if done at the load balancer level. [1] https://shopify.dev/api/admin-graphql/2022-07/enums/localiza... |