Search for a command to run...
Senior Software Developer with 11+ years of experience in building and leading important projects, specializing in Ruby on Rails and complex domains like billing and subscriptions. Strong collaborator, aligning technical execution with business objectives.
No comments yet. Be the first to comment.
GraphQL was open-sourced by Facebook in 2015, and since then, the debate between using traditional REST APIs versus GraphQL APIs has taken off. After a few years, we now have a clearer picture of the reasons why many large companies have chosen to migrate from REST to GraphQL:
Performance improvements
Better developer experience
Enhanced development process
Improved scalability
Let’s explore these motivations in greater detail.
Netflix adopted GraphQL to speed up Monet, their internal system for managing the creation and delivery of ads across external publishing platforms.
Even simple pages on their frontend needed to pull data from a wide range of sources. They initially tried denormalizing data on the backend to improve loading times, but it became a problem since not all pages need all the data, and they ended up running into network bandwidth bottlenecks.
To fix this, the Netflix team introduced GraphQL as a middle layer between the frontend and their REST APIs, which provided the following benefits:
They saw an 8x performance boost, since with the GraphQL middle layer the majority of the data flows between servers within the same data center, resulting in reduced latency in comparison with direct network calls from the browser.
They could reduce the page load of some pages from 10 MB down to just 200 KB, thanks to GraphQL letting the client request only the data it actually needs.
Similarly, Shopify could reduce the number of round trips made to the server in their Admin API built in GraphQL. Shopify believes the improved performance adds a layer of stability since the multiple server trips can slow down the app and make it feel unresponsive, which isn’t great for developers building on their platform.
Shopify took advantage of GraphQL’s strongly typed schema, great tooling, and built-in documentation to give their partners everything they needed to easily handle complex merchant tasks.
Tools like GraphiQL, a graphical interactive in-browser IDE for GraphQL, make it easier for developers to explore the API and access documentation without digging around.
On top of that, strongly typed schema provides superior tooling, which allowed Shopify to provide improved code intelligence and generation, and the ability to detect potential issues before sending a query. It made development more straightforward for developers.
LinkedIn accelerated API development by 90% by moving their Integrations and Partnerships APIs to GraphQL.
Each customer looking to integrate with them had a different set of product needs, especially when it came to data and how it was retrieved. They tried to overcome this challenge by building new APIs only when necessary and by supporting REST API projections, a GraphQL-like approach to return only the needed data.
But even with that, the development cycle was still long and repetitive. Switching to GraphQL solved that. Customers could now explore available capabilities through the type system, and new use cases could be supported simply by writing new GraphQL queries, no need to build entirely new endpoints!
GitHub had a similar experience. After GitHub launched their public APIs, integrators began to request specific additions to the API. The GitHub team started adding those data points to the API, but over time, the responses became bloated and harder to manage.
In addition, GitHub’s feature development and REST API development were handled separately, so after delivering a new feature, developers needed to figure out how to implement that functionality via REST APIs, which could lead to duplicated work and bugs.
GitHub optimized their development process by using GraphQL as the single interface for both the platform’s features and external APIs, eliminating the duplicated work and allowing integrators to use external APIs since the launch of new features while letting integrators leverage GraphQL’s features to request exactly the data they need.
As APIs and the teams who build them grow, complexity increases and maintenance becomes more difficult.
One way to handle this is by implementing distributed APIs using a Federated GraphQL architecture.
Booking.com used GraphQL to introduce a unified data layer for their accommodation services, a single entry point for accessing all relevant data.
But as their GraphQL service expanded, their GraphQL team was overwhelmed with merge requests and service owners struggled to maintain clear ownership of their data and schemas.
To fix this, Booking.com moved to a Federated GraphQL setup, where each team could own and manage their part of the graph independently. That brought back a sense of structure and made scaling much more manageable.
Similarly, Netflix also used Federated GraphQL to migrate their iOS and Android apps from a legacy API monolith to GraphQL services owned by the domain teams, introducing a more modular backend.
To safely migrate hundreds of millions of users, Netflix developed tools that ensure confidence in the migration process, such as AB testing, replay testing, and sticky canaries. The migration was divided into two phases:
Phase 1: They added a GraphQL Shim Service on top of their legacy Falcor API, enabling client engineers to move quickly to GraphQL without being blocked by server-side migrations. To evaluate the impact, they ran an AB test with 1 million users and compared metrics like error rates, latency, and render times to assess the effectiveness of the new GraphQL layer.
Phase 2: they retired the GraphQL Shim and legacy Falcor API by transitioning to Federated GraphQL services. They ran replay tests to ensure the functional accuracy of GraphQL responses by comparing the new services to the Shim, and used Sticky Canary experiments, an infrastructure experiment where customers are assigned either to a canary or baseline host for the entire duration of an experiment, to understand the overall perceived health of user interaction.
After several successful experiments, Netflix fully migrated to the new GraphQL-based architecture.
All in all, the way big companies have embraced GraphQL shows just how powerful it can be compared to traditional REST APIs.
GraphQL helps boost performance by cutting down on data transfer and latency. It improves the developer experience with its strongly typed schema and solid tooling. And it makes the development process way smoother by giving teams more flexibility in how they build and interact with APIs.
On top of that, GraphQL’s support for federated services makes it a great fit for growing teams and complex systems, helping organizations scale without losing control.
From Netflix to Shopify, LinkedIn, GitHub, and Booking.com, it’s clear that GraphQL has earned its place as a go-to solution in modern API development, offering a scalable, efficient, and developer-friendly approach to building applications.