If you are building a data-driven web or mobile application, then key concerns you need to address is how data will be surfaced to the client and how the client can update the state on the server. This is not a new problem, and one that we have been solving for decades.

GraphQL provides one way to address this problem and uses an approach that provides significant benefits over previous RPC-based approaches. GraphQL was originally created at Facebook several years ago. It has been widely adopted since by Github, Concur, Airbnb and more. We’re even now adopting it at DocuSign. If you are doing React development, GraphQL has become the de-facto way to query from React clients.

What is GraphQL?

At its heart, GraphQL is several things.

A schema that allows defining a structured view of data that will be surfaced to / queried / updated by a GraphQL client.
A query language for interacting with a GraphQL endpoint to retrieve, update, and subscribe to notifications.
Tooling and SDKs for building GraphQL clients and servers, or interacting with GraphQL endpoints such as the GraphiQL editor, clients like Apollo and Relay, servers like Apollo, GraphQL for .NET, and more.

A few things that have stood out for me that I have really liked about GraphQL.

• It provides a standard way to query and update data including non-crud based actions. It supports “graphs” of data allowing queries to pull hierarchical data.
• It puts power in UI teams hands to be able to hand craft queries with the data they need, without having to constantly send custom requests to the API team.
• It has GraphiQL which is an awesome intellisense-driven tool for querying GraphQL endpoints that you can provide to developers for interacting with the endpoint.
• It can work side by side with, and wrap existing “REST” APIs
• It is not opinionated about where data resides, it is not bound to a database.
• Data could live in MongoDB, SQL, in documents like S3/Azure Blob, or even in memory. It is really easy to make GraphQL work with any data store
• It allows full control from the server-side as to what data is exposed.

There are also plenty of tradeoffs with GraphQL vs traditional APIs and it is not a silver bullet. Fortunately it is not mutually exclusive and can live side by side with “REST” APIs. Still you should go in with eyes open (as with any other technology or approach).