WWCode Talks Tech #24: Intro to GraphQL
Written by Farzaneh Orak
Farzaneh Orak, Senior Software Engineer at CoStar Group presents an Intro to GraphQL. She talks about its uses, advantages over many other systems, and some of the applications it can apply to.
GraphQL is a query language for your API and a server-side runtime for executing queries using a type system you define for your data. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data.
To make it simple, GraphQL is a query language. It was developed by Facebook in 2012 for internal use initially, but then they made it open source in 2015 and now it's open to the community and the community is contributing to that.
It's a library. It's not a framework. It's not replacing anything. It's not a database. It's not an API. You're adding one layer to your stack.
Why GraphQL? GraphQL is an alternative to traditional REST APIs. REST APIs tend to be very stiff and hard or impossible to change because so many things depend on them. So, for any changes, you have to create a new API. However, GraphQL is a more flexible option. GraphQL can dictate the shape of the data. This is the key. This is the whole thing about GraphQL. Client-side, it's control over what type of data you want and what shape of data you want.
It gives you the ability to retrieve many resources in one single request and reduces network usage in many cases. And GraphQL provides documentation for newcomers. There are tools like Apollo which provide a very nice visual for the architecture of your system and all of your data structures, making it easier for newcomers to wrap their heads around the actual application.
Here is a very simple example. In the REST world, imagine you want to create an application that will show all the books for all your authors. In your database, you call the author endpoint, and you get information about the author, which you probably don't need. And then, you get the ID and call another endpoint to get the books for those IDs. If you have an array of authors, depending on the type, you will have to make many calls to get all the books for the authors.
In GraphQL, on the client side, you tell it you want the name of the authors and the list of the books, and that’s what you get. The server side is responsible for taking care of it. You don't see anything less or more.
GraphQL has just three things, schema, operation types, and resolver. When working with GraphQL, you constantly touch your schema, operation types, and resolver. What are they? Schema is your type, the shape of the data you describe, and the order defined. The operation type is the query. You're getting data. Then you have the resolver. Some functions hydrate your schema, so you define your schema and then define the operation type. What do you want? Do you want a query? Do you want to get data in that shape? Or do you want to mutate in that shape? The resolver is the middleware. It does all the hard work and gives you exactly what you need.
For example, you have a query and want to get data: the name of these books, so you want the array of books coming back. What is a book? This is the type that you're defining. It has a name, and then you give it a type you want to return—the same thing with subscriptions. Resolvers are functions that always get four arguments. They can be synchronous or asynchronous. The way that resolvers or GraphQL resolve the query doesn’t matter. The first parameter is the parent. Args provides arguments. Sometimes your query might have an ID or some arguments to filter. Args is where you’re accessing that. Context is expressed, it's a request or a response, and info is more advanced.
This returns exactly what you want, in our example, the list of books. GraphQL treats an object as a node. So, the book is the node, and these are leaves. This can be nested. In this case, the author is another node, and these are leaves. The resolver resolves it by getting to the root, the books, and then resolving hydrates, and it gets to the author. The parent argument I mentioned is for the author. It would be a book. At this point in your resolver, you have access to the book information, which makes it very efficient. You don't need to make an extra call to get data. Everything's cached and ready, and you have access to it.