If you're ever trying to talk someone into liking GraphQL, a good place to start is by explaining that GraphQL is a type system for your API. Enforcing types is something that GraphQL is really good at, and if you add TypeScript in the mix, you're dealing with a pretty powerful combination. GraphQL and TypeScript are like Leslie Knope and Ben Wyatt - they both love rules, and they both bring out the best in one another.
GraphQL resolvers are functions that return data for fields in your GraphQL schema. If the schema is the plan for your GraphQL API, the resolvers are the executors of that plan. They're the workers who go get the data for you, no matter where that data is.
In a couple weeks, we're going to be celebrating Moon Highway's eighth anniversary. Eight years of classes, video recordings, talks, and webinars. There's been a whole lot of typing into a code editor in front of people, and one of our main goals when doing this is to make sure that people can read the screen.
A common refrain you'll hear about GraphQL is that you can make one request and get only the data you want. A query will return just the fields that you request, nothing more and nothing less. For example in the allLifts query, we make a selection for a certain set of fields:
When you start working with GraphQL, you'll start to realize that GraphQL is going to change your design process. Instead of looking at your APIs as a collection of REST endpoints, you'll start looking at APIs as collections of types. Before breaking ground on your new API, you need to think about, talk about, and formally define the data types that your API will expose. This collection of types is called a schema.
When Facebook open-sourced GraphQL, it had a few different parts. It came with a spec. That specification document described all of the features of the GraphQL query language and the schema definition language. It also came with a reference implementation of a GraphQL server called graphql.js. This was an example of what a GraphQL server might look like so that other people could implement their own servers in a variety of languages.
One of the most powerful features of GraphQL is its schema definition language. When we write a schema, we define all of the types that are available on our API. If our GraphQL server provides us with an enforced list of type definitions, that means that GraphQL gives us an added benefit: mocking.
When GraphQL was first released, some touted it as a replacement to REST. "REST is dead!" early adopters cried, and then encouraged us all to throw a shovel in the trunk and drive our unsuspecting REST APIs out to the woods. This was great for getting clicks on blogs and starting conversations at conferences, but painting GraphQL as a REST killer is an oversimplification. In fact, wrapping an existing REST API is a very effective way of migrating from REST to GraphQL.
