Take a shot every time you read about how [Insert name of technology here] is Dying™. GraphQL finds itself the latest subject of this narrative. Claims of its downfall, the notion that it has “crashed and burned,” are all over dev spaces.
Needless to say, this is not a very safe drinking game.
GraphQL isn’t dying. It’s just no longer the novel, bleeding-edge technology; no longer the tech Twitter poster child. The hot debates and spicy takes in online forums are dead, but GraphQL itself has matured into a robust, well-understood tool, well-used in production, and well-entrenched in solving real-world problems.
GraphQL has finally become boring.
The Virtues of Being Boring
Boring is stable. Boring is reliable.
GraphQL might have plateaued if you’re looking at StackOverflow Trends…
Still in a very strong position, I’d say.
…but I’d argue this perceived decline is the calm after the storm of the initial hype cycle, allowing for a more nuanced understanding of its role and purpose within dev ecosystems.
Allow me to explain.
In 2015, GraphQL was the It technology. In 2023, it’s just another tool in your toolbox.
I think the disconnect here stems from an initial misconception. During GraphQL’s initial hype cycle, it was heralded across developer circles as the REST API killer, poised to obliterate its predecessor. As the dust settled and practical implementations unfolded, with more and more orgs using it in production, we discovered a rather obvious truth — GraphQL, like any technology, wasn’t a silver bullet.
We figured out exactly what GraphQL did exceptionally well — It was the undisputed choice if you needed API composition and federating your data dependencies. Its knack for bridging organizational divides between frontend and backend teams, as a shared contract everyone could agree upon, was unmatched. Needed to create mobile apps and account for slower devices and networks? GraphQL was your best bet.
We figured out which use-cases fit GraphQL the best and which did not, we figured out its gotchas and tradeoffs, and we figured out how to deploy it in production. Ergo, it became boring.
And that’s okay.
After 8 years, GraphQL being ‘boring’ isn’t a step backward; it’s an indication that the hype behind it has died while GraphQL itself has, dare I say, won.
GraphQL is Now Mainstream
More and more companies now use GraphQL in some form or the other.
According to the 2023 Postman State of APIs survey, GraphQL has only ever grown in YOY Popularity, taking the top 3 this year.
Shopify, for example, found the strongly typed structure that GraphQL schemas provide useful in smoothing over client-server data mapping. Previously, any change to an external-facing REST API at Shopify would break client apps, needing clientside devs to statically type a field and cast the over-the-wire JSON response to it every single time, increasing risk. GraphQL schemas being strongly typed provided a foundation that fostered reliability, type safety, and effective contract management within (and without) their ecosystem. For most orgs (like GitHub), that and the intuitive querying mechanism for the frontend is all they’ll really need for a GraphQL adoption to pay dividends.
But what if you have different teams who all use different ‘boring’ technologies, but are siloing knowledge? In this case, it doesn’t matter that you’re only using stable, reliable technology; siloing means you’re still taking on increased organizational risk.
This is where Federated GraphQL can help. Federation gives you the ability to bring together disparate APIs (gRPC, REST, SOAP, and even GraphQL), microservices, and other data dependencies into a unified interface i.e. a single GraphQL endpoint for every team within the organization — and is probably the use-case driving GraphQL adoption in enterprise, where you have unique challenges that most developers will never face: composition without sacrificing scalability (an actual problem, this time), central governance, team autonomy, or adaptability to evolving requirements.
With federated GraphQL architectures, any data added to the organizational data “pool” instantly becomes available to all teams. All companies like Walmart, Zillow, and Netflix had to do was compose any new data source (which could absolutely be other federated GraphQL APIs, mind you.) into a central graph, and all of it was immediately available for every team (who could now work autonomously without dependence on other teams’ structures) to query and come up with new and exciting business uses. This federated architecture provides flexibility without having to aggressively refactor or create bespoke new interfaces, and allows for the establishment and enforcement of unified data access policies, validation, auth mechanisms and protocols, and, of course, monitoring oversight that helps in identifying potential bottlenecks, and ensuring adherence to industry-specific regulations like GDPR, HIPAA, or other data protection laws.
GraphQL carves out unique niches rather than serving as an all-encompassing substitute for REST APIs. With the rate at which web development is evolving, a few years down the line you might have a unique problem that just happens to align perfectly with GraphQL’s inherent strengths. Heck, I’ve even seen an example of a frontend team using the GraphQL schema to keep track of the company tech debt via custom directives, meaning their backend teams rarely, if ever, had to go into the frontend codebase to plan refactors. A particularly novel organizational use-case.
Not bad for a technology supposedly on life support.
Looking To The Future
Listen, if all you take away from this is that GraphQL is not dying, but none of these potential use cases really sound compelling right now…trust your gut.
You could use a torque wrench to hammer in a nail, if you really wanted to, but it’s probably not going to be worth the infrastructure investment you’ve made, nor the operational headaches you’ll now have to take on.
Similarly, if all you have is a small team with a CRUD app, you shouldn’t shoehorn in GraphQL when a REST API would suffice — and in that case, OpenAPI REST is the “boring” technology you should be adapting right now.
However, if you envision your org or the app growing, anticipating multiple data dependencies or even federated architectures, adopting GraphQL could be a strategic move — and a tool like WunderGraph could help you get there.
WunderGraph is not one but two products, and which one you choose depends on your most pressing need at the moment.
WunderGraph Gateway
If all you need is to manage multiple disparate APIs, all with their own styles, auth protocols, architectures — WunderGraph Gateway is what you want. This is a free and open-source (Apache 2.0 license) Backend-for-Frontend framework that can bring together all of your disparate data sources, whether they’re SQL/NoSQL DB’s (including DBaaS like PlanetScale), ORMs like Prisma, SOAP, OpenAPI REST or GraphQL APIs, Apollo Federation, and even OIDC/non-OIDC compatible auth providers (OpenAuth, Auth0, etc.) — letting you add them all as a simple dependency array, and generating fully-typesafe clients from them for your frontend.
The best part is that while WunderGraph uses GraphQL in your dev environment (introspecting all of your data sources and consolidating them into a single virtual graph that you define GraphQL operations on to get the data you want) no GraphQL is ever shipped to the client, nor is a GraphQL endpoint ever made public. Instead, WunderGraph uses persisted queries. Any arbitrary GraphQL operation you write against the virtual graph is hashed and then saved on the server, only able to be accessed by the client by calling for the hashed name. The WunderGraph BFF server has a list of known hashes — as many Persisted Queries as you define — and will only respond to client requests for valid hashes, serving them as JSON over RPC, with a unique endpoint for each and every operation.
All the devex wins of adopting GraphQL, with none of the drawbacks. You get blazingly fast stale-while-revalidate caching strategies, and prevent rogue users performing drive-by dumps of your database by reverse-engineering your public GraphQL API.
WunderGraph Cosmo
If you know what you’re doing and a Federation V1/V2 architecture is indeed what you want — WunderGraph Cosmo is for you. This is an open-source (Apache 2.0 License) platform for GraphQL Federation, without vendor lock-in. It is a fully self-hostable solution (you retain control of all data), a drop-in replacement for Apollo GraphOS, built on open standards that includes everything you could possibly want to build, manage, and collaborate on federated graphs at scale. It’s an all-in-one solution that contains a schema registry that can check for breaking changes and composition errors, a blazingly fast Federation V1/V2 compatible Router, graph visualization, and an analytics/distributed tracing platform for federated GraphQL.
For enterprise use cases, licensing and data governance (to ensure compliance) are critical — and Cosmo being under an OSI approved license (Apache 2.0) and fully self-hostable makes it the best choice for enterprise adoption of federated GraphQL. Best of all — if you’re already using Apollo Studio/GraphOS for managing your federated graphs, you can migrate over with one click.
In Summary…
The reports of GraphQL’s death have been greatly exaggerated.
GraphQL’s transition to a stable workhorse comes as no surprise — this is just what success looks like. A new technology is overhyped, navigates past it, surviving, becoming a reliable tool in the developer’s arsenal, and solving specific, real-world problems. Acknowledging GraphQL’s perceived plateau in trends is not a declaration of its decline; rather, it’s a testament to its maturity.
In fact, GraphQL is poised to become even more important as diverse API styles become increasingly prevalent. The ability of GraphQL Federation to stitch together various APIs, microservices, and data sources into a coherent and federated structure holds immense promise for organizations. At scale, Federation is the best tool we have for building interconnected systems that can efficiently tap into a shared data pool without compromising the independence of each team or service.
OSI-approved open-source tools like WunderGraph (Cosmo, or the Gateway) not only make it easy for enterprises to adopt GraphQL without licensing hurdles, but make it easier to work with diverse, disparate, evolving technologies without giving up on data governance and distributed autonomy.
Top comments (1)
TIL, a lot of people are still using SOAP (: