| Gateway APIs: http://microservices.io/patterns/apigateway.html Assuming you've read that then I'd add the following. If you don't have something approaching a gateway, you're probably doing a big disservice to your users (assuming clients fetch data via API, rather than using a traditional render-on-the-server framework like Django or Rails). The value proposition of GraphQL is based on the assumption you're already doing things right by users, and its possible to fulfill the data requirements for a single page or app screen in a single API call. What this probably means is: * You have a custom endpoint per screen * That endpoint to either a) be versioned or b) support as many historical versions of your app as are in production * You might have a gateway per client (this is the full backend-for-frontend pattern) * Every time you add functionality, or change existing functionality, you're adding to what quickly becomes a huge set of endpoints What GraphQL promises (and delivers on) is the ability to get all the benefits of the backend-for-frontend pattern, without anyone ever having to write an endpoint specifically for a give client use case. The clients convert their data requirements into a query, and the GraphQL server returns the exact data you need, no more, no less. It requires some discipline when it comes to evolving the schema over time, but it works really really well. And when implemented intelligently has comparable performance to hand-crafted endpoints (I've written about how to approach this here: https://dev-blog.apollodata.com/optimizing-your-graphql-requ...) When you experience the front-end workflow of using a library like Relay or Apollo (both are GraphQL clients) and having perfect synchronisation with UI and data, it's a really magical moment. You end up in a world where you can just get on with building UI, it's amazing. |