May 10, 2020
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.
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.
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).