APIs and the services behind them have changed how we build software. I like to explain APIs as Lego blocks for developers. They're little building blocks that you can put together to build something bigger. You might have to glue to build a really big model but the individual pieces are necessary for the end-result.
How much do developers love APIs? The answer is: a lot. 50% of apps built today use 2-5 APIs, while 9% of apps use more than 25 APIs* . But as anyone who is a parent would know, when you have a lot of Legos, you will eventually step on one and it hurts.
With that many APIs, you’ll need to understand:
Getting to know everything is a Herculean task. Luckily, GraphQL makes some of that easier. If all your APIs use GraphQL, discovering how APIs work and what data is available becomes much easier. But we still need to know what API holds which data and how it relates to data in other APIs.
Maybe Legos aren’t the right metaphor for APIs. Maybe APIs are more like music. Because music can be mashed up. A mashup is a song that’s created by blending two existing songs together. If you listen to two different songs one after the other, and then proceed to make a mashup and listen to it, you’ll be able to hear the two original songs. But if you listen to the mashup first, it probably won’t cross your mind that it’s made from two different songs.
Let me explain how we can apply this concept to APIs. At Contentful, we have a lot of open source projects. Just our main GitHub organization has over 100 open source repositories. It’s starting to become difficult to keep track of them so what we need is a dashboard to give an overview of what’s happening in our open source ecosystem. I can pull that information on GitHub, store some metadata in Contentful and pull information from other services. For instance, TravisCI, which already knows if a test succeeded for a project and this info does not need to be replicated somewhere else.
Why do developers like to use GraphQL?
All those advantages come at an upfront cost of a difficult amount of work involved to get it working reliably. So if you, your team or organization want to start using GraphQL, know that it’s not an easy technology that you can simply hash over your existing API.
Due to how it works and what it enables, GraphQL can be terrifying for backend engineers. Frontend developers, however, think it’s amazing.
The core part of every GraphQL API is its schema. The excerpt above is from GitHub’s GraphQL API. It’s a type repository that implements an interface called
Node and some of the properties you have on the interface. You see an
owner here, which links to another object type called
RepositoryOwner. The bang at the end means that it’s never null and always defined. It also has a URL and a connection to the stargazers.
Next I’m going to write a query. This is a simple query to access the GitHub API. I specify the organization to be
contentful, with the name
What I get back is a JSON object. If you look closely, you can see the structure of the JSON object matches that of my query. Even if it’s an API I’ve never touched before that someone else wrote, I can reason about the data that the API will return just by looking at the query, without having to read any documentation. Being able to form an interpretation just by looking at the code is really powerful when dealing with APIs that are unfamiliar to you and is one of the strengths of GraphQL.
How do I write a GraphQL API? Let’s write a
Hello World together. First, I’m going to import an ApolloServer.Apollo has released a lot of great tooling around GraphQL which I will use throughout the article. ApolloServer is the very basic machinery to setup a server that responds to GraphQL queries.
We always start by writing a schema. In this case our schema contains just one query with the name
hello that will return a string. With a schema, I’ve only defined what’s possible but I actually need to write the code that responds to any incoming GraphQL query as well. Namely, a resolver. For every query and object type, you’ll want to write a resolver function that gets passed to ApolloServer, that returns the data requested by the user.
In this example, it’s easy since I only have to write a resolver for
hello that returns a string, then start ApolloServer. If I access this through a GraphQL client, I can see my schema and introspect it. With a query that simply queries
hello and I get the word
world back which is a string so it matches the schema. Again, the result matches the structure of the query.
First thing I did is store all the data for projects, that GitHub doesn’t know about, in Contentful. I can model my own data there so I’ve modeled a repository, team, group and department. What I’m doing here is maintaining information about which repository is owned by which team in Contentful.
Much like having two separate music tracks that I want blended into a single mashup, I now have two APIs, GitHub and Contentful, but what I want is a unified version of this data and that’s my stitching proxy.
*Source: Global Development Survey 2017 Vol. 1, Evans Data Corp