GraphQL Growth Explodes but so Do Problems Federated Graphs Solve

GraphQL is a query language that allows users to find and request data from servers in a way that they can specify the type of data they want through the API in a more precise way than through other types of API structures. A federated GraphQL platform allows for different sub-GraphQL schemas to be used in a decoupled way but through a single API interface of the GraphQL platform. They both have and will continue to become enormously popular.

Statistics recently released by the Gartner report reveal how more than 60% of enterprises will use GraphQL in production, up from less than 30% in 2024. By 2027, 30% of enterprises using GraphQL will use GraphQL federation, up from less than 5% in 2024, Gartner reported.

So, federated GraphQL adoption will, according to Gartner, increase fivefold during the next three years while GraphQL adoption will “only” double.

Why?

Because Federated GraphQL solves a major problem: so-called API sprawl. This phenomenon occurs when numerous GraphQL and other APIs proliferate throughout an organization.

Gartner’s statistics highlight the effectiveness of GraphQL as a very clever and reliable way to conduct queries via an API. However, a potential issue arises when users within an enterprise begin to utilize their own GraphQL or other APIs for various legitimate purposes in parallel, leading to the unwieldiness the sprawl causes. Before delving further, let’s establish clear definitions for GraphQL and a federated GraphQL platform.

Gartner defines GraphQL thusly:

“GraphQL is an open specification for implementing APIs, which allows consumers to specify the content they request from a service. It provides developers with a type system to define data and a server-side engine for querying specific data elements they need. The specification also provides a query language for API consumers to define queries and mutations to update, and subscriptions to request notifications of changed data.”

Federated and Less Sprawl

👁 Image

👁 Image

Returning to the issue of API sprawl, Federated GraphQL offers a solution by consolidating disparate instances. Take Netflix, for example; after adopting GraphQL, they discovered numerous instances scattered across their infrastructure. Concurrently, they utilized various other API types, such as GRPC and REST APIs. Initially, they attempted to centralize GraphQL within a single API or monolith, which proved restrictive. However, the GraphQL federated gateway, provided by Apollo, effectively addressed this challenge.

As Geoff Schmidt, CEO and co-founder of Apollo GraphQL explained to me during KubeCon + CloudNativeCOn, GraphQL — like SQL — is a query language and specification rather than a specific piece of software. While there are implementations of GraphQL, such as Apollo GraphOS, GraphQL itself is a standard that defines how clients can request data from servers, Schmidt said. It’s akin to how SQL is a language used to interact with databases, but various database management systems implement SQL, such as PostgreSQL or MySQL. So, GraphQL can be implemented by different platforms and frameworks, but it’s not a standalone software project in the same sense as a database management system, he said.

“The adoption of GraphQL, especially with the concept of GraphQL federation, has helped streamline data access across various microservices within enterprises, promoting self-service platforms and API efficiency,” Schmidt said.

Because GraphQL is a flexible specification, GraphQL does not compete with or replace REST APIs. This is because they can be used in conjunction with each other. As reported, GraphQL’s schema definition language can be used in conjunction with REST in a few ways. For example, a federated GraphQL layer can abstract REST endpoints and be integrated as a separate GraphQL schema.

This architecture is often called a supergraph or a federated graph — which was introduced by Apollo in 2019. It creates an abstraction layer that can replace most backend or frontend Backend-for-Frontend (BFFs) APIs or experience APIs.

As Schmidt explained: “There’s a distinction to be made. GraphQL isn’t akin to a piece of software like a SQL database; instead, it functions as a feature or language. SQL, in contrast, operates as a standard means of querying databases, with various SQL databases such as Postgres being tangible software entities. It’s essential to understand that GraphQL, much like SQL, serves as a method of querying data rather than a standalone software product.”

Regarding GraphQL’s inception, Facebook didn’t release actual GraphQL code but rather a specification similar to IBM’s release of SQL in an academic paper. “Since then, the adoption of GraphQL soared, especially with the concept of GraphQL federation gaining traction. This approach emphasizes the need to integrate disparate microservices seamlessly, promoting a self-service platform within enterprises,” Schmidt said. “The essence lies in creating an API platform that optimizes API usage, countering the prevalent issue of disjointed APIs plaguing many organizations.”

What alternatives do people have apart from manually piecing these together? Schmidt said: “Well, they end up writing extensive code,” Schmidt said. “It could be termed an experience API, integration API or a Backend for Frontend.”

Regardless of the label, the code-writing process typically involves crafting a Java, .NET, or Node.js process, custom-built to serve as a processor server, Schmidt said. Essentially, it receives API requests from the client, instructing it to fetch data for various functionalities. Subsequently, it calls numerous backend services, consolidates the data, and delivers it as an API-to-API proxy or integration. “This approach consumes an increasing amount of enterprise resources and often results in a multitude of disjointed solutions, each addressing only part of the problem,” Schmidt said.

Consequently, disillusionment sets in as the complexity grows exponentially. As an analyst aptly put it, this process resembles a continuous mess spiraling out of control. However, there’s hope. “I recently heard a customer remark that adopting GraphQL transformed their situation from spaghetti code to well-structured layers, likening it to moving from spaghetti to lasagna — a significant improvement,” Schmidt said.

Apollo has emerged as a leader thanks to its pioneering work in developing the Apollo Federation and Apollo GraphOS, “the premier federated GraphQL platform,” Schmidt said. “While others attempt to replicate our success, creating a viable federated GraphQL solution is no easy feat. It necessitates a robust query planner and significant investment, akin to the challenges faced by Oracle in establishing SQL as the standard. Such endeavors require substantial resources and are beyond the scope of small or medium-sized teams funding to complete.”