A Quick Intro to GraphQL
So What is GraphQL?
GraphQL is a query language for APIs, often used to load data from a server to a client. It allows the client to spell out exactly which data it needs and makes it easier to accumulate data from various sources.
How did it get started?
GraphQL, like many other technologies, was first built and used inside Facebook. It was first used in 2012 and wasn’t released externally until 2015.
In 2012, Facebook found themselves with an issue. Both their iOS and Android apps started to suffer poor performance and frequent crashes as they became more complex. Facebook assessed their options of solving this problem, and that’s how GraphQL came into fruition.
GraphQL was an innovative project meant to separate data used by the mobile applications with the server queries they required to fetch. Instead of thinking of data in terms of resource URLs, data could now be thought of as a graph of objects and the models used to store them.
Let’s illustrate this idea with an analogy. The old REST model is like running three consecutive errands: dropping mail off at the post office, depositing a check at the bank and then going shopping at the grocery store. You communicate with three different shops.
Conversely, GraphQL is like forgoing the trip around town and instead having a personal assistant. You can simply give your assistant the addresses of the post office, bank and grocery store, tell them what you need and then wait for them to come back with your goods. GraphQL creates a standard language for communicating with this metaphorical personal assistant.
Cool! So how does it work?
There are three principal building blocks that make up a GraphQL API: the schema, queries and resolvers.
Schema
Central to every GraphQL server is its schema. The schema specifies the server’s API, which lets the client know which operations the server can perform. It is written in SDL, or schema definition language, and allows you to define object types and fields to represent data that can be retrieved from the API. It can be helpful to think of the schema as a sort of contract between the client and server, as it establishes the capabilities of the API and specifies how clients can request data. Here’s an example of a schema in SDL.
Queries
Queries are strings that are sent to the server to be interpreted and executed, and they then return JSON data back to the client. Here’s an example of what one would look like. Here we have a query that would return a list of all of the authors stored in the database, and their ages.
A major advantage of GraphQL is that it allows you to easily query nested information. For example, if you needed to get back all the books that an Author has written, you could simply follow the structure of your types in a query like so:
Resolvers
With GraphQL we have a very clear separation of structure and behavior. The structure of a GraphQL server is its schema, which, as said before, specifies the server’s capabilities. This is where resolvers come in. Resolvers bring the schema to life by determining the server’s behavior. Resolvers are functions that describe how queries should be handled and responded to. Each field on each type is backed by a resolver function. When a field is executed, the corresponding resolver is called, and it executes and produces a value.
Bringing back the analogy from earlier, even an expert personal assistant won’t be able to help much if you don’t tell them which post office or bank you need them to go to. Likewise, a GraphQL server won’t know how to process an incoming query until you tell it to with a resolver. The resolver tells the server where and how to fetch the data corresponding to a given field.
Here’s an example of what a revolver looks like.
Conclusion
In short, GraphQL makes it a lot simpler to be selective about the data you receive back from external API’s. This was just the tip of the iceberg of the world of GraphQL but I hope it piqued your interest enough to check it out if you haven’t already.
