GraphQL: For When REST is Just Too Slow
GraphQL is a query language that allows for highly customizable queries against Application Programmer Interfaces (APIs). GraphQL usage is on the rise and is currently being used in production level applications by PayPal, Netflix, Shopify, Github, and Airbnb and many others.
Though often referred to as a technology, GraphQL is a specification, a set of rules and concepts that allow developers to build their own implementation of the query language. Because of this, GraphQL leaves much room for developer innovation and creativity.
So what is GraphQL? Let’s start with the similarities to REST as REST as the current standard for trading information with a web applications. REST and GraphQL both utilize HTTP requests for fetching data. And both are server-, language-, and framework- agnostic.
It’s here that the commonalities diverge, as GraphQL was built as an alternative solution to the REST architecture.
Back in 2012 Facebook users were moving from primarily desktop and laptop usage to iOS and Android applications. Up until this time, Facebook put the bulk of their engineering resources into web development. Mobile resources needed something new, a faster, more lightweight and custom way to transfer large amounts of data instantly, GraphQL co-creator Lee Byron has explained. Something potentially faster and more nuanced was needed.
Because GraphQL was always intended to quickly serve a high volume data of data across a largely-used application at lightning speed, it requires a revolutionary way of fetching data.
Consider the basic workflow for a REST HTTP Get request is as follows:
- Request the data from a source
- Receive the full response object back
- Manipulate the response object to pull out only necessary data
- Repeat again if data from another endpoint is needed
REST focuses on multiple endpoints and thus making multiple calls in series, which can get expensive and slow down web pages that are either very busy or data-heavy. Rather than prioritize multiple calls to get every piece of data available, then parse through everything to find the necessary items and implement accordingly, GraphQL focuses more on a detailed oriented organizational query structure set up and only fetches necessary data.
Postman’s recently-issued “2022 “State of the API” report shows people involved with APIs continue to be excited about GraphQL, and that use of it as architecture rose slightly, from 24% to 28% of those surveyed. –Lawrence Hecht.
How Does GraphQL Work?
GraphErrQL Software Engineer Josh Merrell says of the GraphQL data modeling setup, “The main element when considering this is that GraphQL can be heavier on the development side as you have to define the schema.” The schema, which is comprised of GraphQL types (string, boolean, integer), specific to GraphQL, specifies the data types the query results should return.
It’s no more labor intensive than say, working with TypeScript though and includes a similar, thoughtful consideration of what data points be included in the query and their associated data types. Building a GraphQL schema also helps build an understanding between members of an engineering team, between teams, or for future engineers as now the data being queried for is clearly stated right there in the code rather than something to be searched for in the response object.
The resolver function, also included in the schema, is where the HTTP request to the data is made. That can be anything, depending on the data per the application. In the case of the image below, which is a simple request to a third-party Star Wars API, a simple Axios get request is used.
The image below shows a sample schema set up in Node.js/ Express.
After doing extensive work in GraphQL during the development and development of GraphErrQL, Mariah Talicuran, software engineer from the GraphErrQL project does admit though that, “ramp up time is lengthy and can turn some developers off.” Jerald Stephenson, also a software engineer contributing to GraphErrQL echoes that, “It just depends on the developer.”
Working with GraphQL and Rest
Gwen Phillips, a Software Engineer from GraphErrQL said that, when working with GraphQL and REST, “it doesn’t have to be either or. You can have a combined GraphQL and REST application. Some companies are modernizing gradually and transitioning some areas of the application to GraphQL first to make it more palatable for developers.”
There is no perfect solution and there are trade offs for everything. GraphQL is better for complex systems and microservices, it defines a data shape, it’s a strongly typed language, and it solves the problem of over and under fetching. GraphQL doesn’t have a native caching solution though there are server and open source options. Parsing through GraphQL’s AST can get incredibly complicated and the error contextualization out of the box isn’t the best.
Meta no longer maintains GraphQL as there is now the GraphQL foundation that is in place.
