How to Make GraphQL Work For You

We interview three API experts on the state of GraphQL

GraphQL, the API query language, enables you to return many resources in a single request. With an effective type system, GraphQL streamlines data fetching to explicitly what the client needs.

Ever since its public release by Facebook in 2015, GraphQL has ignited much API industry discussion. GraphQL Landscape now cites 84 companies adopting GraphQL in production, and there are 21 members on the GraphQL Foundation.

Public opinion of GraphQL remains quite positive, with communities and ancillary tooling extolling its benefits. Yet, compared to the 22,000+ estimated public APIs in existence, GraphQL adoption numbers only make up a minuscule fraction of total APIs.

Perhaps low adoption rates are evidence that GraphQL may not be custom-fit for every scenario. API owners may also find it challenging to adapt to GraphQL without majorly reforming pre-existing REST services. Nonetheless, there are some exciting wrapping capabilities, extensions, and tools that enable pre-existing API designs to work in tandem with GraphQL.

So, for this article, we brought in some experts to learn how they’re making GraphQL work for their environments. Below, API experts Devlin Duldulao, Senior Consultant, Inmeta, Didier Micoud, Software Solutions Architect, Expedia Group, Vrbo, and Diana Suvorova, Software Engineer, Uber, bring their domain expertise.

We’ll see why our panel is still excited about GraphQL, as well as their take on when GraphQL is better to use than REST. We’ll also discover how to combine GraphQL with existing environments and cover some favorite GraphQL tools. Hopefully, we’ll determine not only how to make GraphQL work for you but how it can elevate your developer program to new programmatic capabilities.

Why We’re Still Excited About GraphQL

Are people still excited about GraphQL? Gauging from our panel, the answer is an overwhelming “Yes.” As we’ve discussed previously on the blog, GraphQL can offer many advantages over the traditional web API experience.

For one, GraphQL brings usability benefits. Instead of requiring API consumers to ping different HTTP endpoints, GraphQL enables a single endpoint to accept multiple queries. Developers can also utilize a GraphiQL playground to run queries, both of which Devlin finds “really cool.” Devlin adds that GraphQL is efficient, especially in terms of state management.

Devlin Duldulao, Senior Consultant, Inmeta, weighs in on GraphQL capabilities.

“[With GraphQL], you will be able to easily manage your application’s local state together with your remote data,” says Devlin. “This means no need to install a state management library in your app that will require you to set up extra boilerplate.”

For Didier, they’re excited about utilizing GraphQL at Expedia to present their API in the most consistent and understandable manner.

“Our GraphQL approach also allows us to focus more on the capabilities we want to expose and less on the stack,” says Didier. “GraphQL will provide a way to bridge often heterogeneous internal domain APIs to various experiences.”

Diana notes that GraphQL appeals to front end developer users who want a more flexible, seamless integration. “As a front end engineer, I am absolutely thrilled about GraphQL,” says Diana. “GraphQL removes the need to have complex logic on the client to get all the data for the app.”

Diana describes how GraphQL solves issues like over/under fetching, removing the need to send irrelevant data to the client, as well as reducing confusion on how to filter responses.

Meeting the needs of API consumers and solving pain points for developers are goals we often encourage on the blog as Developer Experience (DX). It appears GraphQL is in line with the modern emphasis on DX for developer-facing services.

But GraphQL is about more than just usability for API product consumers; it has many advantages for web application development. By using GraphQL clients for React such as Relay or Apollo, you can interact with React Components, allowing front end developers to take control of their data models and remove unsavory dependencies in the process. According to Diana, this is “a huge win for the front end development community.”

When to Use GraphQL Over REST

Of course, GraphQL is not the only API style in use today. A 2017 ProgrammableWeb study found that 81% of APIs were REST designs.

The more recent 2019–2020 Developer Survey conducted by RapidAPI showed signs that other styles are emerging alongside REST. The study found 62.5% of devs are using REST in production, with 28.8% using webhooks, 6.4% using GraphQL, and 3.4% using gRPC.

A 2019–2020 Developer Survey conducted by RapidAPI showed signs that other styles are emerging alongside REST.

While it seems the vast majority of use cases are perfectly fine with REST, GraphQL may have its place for a particular subset of API providers. So, when is it better to use GraphQL over REST?

Devlin recommends first taking a critical look at your product or service and going with the right tool for the right job. “What are the business objectives? Every tool has pros and cons, and GraphQL is no exception to that,” says Devlin. Not all applications will require a format that was initially intended to resolve Facebook development concerns, Devlin notes.

Didier Micoud, Software Solutions Architect, Expedia Group, Vrbo, appreciates GraphQL’s extensibility.

Didier similarly acknowledges that both REST and GraphQL are relevant for various use cases. “GraphQL in itself is not a magic bullet that resolves all the concerns around building a robust API,” says Didier. “For me, it’s about the extensibility of the contract and mostly how we can compose features and capability as a single API endpoint.”

We’ve compared REST vs. GraphQL extensively on the blog, yet we tend to focus on technical attributes. Diana notes that the cost of implementation is a practical point to consider, surmising that a GraphQL API requires more significant investment.

“GraphQL has a relatively high up-front cost to get it up and running,” says Diana. On the other hand, REST has a more established community, with tools and best practices. Nonetheless, Diana believes “[GraphQL] is worth the risk if you anticipate multiple clients with different use cases or the product requirements are not fleshed out yet, and you need to design for flexibility on the API layer.”

Combining GraphQL With Other Environments

Some developers may desire to have GraphQL work in conjunction with pre-existing environments or other styles, like gRPC, REST, or Odata. When this occurs, GraphQL essentially acts as an abstraction layer in front.

One method is to wrap an existing service in GraphQL. Devlin suggests GraphQL could be utilized as an entry point to gRPC in a microservices environment, or as a facade to an older RESTful service, or potentially as a wrapper to an OData service.

Didier similarly views GraphQL as a helpful way to standardize the externalization of a suite of APIs in various design styles. “This is one of the reasons we [at Expedia Group] are going towards exposing our external API with GraphQL,” says Didier. “Our approach allows us to build an external executable GraphQL schema that resolves to new or pre-existing API with no regard as to how they are exposed.”

For Diana Suvorova, Software Engineer at Uber, GraphQL, and gRPC can live happily together.

Diana acknowledges GraphQL is flexible – the specification leaves room for leveraging back ends with different communication protocols, and even composing other GraphQL services. Diana feels the choice to implement it will come down to your schema scope and composition strategy.

“The main consideration before introducing a GraphQL layer into the pre-existing back end infrastructure would be the scope of the schema and the strategy of composing it,” says Diana. A local schema will be more accommodating to lightweight, tightly coupled designs with greater flexibility. Shared schema, on the other hand, “should closely follow the data model exposed by the upstream protocols,” says Diana.

In terms of technical details for creating a GraphQL abstraction layer, Diana notes there are nuances with each approach. However, the process is pretty self-contained: “converting one IDL (for example Protobuf) to another (GraphQL type definitions) and runtime query/mutation mapping to RPC or GET/POST requests.”

Migrating From REST to GraphQL

Some API providers may see the benefits of GraphQL, yet are entrenched within a previous design style, like REST. Though we’ve seen it is possible to create an abstraction layer for such services, this might not appeal to purists, as it introduces legacy code and added dependencies. So, is it possible for such services to migrate from REST to GraphQL?

Well, first off, Devlin accepts that GraphQL is not a fit for all companies. So, the question may be a moot point for many. The majority do not want to migrate an existing REST API or build a GraphQL API from scratch. “They would instead use REST because of its stability and for being battle-tested while GraphQL is still on its early stage,” says Devlin.

That said, there are still many instances of GraphQL being used in production by large companies. All our panelists highlight Github, who switched their public API to a GraphQL interface quite early on. Our panelists also highlighted Airbnb, who has been a vocal proponent of GraphQL. Having migrated much of its API to GraphQL, Airbnb saw better page load times, and improved developer experience.

Other GraphQL adopters include PayPal, Lyft, NBC, The New York Times, KLM, Airbnb, Yelp, Rakuten, and NBC. This Github repository also lists 30 official GraphQL APIs, as well as other unofficial API proxies and demonstration-only GraphQL services.

For the companies that want to make the switch, they will likely face adoption hurdles. For example, Didier notes how different API styles are often implemented on differing stacks. “REST-like services implemented in Java, Node or Kotlin can all be wrapped into a GraphQL executable schema, but it does not always make sense to revamp each and all of them as GraphQL APIs,” says Didier. “Lightweight wrapping of these existing services as
GraphQL executable schema [in a way] that can be reused” is an approach Didier is actively pursuing.

Diana also chimes in with logistical migration issues such as your rollout path, performance monitoring, the need to conduct A/B testing, and the lack of in-browser cache management.

“One aspect to call out for the front end part of the migration is the cache management,” says Diana. “With REST APIs, clients can rely on in-browser network caching. With GraphQL, it is no longer a workable solution. So engineers need to rely on different solutions.”

Diana’s point on solutions brings us to our next section on GraphQL tooling quite nicely…

Some Cool GraphQL Tools

When we interviewed the creator of GraphQL, Lee Byron, in 2018, he stressed the need for more growth in GraphQL tools to fill in the gaps. In recent years, we’ve certainly seen many GraphQL tools enter the market to answer this call.

On the blog, we’ve reviewed Graphcool for backend development, HyperGraphQL for linked data extension, GraphQL documentation generators, the GRANDstack build framework, Hasura, GraphQL frameworks like FlacheQL, and covered ten other GraphQL solutions and extensions here.

All our panelists recommended GraphiQL, the official in-browser GraphQL IDE, for interacting with API calls. This open-source sandbox environment can significantly improve API learnability.

To help with caching, Diana recommends Apollo GraphQL client for its in-memory cache. “The implementation is pretty good but does require some additional maintenance, especially in the case of mutations,” says Diana. Devlin also recommends Apollo.

Didier highlights the GraphQL Playground by Prisma Labs. “From a developer standpoint, the Prisma Labs GraphQL Playground desktop application is a must, especially when handling multiple environments.” For documentation, Didier recommends the APIs.guru GraphQL Voyager plugin for rendering the schema in a human-readable way.

Lastly, Diana recommends Rejoiner, a Java library that generates a unified GraphQL schema based on gRPC microservices. “It allows you to bootstrap a GraphQL service with a minimum effort if your back end infrastructure is built with Protobufs,” says Diana.

Final Thoughts

One thing is sure – GraphQL has hype. The aforementioned Rapid API Survey also found that 37.5% of developers had heard about GraphQL but were not using it – the highest percentage of awareness (without production use) of all surveyed technology categories. GraphQL evangelists have certainly done their legwork, and most API developers now view GraphQL as a reputable option in their toolbox.

In summary, we’ve found that GraphQL is:

Interactive: GraphQL is a useful schema for clients that utilize front end React-based web development.
Usable: GraphQL improves the developer experience by uniting API calls to a single endpoint.
Extensible: It’s possible to use GraphQL as an abstraction layer over existing styles to improve front-end usability and also simulate a consistent integration wrapping multiple API types.
Proven: GraphQL now has a track record in many production environments.

These points, along with GraphQL’s expanding tooling ecosystem to help circumnavigate issues like cache management, mean there’s a good chance GraphQL will work for you.

Yet, for now, it seems GraphQL will remain shelved until niche settings warrant it. The tried and true legacy of REST, and its proven use in scalable API development “on the scale of decades” is plenty of reason for many to stick to what is standard practice.

Our panelists acknowledge we are still early on with GraphQL, so it will be interesting to see how adoption rates trend into the future. Thankfully, Nordic APIs will be here, covering the API economy to fill you in!

Thank you to our panelists for sharing your knowledge. It’s an honor to present your ideas to our community in this fashion! In this article, we featured the three “D’s of GraphQL”: