GraphQL helps us build apps faster. Data is more discoverable, easier to query, change, and evolve over time. Most companies that adopt GraphQL typically take one of these four patterns:
- Client-only: Client teams that are excited to take advantage of GraphQL’s client-centric data-fetching capabilities may add a GraphQL API within their own application for the convenience of wrapping other APIs.
- Backend for Frontend (BFF): BFFs add a new layer to the stack so each client (for example, web or iOS) can send queries to a service that is tightly coupled to its specific user experience. GraphQL can be a natural fit for building out this intermediary layer.
- Monolith: A company may develop a single, large GraphQL API for all client to use with either shared ownership between teams or with a dedicated team to manage this API.
- Multiple overlapping graphs: Different teams within a company may develop their own service-specific GraphQL APIs. Teams usually try to split these APIs by types or use cases, but there is often some amount of overlap between the graphs.
Each of these approaches to running a graph in production can get you up and running and are great first steps toward leveraging GraphQL’s benefits across a company. However, over the last few years we’ve spent helping companies like Glassdoor, PayPal, Expedia and NYT to design, improve, and scale their GraphQL efforts, we’ve realized that each of these architectures break down over time and create pain points when trying to consolidate and scale GraphQL across teams. That’s why we’re writing the GraphQL at Enterprise Scale free ebook: to teach you how to scale GraphQL in the Enterprise with Federation and Apollo Studio.
Download the first version
The first version of the book just launched today! You can download it at apollographql.com/guide. It covers advanced topics like:
- The most common pre-consolidation GraphQL patterns and where they break down over time
- How Federation help you scale APIs, get a unified view of your data, leverage existing infrastructure, and ship code faster
- When to consolidate your GraphQL efforts with Federation
- The role that GraphQL champions play in helping your company serve your graph as a product
What’s coming next?
This is only the first version! In future updates to the book, we’ll explore:
- How to migrate from a monolith, BFF, overlapping graphs, or client-side only GraphQL data layer to Federation
- How to understand, plan, and design a Federated graph for your clients
- Strategies for caching GraphQL data
- Advanced testing patterns
- How to monitor your graph performance
- and so much more!
How do I get notified?
If you download the current version of the book, we’ll keep you posted as to when we publish new chapters.
Thank you!
We’re really excited about this resource. If you have a topic you’re struggling with or you’d like to learn more about specifically, feel free to reach out to us at solutions@apollographql.com. If you need our advice on scaling your GraphQL efforts today, we’d love to hear from you. Click here to contact sales. Happy querying!
