I’ve enjoyed watching GraphQL’s evolution during my time as a Forrester analyst. While I can’t say it is a super popular topic in my client calls, I have seen a noticeable uptick in interest. This has happened while objections to GraphQL adoption are being alleviated: monolithic graphs, poor developer experience, and performance issues. Let’s review how each of these barriers is being addressed.

Monolithic GraphQL Becomes Federated

The original GraphQL implementation was one giant, monolithic graph for the enterprise. This couples everything to everything, creating an operational problem wherein an outage anywhere in the enterprise could ripple through the graph. The enterprise team supporting GraphQL operations lacks visibility into and ownership of those services surrounding it, as Netflix famously wrote about in two blogs.

Apollo Federation first addressed this a few years ago. It allows GraphQL to be split into subgraphs, each owned and operated by different domain IT teams. Unfortunately for buyers, Apollo switched this from an open-source license to proprietary, preventing competitors from using it. There are attempts in progress to create an open standard to federation. Wundergraph responded with a federated product under the Apache 2.0 license. ChilliCream and others developed GraphQL-Fusion under the MIT license. A subcommittee of the GraphQL Working Group is also developing Composite Schemas, a federation specification for the GraphQL Foundation. Hasura has yet another option.

GraphQL’s Developer Experience Is Improving

The GraphQL developer experience (DX) has been very far behind that of REST API development, but there have been steady improvements. Federation, of course, improves DX by giving application development teams more autonomy from other teams building on the graph. Writing a new schema by hand is very error prone; now there are linters to automate enforcement quality standards, error checks, and backward compatibility checks from vendors such as Apollo and Inigo.

In the past, connecting to a new data source often meant writing custom code in a GraphQL server. Apollo recently made Apollo Connectors generally available, a way to connect a graph to REST APIs through declarative configuration instead of coding resolvers. This not only makes it easier to connect to service endpoints, but I also expect this approach will make it easier for future AI to generate fully connected GraphQL implementations.

From Performance Concerns To Performance Gains

GraphQL has always had opportunities to improve performance by consolidating several REST data fetches into one query fetch. But performance concerns also arise from the fact that you’re adding yet another layer between the client and the back ends. Nonetheless, the GraphQL ecosystem has been making headway with performance.

Apollo has recently converted its query planner from JavaScript to Rust, improving performance like C++ while maintaining memory safety. The Apollo Connectors described above also boost performance by eliminating the need for a GraphQL server supporting those connections. Since federation runs different parts of the graph on different servers, it also provides more opportunities for parallel processing and optimized query planning.

The worst performance risk, though, is recursive or redundant queries that can DOS a database. Although this problem remains, there is better tooling today to protect from it. More API management vendors support GraphQL-specific policies to limit query depth. Startup Inigo specializes in GraphQL security policies, including query depth and rate limiting to protect back-end infrastructure. It also offers advanced observability of runtime queries to diagnose the root cause of problematic ones. Apollo provides a query planner to introspect how queries will execute and a means to declaratively present unique subset views of a graph to different users. Fine-grained caching is also available from vendors.

I spoke with one user who believed screen rendering went from 5 seconds to 1 or 2 seconds when employing solid schema design and caching in GraphQL. Another found up to a 95% reduction in latency by migrating to Apollo’s Rust-based router in the travel industry, where latency could mean the loss of millions of dollars in revenue.

Pick The Right Use Case

GraphQL mainly supports front-end developers, replacing the back-end-for-front-end pattern, but not much beyond that. This leads to caution about going overboard. The wisdom of exposing it to third parties remains to be seen. That recursive query risk is easier to deal with when the client is one of your employees. When it’s a customer, for example, you have much less leeway to tell them to stop making that query. I have talked to vendors who made client-facing GraphQL and regretted it for that reason.

Shopify provides another caution. It recently pushed customers off REST and onto GraphQL. User reaction has not been all positive. Some of this was self-imposed by Shopify: incomplete documentation and not migrating all data from REST to GraphQL. But negativity was mostly due to GraphQL itself, notably using it for write operations. The problem with write operations is that — unlike reads — they often must execute in a specific order. GraphQL does not have a way of knowing that order. A single REST API can hide this orchestration from clients using iPaaS. GraphQL pushes that complexity onto clients.

For example, one Shopify user wanted to upload a product image with alt text and position information, attached to multiple product variants. This had been one REST call. With GraphQL, it now takes six calls: Stage the upload, upload the image, send media info to link to that image, etc.

GraphQL is like every other tech: It’s not a silver bullet, and it has tradeoffs. As its tooling matures and becomes viable for more and more organizations, enterprises must never lose sight of the bigger picture: GraphQL is here to stay, and adoption will grow in the coming years, but it will never fully replace REST.

AI: A New Horizon For GraphQL?

I look forward to seeing how this continues evolving. AI creates an interesting potential. For AI to leverage APIs as tools, it needs to know the relationship that one API has with another. GraphQL’s schema provides context of how entities from different endpoints relate to each other. The growth of agentic AI may provide a tailwind for GraphQL adoption and a new common use case beyond just supporting front-end UX.