In the last couple of years, developers, startups, and enterprises alike are adopting GraphQL at a staggering rate. The passion in the GraphQL community for the technology has it spreading like wildfire.
Companies like GitHub, Airbnb, Shopify, Expedia, and Trulia were early adopters of the technology and they have seen impressive results with it.
Let’s start by going back to the beginning. In 2012 Facebook wrote the GraphQL specification and the first implementation. They released it as an open-source project three years later. Today they are still using GraphQL and the “unified data graph” to enable developer productivity and help them grow their business.
You may wonder, ‘what is GraphQL’? According to GraphQL.org, GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn’t tied to any specific database or storage engine and is instead backed by your existing code and data.
Many view GraphQL as an alternative to other API architectural styles like REST and RPC. It can support many data sources, including databases and APIs, which can then be accessed through a single query. As REST APIs are proliferating, the promise of accessing them through a single query language and hub is alluring to many companies, big and small.
GraphQL allows for greater flexibility with database queries. One query can be constructed to fetch data from multiple endpoints, so you get all the data you need with a single call. This declarative data fetching turns out to be especially helpful on mobile devices, where an abundance of network requests may consume limited battery and bandwidth resources. The intuitiveness of the query language makes it simple to express the data requirements and operations of even the most complex application.
GraphQL also allows for introspection, so developers can retrieve the schema associated with a GraphQL endpoint. This functionality will tell you the kinds of queries are supported and can be used for the auto-generation of API documentation. Unlike RESTful APIs, which can support this functionality through blueprints and OpenAPI Specifications, GraphQL endpoints guarantee this functionality since the schema is mandatory.
Many companies have now shifted to using GraphQL in production with great outcomes. Although the technology is relatively new, the rate of adoption across various industries is impressive. Here’s how some companies are using it:
I’m sure you’ve seen the headlines “Airbnb is Moving 10x Faster at Scale with GraphQL and Apollo”. In 2019, Airbnb software engineer Brie Bunge said about 5.8% of all Airbnb traffic involves GraphQL and she expected that number to reach 10% by the end of last year.
The travel marketplace took an incremental migration approach and shifted its entire stack to utilise Apollo & GraphQL with React Hooks, allowing them to move away from Redux. While only 10-15% of their frontend code contains business logic, the rest was data handling. GraphQL helped them to regain productivity by reducing non-business related code.
GraphQL was originally thought of at Airbnb as a competing strategy, not a complimentary one, so the migration to this new technology was delayed. Eventually, they reopened the discussion because the benefits of GraphQL—and Apollo, specifically—were too compelling to ignore. By using the two, they would get better documentation, more flexibility in field selection, and cross-platform development without dependency on backend engineers to iterate.
With the help of GraphQL, they are now moving exceptionally fast and automating as much of the process as possible, improving their productivity and performance along the way.
GraphQL has become Shopify’s technology of choice for building APIs. Here’s what their Mobile Lead Developer had to say about their use of GraphQL:
GraphQL gave us big wins by reducing the number of round trips made to the server and giving us a well defined and strongly typed schema to work against. GraphQL has also played a major role in helping us find and fix bugs before impacting our merchant’s daily operations.- Kevin Barnes, Shopify Mobile Lead Developer
Shopify loved this technology so much internally, that they rolled out GraphQL for their partners, giving them full power to orchestrate complex merchant tasks, with simplicity and efficiency.
GraphQL is transforming Expedia’s goals to create seamless customer experiences across their frontend platforms. GraphQL is becoming the standard for customer-facing applications and internal and external APIs.
Continuously improving customer experiences across 200 booking sites and 25 brands isn’t easy, and it requires the creativity and careful orchestration of thousands of developers and dozens of backend service teams.
While operating multiple technology stacks over the past decade, most of which were built in-house, Expedia has mainly relied on REST services to service its mobile and web applications. These architecture choices have increasingly slowed down teams since onboarding, configuration, and duplication of efforts have become major roadblocks in efficiency and focusing on customer experience.
The rise of native mobile clients added more complexity, leading to delays to access to the latest features on mobile, a poor customer experience, duplication of effort on the developers managing it.
“Much of the mobile app team’s work had nothing to do with creating experiences for customers because they were constantly figuring out which API to call, onboarding those APIs, and dealing with version and endpoint changes. All of these distractions required additional resources and slowed our feature delivery.” – Dan Boerner, Product Manager at Expedia Group
Despite dedicated resources, the underlying problem persisted and continued to affect the customer experience.
“The client-service complexity became a real bottleneck,” Boerner added. “Asking a native app team to keep track of tens of service teams so they can escalate production issues became a source of real frustration, and a real distraction for a team focused on creating great customer experiences.”
GraphQL was then brought in to connect the entire organization’s app data and services into one central data graph. Their goal: a single graph, understood and discoverable by all teams, built to empower a new set of cohesive customer experiences.
With a single entry point for clients to connect to, client teams were freed from directly connecting to multiple services or managing communications across multiple, extended teams. Meanwhile, service owners could easily expose their data via a schema that allowed clients to retrieve exactly the portion of data needed with a simple query.
Expedia Group turned this effort into a formal initiative, which now serves as the foundation of their modern application development stack, and supports their strategy to create seamless customer experiences across all their client platforms.
Today, Expedia Group is moving away from using their previous RESTful API strategy, which was causing hardships for development teams, in favour of a GraphQL approach that better lends itself to their organisational and development needs. This has allowed for more time to focus on customer experience across all platforms while shipping new features more quickly. Adopting a common data graph while moving away from heavy clients with tight bindings to REST APIs has been transformational for Expedia.
Expedia is continuing to adopt GraphQL across mobile web, iOS, and Android.
Anybody who slings code for a living knows GitHub. The website is the repository of record for millions of developers and has had a significant impact on the way software is created and shared globally.
GitHub needed GraphQL to solve a very specific problem: managing its customers’ requests for special data structures.
In 2017 the company was having problems around its REST API. The API, which was about seven years old, grew in popularity and key companies began to ask for special additions to the API payloads. GitHub accommodated as best they could, but after a while things became unmanageable. A better solution was needed. As Kyle Daigle, GitHub’s Director of Ecosystem Engineering told ProgrammableWeb this:
“We did some proof of concepts and ultimately got pretty excited about GraphQL because it allowed us to give integrators access to data in a format [where] they could define what data they were actually looking for.”
GraphQL is the primary way that GitHub exposes itself to the world at the API level and they’re helping other companies take the plunge. A quote from the company’s blog states:
“GraphQL represents a massive leap forward for API development. Type safety, introspection, generated documentation, and predictable responses benefit both the maintainers and consumers of our platform. We’re looking forward to our new era of a GraphQL-backed platform.”
GitHub is just one company that’s gone “all in” with GraphQL, but with the millions of developers visiting their website, their influence in adopting this technology may have a significant impact. Some will say “if it’s good enough for GitHub, it’s good enough for us.”
Trulia unifies its REST APIs into a single source of truth using GraphQL. The problem that led Trulia to adopt GraphQL was one that’s common to many companies. Each of the company’s mobile applications and its website had a special way to access data. The disparity was having a growing impact on developers.
Trulia decided that instead of having it so that each application uses a particular set of REST APIs, all applications — native mobile and web-based — would use a single GraphQL API.
One of the interesting positive side effects of the decision was that moving to GraphQL as the single source of truth for Trulia promoted more collaboration between groups and departments. Previously, development groups were siloed because each application had its own set of APIs for accessing the data that needed to be supported. Implementing a common GraphQL interface made it so that everybody had to be part of the implementation initiative. Because of using GraphQL, Trulia’s data has become more consistent.
Here’s how other early adopters are using it:
- LinkedIn organised their “economical graph” of relationships between users, using a unified graph to hide complex systems behind a simple GraphQL API. They are leveraging the technology to enable a consistent access experience across online, nearline, and offline environments.
- Onegraph showed a very interesting approach where they combined various popular 3rd Party APIs into a single unified GraphQL API. With the help of their plugin users, they can now power their apps or import data directly into Excel for calculations.
So, how can you benefit from the Universal Data Graph?
One thing that’s consistent around the stories of companies adopting GraphQL is the power and flexibility it allows developers to have as they define the data they want, as they want it, hastily against a unified data graph. It’s an interesting value proposition, particularly given the fact that mobile devices are becoming powerful enough to perform data aggregation chores that previously could only be executed in the datacenter. GraphQL is well-positioned to become a go-to technology for data access across all platforms. As shown, there is a lot of value in strategically leveraging this technology over the typical RESTful API route especially when data needs across platforms are similar.
CTOs who’ve already adopted this technology believe that at some point, it’s likely that most companies large and small will need to adopt the data graph as the primary way to represent data on the Internet. The advantages are too compelling to do otherwise and not adopting the data graph puts a company at risk of losing competitive advantage.
Barriers to entry
But there are still additional disadvantages that come along with adopting a new technology. All the bells and whistles aren’t readily available. As a CTO of a big corporation, you may want:
- A unified way to access all data sources within the company from a multitude of clients
- A central point of governance to set and audit granular access rules
- A toolkit that helps onboard existing data sources to the “unified data graph” as easy as possible
- A toolkit that simplifies maintaining a data graph strategy
For small to mid-sized companies, you may not have the resources to solve one problem that many of these larger companies have solved all on their own. Many larger companies implemented security on their own. They built their own Validators, Complexity Analysis, Fraud Detectors, Rate Limiters & Authorisation logic.
These companies understood the gains and put in the resources to solve all these problems on their own, and many other companies are looking for similar solutions.
Making GraphQL and the UDG accessible to all organisations
Soon, we will be introducing GraphQL functionality directly into our API management platform by creating the Universal Data Graph. We listened to the GraphQL community as we crafted an offering which allows for all the upsides of leveraging GraphQL while getting rid of the large hurdles and concerns about GraphQL adoption. Our offering aims to:
- Create an easier way to design and implement GraphQL services, including doing so through a no-code approach
- Easily allow for the addition of authentication to GraphQL services using Tyk’s existing full-authentication capabilities
- Manage GraphQL authorisation by allowing for fine-grained access rights to individual field access
- Aid in the battle against GraphQL-focused DDoS attacks
On top of the features above, we also have the most performant GraphQL engine ever built. This means you get fully-featured GraphQL build tools integrated directly into the Tyk Dashboard, plus, your queries will run lightning-fast, outperforming all the other GraphQL engines available out there today.
Before we end, if you want to try Tyk’s Universal Data Graph (UDG), you’re in luck because we’re offering a free two-week trial! Tyk’s UDG is available in the open-source gateway, so you can get instant access via Tyk Cloud, or you install our open source gateway in your own infrastructure.