Why GraphQL Needs an Open Federation Approach
Looking at the current API landscape, it’s evident that enterprise GraphQL adoption has grown from a niche technology for frontend developers to a key technology for helping architects and backend developers combine APIs and other services. Gartner predicted this momentum in 2021, reporting that only 10% of enterprises were then using GraphQL in production, but it expected more than 50% of enterprises to adopt it by 2025. Amid this rapid expansion, there’s increasing dissatisfaction with current approaches to composing data across different backends.
The Need for a Unified Layer
One reason for its growing popularity is GraphQL’s ability to function as a unified layer for all your data. Enterprises are handling more data than ever, using a variety of different backends. Often, these backends are distributed in the form of microservices or third-party APIs.
GraphQL emerged as a game-changer here, allowing for customizable data retrieval through a single request rather than having to chain or mix and match several requests to incoherent APIs (e.g., for REST APIs). This is where the concept of GraphQL federation comes into play, as shown in this diagram below.
Federation is the pattern in which individual GraphQL services are composed into a single GraphQL API that can be used as the entry point to access all data from underlying backends through a single request. Instead of sending individual requests to these backends, these requests are federated by GraphQL.
However, the current federation implementation is maintained by a single company, which leads to vendor lock-in, slows innovation and limits technology choices.
Pitfalls of Current GraphQL Federation
Apollo Federation is a popular solution for building a federated GraphQL infrastructure. It allows various GraphQL services to be combined into a single GraphQL API. However, while Apollo Federation has certainly set the standard for composing data in GraphQL, it’s not without downsides.
The Apollo Federation approach necessitates the use of specific Apollo-defined directives and types. These are typically available only when using Apollo technology for the underlying backends or using backend technologies that are compliant with the Apollo specification. This ties the GraphQL federation architecture to Apollo’s implementation.
This leads to a vendor lock-in scenario, where enterprises are dependent on Apollo for updates, support and the federation feature set’s evolution. This dependency curtails the freedom to switch to other technologies or to adopt potential innovations from the broader GraphQL community.
Open Federation Is Crucial for Innovation
At September 2023’s GraphQLConf (the first community-organized GraphQL conference in the United States), it was apparent that developers and enterprises are rooting for an open approach to federation. Not only for combining data only from GraphQL APIs — as is the case for GraphQL federation — but also for combining GraphQL with non-GraphQL specifications for APIs such as OpenAPI.
IBM company StepZen believes in democratizing federation, allowing different GraphQL services to support a common standard. Whether you use IBM or other technologies to build your GraphQL API, you shouldn’t risk having to use a single vendor’s ecosystem. As businesses continue to make significant investments in API technologies, an open federation approach is not just a strategic advantage but a necessity for continued innovation and growth in the API ecosystem.
When building StepZen (acquired by IBM in February 2023), we believed federation should work the same way for any backend. In The Case for a Federated Data Access Layer with GraphQL, StepZen co-founder Anant Jhingran explains how the approach works. As this pattern is getting more popular, there’s a promising new federation initiative called GraphQL Fusion that’s supported by the GraphQL Foundation and the broader community, including IBM. We look forward to seeing how this initiative and the larger community develop.
