GraphQL provides a query language for describing the capabilities and requirements of data models for client‐server applications. It can be used to solve many of the problems that are usually faced when using its alternatives like REST and custom APIs. The three most important problems that GraphQL solves beautifully are:
The need to do multiple network round-trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single request to the server. To do the same with a REST API, you need to introduce unstructured parameters and conditions that are hard to manage and scale.
Clients dependency on servers: With GraphQL, the client speaks a request language which: 1) eliminates the need for the server to hardcode the shape or size of the data, and 2) decouples clients from servers. This means you can maintain and improve clients separately from servers.
The bad frontend developer experience: With GraphQL, developers express the data requirements of their user interfaces using a declarative language. They express what they need, not how to make it available. There is a tight relationship between what data is needed by a UI and the way a developer can express a description of that data need in GraphQL.
GraphiQL is an in-browser IDE for writing and testing GraphQL requests. It offers many great features to write, validate, and inspect GraphQL queries and mutations. These features are made possible thanks to GraphQL introspective nature that comes with its mandatory schemas.
A GraphQL request comprises a set of operations, an object for variables, and other meta information elements as needed. GraphQL operations use a tree of fields. A field represent a unit of information. The GraphQL language is largely about selecting fields on objects.
GitHub has a powerful GraphQL API that you can use to read data about repositories and users, as well as do simple mutations like add a star to a repository, or comment on an issue in a repository.
GraphQL introspective queries offer a way for clients to get meta information about the GraphQL API.
You can use GraphQL backend-as-a-service tools to create your own data models and have ready-to-use GraphQL requests to read and write to these data models. This is an easy way to get started with a GraphQL API and quickly prototype designs.
GraphQL has a few features that you can use to organize client requests and customize server responses:
You can pass arguments to GraphQL fields when sending requests. GraphQL servers can use these arguments to support features like identifying a single record, limiting the number of records returned by a list field, ordering records and paginating through them, searching and filtering, and providing input values for mutations.
You can give any GraphQL field an alias name. This enables you to customize a server response using the client’s request text.
You can use GraphQL directives to customize the structure of a GraphQL server response based on conditions in your applications.
Directives and field arguments are often used with request variables. These variables make your GraphQL requests reusable with dynamic values without needing to resort to string concatenation.
You can use fragments, which are the composition units of GraphQL, to reuse common parts of a GraphQL query and compose a full query by putting together multiple fragments. This is a winning strategy when paired with UI components and their data needs. GraphQL also supports inline fragments that can be used to conditionally pick information out of union object types or object types that implement an interface.