The big picture
A spec that describes a declarative query language that your
clients can use to ask an API for the exact data they want. This
is achieved by creating a strongly typed Schema for your API,
ultimate flexibility in how your API can resolve data, and client
queries validated against your Schema.
It’s just a spec. There are several implementations and variations
A GraphQL server with a connected DB
A GraphQL server as a layer in front of many 3rd party services and connects them all with one GraphQL API.
A hybrid approach where a GraphQL server has a connected DB and also communicates with 3rd party services
A Type on a Schema that defines operations clients can perform to access data that resembles the shape of the other Types in the Schema.
Functions that are responsible for returning values for fields that exist on Types in a Schema. Resolvers execution is dependent on the incoming client Query.
To create a server, at minimum, we need a Query Type with a field, and a Resolver for that field.
A Type on a Schema that defines operations clients can
perform to mutate data (create, update, delete).
A set of discrete values that can be used in place of Scalars. An enum field must resolve to one of the values in the Enum. Great for limiting a field to only a few different options.
Abstract Types that can’t be used as field values but instead used as foundations for explicit Types. Great for when you have Types that share common fields, but differ slightly.
Like interfaces, but without any defined common fields amongst the Types. Useful when you need to access more than one disjoint Type from one Query, like a search.
Your API is no longer a predefined list of operations that always return the same shapes. Instead, your API is a set of Nodes that know how to resolve themselves and have links to other Nodes. This allows a client to ask for Nodes and then follow those links to get related Nodes.