Nic Hampton
writes on January 10, 2018
Happy 2018 fellow learners! It’s a little chilly here in Portland, but even in our brief winter break, we at Treehouse are still chasing the feverish pace of web development, trying our best to sort out passing trends in the industry from those technologies which will fundamentally change what we teach our students. I found a clue to future recently in the form of a quote from Sacha Greif, one of the co-publishers of the 2017 State Of JavaScript Survey:
“…I would say keep an eye out for GraphQL. It’s the technology that has the largest interest ratio while still having a fairly low number of actual current users, which probably indicates a sizable portion of the ecosystem learning GraphQL in 2018!”
If I had to guess (and here at Treehouse, we do) I’d have to say he’s right. In 2018, GraphQL is poised for a dramatic adoption from the web development community, and learning how to work with it will become one of the new requirements for junior developers in the tech industry. But what sets GraphQL apart from everything else can learn today, and just what is GraphQL anyway?
[Tweet “This year, GraphQL is poised for a dramatic adoption from the web development community”]
It’s easy to believe that the only type of API there’s ever been is a REST API. If you learned web development in the past 5 years, a REST API is probably the only type of API you’ve used. Less a technology or framework than a set of general principles and guidelines, the idea of a REST API was first proposed by Roy Fielding in 2000 as a way to make API’s more accessible and easier to use than the other standard formats of the time. These simple guidelines and principles made it possible to easily integrate outside resources into other web applications, and early adopters of REST API principles, such as Amazon Web Services, Flickr, and EBay, have become indispensable parts of the internet.
But REST API’s have always had some problems. In a REST API, a URL is dedicated to a specific resource, and the data returned from that resource is fixed. This works well for small questions or large questions that can be reasonably foreseen, but as the questions we ask the API become larger and harder to predict, the number of requests we have to make to several different endpoints in a REST API can slow down an otherwise fast web application.
Enter GraphQL as a solution. GraphQL is a typed, structured query language on top of an API that allows developers to communicate more information about the data they send and receive. What does that mean? Consider a fictional API on a city’s demographics. Let’s say we want to make an app with this API that gives the total number of people who own pets in a given neighborhood.
“GraphQL is a typed, structured query language on top of an API that allows developers to communicate more information about the data they send and receive.”
In a REST API, we might start by making an initial request to a “city” endpoint for a list of city blocks. We’ll wait for that information to come back, then filter the blocks that come back by area to get our desired neighborhood. Once we have our desired blocks, we can make a new set of requests to a “blocks” endpoint, one request for each block, to get information on what houses are on those blocks. Maybe the “blocks” endpoint was designed to return limited information on the people that live in those houses too, but to find out if each of those people owns pets, we need to make dozens of requests to another “persons” endpoint for details. That adds up to a lot of requests, even if we speed up the process by running what requests we can in parallel.
But with GraphQL, we’re going to make a request to the “city” endpoint, and with that request, we’re also going to send a query that lets the endpoint know we only want blocks from a specific neighborhood. We only need to know a list of houses for each block, so we’ll specify that in our query as well. Then we’ll make a request to the “houses” endpoint with another query that asks for a list of residents in each house, and specifies that we only need to know if each resident owns a pet or not. If we’re lucky, the API might be designed to only have a “city” endpoint, and additional information about houses, people, and pets can be included in the query!
By using GraphQL’s query language, we reduced our dozens of requests down to two or even one. That’s a huge performance bump in our app! As you work with GraphQL, you’ll see other advantages to this query system, such as being able to define the shape of data we receive and getting more detail about the data and errors sent from the API through GraphQL’s simple type system. GraphQL even has the capability of giving us some basic code analysis while we write our requests!
As more and more companies such as Github, Facebook, Amazon, and Twitter implement GraphQL endpoints into their public APIs and more and more developers become interested in learning the technology, GraphQL is poised to become as necessary for the junior developer to learn as REST API requests have been for the last decade.
Be sure to add learning this accelerating technology to your must-dos for 2018 and check out our new Introduction to GraphQL course with Isaac Lee!
Start learning to code today.
Free Trial
