GraphQL is relatively new and was created to serve as a better replacement for REST APIs. In principle, GraphQL serves the same purpose as a REST API. It provides a public interface for a data set with optional validation for data manipulation. The functional differences are quite profound, however, and they relate mostly to standardization.
It can be useful to think of GraphQL not as an API, but rather similar to a database engine, like MySQL or PostgreSQL. It’s a bit of a shift in thinking if you’re used to a regular API, but once you get the hang of it, it’s hard to let go.
Let’s take a look at some pros and cons of GraphQL.
Standard Query Language
Firstly, the QL in GraphQL stands for Query Language. If you’re familiar with SQL, it’s the same idea. It’s a fairly standardized way to express what you want or are trying to do, and it works everywhere.
This means as a consumer there’s only one Route, for everything, and as a creator, you don’t have to create Endpoints for most things.
It also means that as a consumer, you don’t need any documentation to use a given server. Similar to an SQL server, there’s a standard way to inquire about all of the data on the server and how it’s stored and formatted, and there’s a standard way to get exactly the data you need. Here’s an example:
On the left above is the payload that gets sent in the POST request. It’s simple and well organized, and data is returned in the same structure, formatted in JSON.
This means that if you know GraphQL, you can work with any GraphQL server without additional training.
Given that GraphQL is a query language, it’s possible to be much more articulate about what you want than with REST. This means you can do complex queries for a variety of data and get it all back in one request. Here’s an example:
This reduces both bandwidth and processing time.
A Foundation To Build On
If you want to build a REST API for your data, you’re almost always starting from scratch. With GraphQL, there are language-specific foundations to start with so you can get something built much more quickly and efficiently.
Drawback to GraphQL
“Limited” Language Support
If there isn’t a server built for the language you want to work with, it’s unlikely you’ll build a new one. It’s open source, so you COULD, but it would be a lot of work. I wrote “Limited” in quotes though, because according to Wikipedia, there’s pretty good language support.
Unlike a REST API, once you know the Query Language of GraphQL, you can simply query the server and ask it to describe the data structure and contents. This can greatly reduce the amount of time it takes to onboard a project.
With REST, you have to learn an entirely new system for every project. With GraphQL, you learn it once and can use it anywhere.
Even though I personally have far less experience with GraphQL than REST APIs, I already want to use GraphQL for everything. Standardized data queries are a gold mine of efficiency and productivity when working with cross-platform applications.
Camber Creative is a digital product design and development company, headquartered in Orlando, Florida. We’re an all-expert, fully-distributed team specializing in digital products for mobile, web, and the internet of things. We work with clients ranging from multibillion dollar enterprises to bootstrapping entrepreneurs. Come say hi on Twitter, LinkedIn, Instagram, or Facebook, or tell us about your new project.
Hexagon tumeric banjo bicycle rights. Deserunt commodo try-hard taiyaki marfa, live-edge cardigan voluptate pork belly hexagon laborum 90's poutine bespoke. Hella asymmetrical offal skateboard chia DIY actually mukbang flannel magna messenger bag 3 wolf moon letterpress minim coloring book. Voluptate vexillologist raclette pariatur vinyl. Post-ironic chicharrones irure jianbing incididunt mustache etsy organic PBR&B. Do cillum vaporware ennui venmo adaptogen cloud bread.
Sriracha tweed gatekeep ennui, messenger bag iceland JOMO magna in tumblr la croix.