To be honest, I didn't know what to think of GraphQL when I first heard of it. I was watching Netflix engineers talk about scaling their microservices with Node.js when one of them mentioned he worked on GraphQL in its early days at Facebook.
Enamored by its name and its neat connected dots logo, I checked out its landing page and was mesmerized by their succinct self-description in the hero section. From the type definition and a declarative json-like query, we get exactly the results we asked for - without delivering more data than necessary and without any roundtrips.
This REST alternative, though it breaks from the easily understood URL-centric conventions, offers a few advantages to its adoptors.
Why Create a GraphQL Server?
GraphQL solves a few client side issues, some of which are glaring exposed by a general overuse of Redux, particularly in React applications. Perhaps you've heard that people (myself included) are using Redux for absolutely everything, even if their application state is trivial. The issue with this is basically that people are using airstrikes to kill a mosquito. Even Redux author, Dan Abramov, is annoyed by its widespread overuse.
Hm, good idea Dan! Fortunately your colleagues at Facebook have created something which helps alleviate the state conundrum by fetching exactly what clients need - no more and no less.
No more overfetching or roundtrip API calls
With a single endpoint the server gives the client all of the data they need to render a particular view, greatly simplying the amount of application state that needs to be configured. Add on features like persisted queries, batching, and subscriptions, and you have a super efficient GraphQL backend.
Imagine that you have to make 5 distinct REST endpoint calls in order to gather enough data to render the front page of your app. You probably have to overfetch data - dozens of fields lost in the surrounding air as heat because you only needed a single integer from one of the responses. Light from a star 6 billion lightyears away landed on a solar panel, became the energy that courses through your computer, and then got thrown away.
This declarative data fetching also means that clients will not need to make as many roundtrip data calls, say to refresh a page or gather more entries in a feed. They would just send a smaller query to do exactly that.
Note that GraphQL and REST are not mutually exclusive, you may certainly configure your server to work with both. This can be done by adding a single endpoint responsible for responding to graphql requests or by wrapping your REST API with a GraphQL server.
Data exploration
In my opinion, data exploration is one of the coolest features of building a GraphQL backend. When you setup a GraphQL server you can configure it to serve a GraphiQL editor (note the i) to test out your queries in development. You can even expose this route on production in order to give users a way to play with your data for their own applications. This in-browser IDE could serve as an tool for onboarding new engineers or letting your team explore data sets in an easy, declarative way. No more combing through MySQL's amazing workbench or relentlessly entering cURLs.
There are several open GraphQL APIs you could explore, including Github, Hackernews, and Reddit.
In a previous blog post I consumed the Yelp REST API in order to create a coffee map. It turns out that they also have a GraphQL API open to developers who opt in to their beta.
There are, of course, a few security concerns with allowing anyone to send queries to your backend. Fortunately, Max Stoiber put together a neat article describing how he improved the security of the GraphQL API at Spectrum.
My Thoughts
Over the past few weeks I've been digging into the GraphQL specification and some helpful libraries that make developing with it a blast. The Apollo team, for example, has created several utilites and numerous blog posts that have been extremely helpful to my digestion of GraphQL.
Apollo provides client-side libraries that make constructing GraphQL queries easy. They provide tools that make putting together a schema straightforward. Also, they provide an engine that gives per-query performance tracing, error tracking, and caching. I recommend reading their blog if you want to learn pretty much anything about GraphQL
I wrote this post in order to gather my thoughts regarding GraphQL and see if any new ideas pop out from them. To get in some practice with building your own GraphQL server, check out this article.
If you want a neat, thorough video course, I recommend Stephen Grider's GraphQL with React: The Complete Developers Guide on Udemy. This is how I got my start learning about it.
Until next time, graph on.
Top comments (2)
Thanks for your post. I'm triying to move to graphql with angular 2. do you hace tips for this challenge?.
Heya, thanks for your response! While I am unfamiliar with Angular, the Apollo team has a GraphQL client you could use. Check out these docs apollographql.com/docs/angular/. They would cover all of the client-side binding info you'll need to interact with a server that 'speaks' GraphQL.