GraphQL has come a long way since its 2012 introduction. From powering Facebook’s mobile applications to going open source in 2015, the query language has steadily gained popularity amongst developers. Mentions across Hacker News and StackOverflow have trended upwards (save some brief hiccups) — while GitHub repos with “GraphQL” in their titles have also multiplied.

Today’s apps are incredibly functional compared to those in the past. In particular, the world’s largest companies oversee massive databases, and users request information from those backends every second. Because these users are so plentiful, those requests generate immense overhead.

REST APIs excel at serving large quantities of data. However, they can be pretty heavy-handed with the data they grab per request. You must also make multiple HTTP requests to grab data from different sources. Companies use GraphQL in production to solve these problems. The client queries the server only for the data types and quantities required. Additionally, GraphQL can query multiple data sources with just one API call. The value proposition is clear — so how exactly have large companies adopted GraphQL? Let’s analyze some examples.

PayPal Leverages GraphQL to Boost Development Agility

Until recently, PayPal’s internal development processes were somewhat fragmented. Teams had no shared blueprint for crafting apps or tooling — rendering PayPal’s API-driven platforms inconsistent from a design standpoint. Additionally, merchants brought their own tech stacks to the table, which muddied the waters. Senior Software Engineer Shruti Kapoor lamented that PayPal had to provide an SDK compatible with each merchant’s preferred programming language. Such efforts were far from trivial. It’s noteworthy that instead of blaming external merchants, Kapoor touched on challenges stemming from internal processes.

Building a better developer experience started from within. PayPal has committed to GraphQL since 2018 — using it as a template for UI application development, while even migrating tooling support away from REST in many instances. Development teams now use GraphQL naming conventions, header standards, and error-handling approaches. Shared libraries and templates have become commonplace. And those SDKS? PayPal now ships a single, language-agnostic GraphQL endpoint for external clients.

Shoring up documentation both internally and externally has eased those transitions. Accordingly, PayPal maintains a learning center to help all developers seamlessly integrate new GraphQL technologies.

Also in the works is the launch of a singular Apollo Federation, which acts as a graph gateway. Per Apollo’s documentation, this solution is ideal for dividing one’s graph implementation across multiple backend services. Not only is this advantageous in distributed systems, but it also offers improved flexibility and scalability. It fits into our modern conception of multi-cloud and allows for simultaneous querying of numerous backing data sources.

Tools like GraphiQL and Playground have encouraged PayPal’s developers to experiment with their APIs and explore documentation. The team has fostered an internal Slack community for the language. Developers across Identity, Payments, and Compliance can now ship much faster. This means faster updates, feature introduction, and parity across all channels.

However, the GraphQL transition hasn’t been perfect. PayPal’s engineers have spent plenty of time adapting REST-centric tools to work harmoniously with GraphQL queries. That has come with a learning curve and ample time commitment. Additionally, lacking standardization has led to effort duplications across teams; error handling and authentication are a work in progress. PayPal’s teams hope to iron these issues out as their solutions mature. However, Shruti and her colleagues have continually praised GraphQL’s propensity to make developers more productive.

Netflix Also Reaps Productivity Rewards

In 2021, Netflix published a blog post detailing the company’s adoption of GraphQL. While recognizing the positive impacts of the “one graph to rule them all” approach (single entry point for accessing data), author Dane Avilla was quick to highlight Netflix’s alternative strategy. Their unique implementation leverages GraphQL microservices to create a fully-formed backend.

To accomplish this, the team uses a custom Docker image running atop a Graphile toolset. Graphite is particularly advantageous because it centers on both GraphQL and PostgreSQL. Netflix lauds Graphile’s performance, robustness, and extensibility. Netflix’s ultimate goal was to treat GraphQL like an enhanced API specification for building CRUD applications. Thus far, this has translated into faster development.

Using Graphile, internal engineers can expose a PostgreSQL dataset rapidly thanks to the containerized computing model. In other words, Netflix was able to package every Graphile library, dependency, and vital code into one compact container. By connecting that container to the database and pulling the appropriate Docker image, internal teams could experience GraphQL’s benefits without additional coding.

The team learned three lessons from this process. First, it was possible to use database views as an API layer — allowing for table modification and formatting without altering GraphQL schemas. Second, PostgreSQL composite types have allowed engineers to build strong GraphQL schemas even faster. Third, controlling client access to GraphQL queries has boosted control and flexibility at different developmental stages. Exposing only required functionality lets developers optimize other database queries.

This has been a boon for productivity, and the results seemingly speak for themselves. According to Microsoft, Netflix maintains over 600 production services and deploys over 100 times daily. That’s an impressive feat and speaks to the efficiency of this new development pipeline.

Shopify Shifts its API Strategy

In May 2018, Shopify first offered a GraphQL variant of its REST Admin API to external developers. This experiment has since led to the widespread adoption of GraphQL across the company. Accordingly, its successful implementation within Shopify’s leading API product has only proven GraphQL’s viability.

Previously, client-server data mapping had always been a challenge at Shopify. Whenever externally-facing REST APIs were updated, external developers were required to update their code in response. This burden on both sides was becoming increasingly apparent — especially when matching static code with unstructured JSON responses. That mix of hard coding and assumed type casting created extra work for Shopify’s engineers.

GraphQL has solved this issue via strong typing. Predefining types directly within the schemas—which makes synced data mapping a relative breeze — has kept clients on the same page with minimal effort. Senior developer Maryam Fekri shares that complex JSON mapping is no longer needed. The lack of statical types within mobile applications makes those applications friendlier, allowing the backend to shine without becoming an obstacle.

However, Shopify is aware of the issues posed by excessive complexity. It’s possible to over-complicate GraphQL schemas and incur additional overhead within an application. To combat this, Shopify developers adhere to a “calculated query cost” limit. Each field has a cost value, and limiting those fields (keeping a schema’s total score below a certain threshold) reduces performance hits.

GitHub Values Greater Specificity

GitHub’s adoption story shares a common thread with others around the industry. The world’s largest development platform shifted to GraphQL so users could request only the data they need during an API call. GitHub is in a unique position; the platform is integrated with numerous external services, and streamlining the querying process reduces friction. Single API calls for complex data requests are inherently less costly than multiple round trips are. GitHub’s GraphQL API supports several simple and complex queries dependent on need.

Additionally, GitHub’s original API was designed to be hypermedia-driven. This meant that constant communication between client and server was required to gather information. Naturally, this high level of activity generated a number of responses— which GitHub soon discovered were very bloated and required *_url hints for easier navigation. This was convoluted. GitHub also shared client complaints on the REST API’s inflexibility. Multiple calls were needed to fully access a resource. This created a troubling situation where data was both too plentiful and less meaningful to those requesting it.

Auditing issues further accelerated the switch to GraphQL. Internal engineers found it hard to examine endpoints, determine resource pagination, ensure type safety, and quickly generate documentation. Client generation was also tedious.

Reducing payload sizing and making data more intelligent were top priorities for GitHub. What began as a minor feature exploration led to the creation of a GraphQL server — in turn paving the way for its widespread implementation. Using social features as a testbed, the team later expanded GraphQL’s production scope. The team reveals that it’s been using GraphQL for quite a while and have transitioned more moving parts over time. Its existing services have since been updated to work effectively with GraphQL.

Airbnb Achieves 10 Times Greater Agility at Scale

Airbnb’s story is headlined by a close partnership with Apollo, whose CLI tooling played an immense role in unlocking Airbnb’s GraphQL implementation. The process involved the development of a test application to prove GraphQL’s type safety and frugality when it came to data fetching. This resulted in the formation of a reliable technical foundation.

Engineers at Airbnb established a GraphQL backend and paired it with a Typescript frontend. This mixture of type safety and efficiency led to a staged migration across Airbnb’s services; this meant replacing longstanding REST requests with GraphQL equivalents. Engineers at Airbnb noted that this wasn’t a complete rewrite, as this route would be too costly and time-consuming. Next, the team used GraphQL’s aliasing and adapters to ensure data integrity.

Once all components were transitioned to Apollo, it was then possible for Airbnb to poll Apollo for API data and React for client data. Boilerplate code has been removed in many instances, and Airbnb can now use caching to a much greater effect when serving pages. GraphQL has allowed the company to experiment with service workers’ query prefetching. Generating content is now much quicker, positively impacting user experiences across Airbnb’s services.

Coursera Lands on GraphQL After Copious Experimentation

Coursera’s adoption of GraphQL has been a years-long technical journey. The company embraced JSON early on with its APIs, later shifted to Scala and played around with specialized “experience-based APIs,” then built its own Naptime REST framework. However, Naptime and REST soon proved to be problematic. Clients found flattened lists of data difficult to work with. It was also challenging for developers to maintain Coursera’s URL syntax over extended periods of time.

GraphQL offered solutions to these issues. By pairing the language with its microservices infrastructure, the team crafted a GraphQL assembler service to make it easier to move between those services. The resulting schema is unified and communicates effectively with Coursera’s dozens of services. This has supercharged data fetching across the platform.

Today, Coursera favors schema-driven development. And there’s an emphasis on keeping those schemas simple. To prevent feature bloat, only critical components are added to it. While the company’s developments have always been data-driven, engineers realized that product requirements and API functions could mismatch by very fine margins. Understanding how business logic was processed in relation to client and server has been key to furthering GraphQL’s implementation. Overall, the GraphQL schema has been an essential unifying layer for Coursera’s engineers, who work today to better optimize their APIs.