GraphQL started its life at Facebook as a solution to problems with REST APIs: basically, REST fetched too much data! With standard REST, you access a single resource/entity, and you can't ask for just one field, you get the whole resource. This might seem like over-engineering, but if you consider billions of people scrolling Facebook on mobile phones, potentially connected to satellite networks, this resource overheard was adding up.
REST APIs are still ubiquitous, but the REST architecture has some issues that GraphQL solves.
REST has issues with overfetching and underfetching, because the way a client gets data from a server involves REST requests hitting endpoints that return fixed data structures. GraphQL uses a strong schema definition to define the contracts between clients and endpoints.
As soon as a change is made in a web service's frontend, the data requirements of the backend have changed. Teams can define the schema when they begin a project (in GraphQL Schema Definition Language) so the frontend and backend teams can work separately, knowing the exact data structure as defined in the schema.
Frontend changes don't require backend changes with GraphQL, because the data needs have already been mapped in the schema. Frontend can make changes based on customer feedback without needing backend changes.
A basic GraphQL request looks like this:
Here we are querying a server for the field called team and its subfields like id and name. GraphQL allows us to define what we're looking for and structure the response we will receive, so we don't get a bunch of fields we don't need in one (relatively) big JSON file. We also have the benefit of communicating via one endpoint, instead of launching multiple requests to multiple endpoints. How does GraphQL do this?
A GraphQL schema is the backbone of every GraphQL API. It clearly defines the operations supported by the API and lets the client define what they're looking for.
REST is an API architecture style that facilitates HTTP connections, while GraphQL is an API querying language. REST architectures expose data through multiple endpoints, while GraphQL exposes only one endpoint. GraphQL accepts an information query from a client via this endpoint, and delivers that information from its flexible data architecture. The important distinction here is the client is defining what they are looking for, and structuring how they want to get it back.
GraphQL was initially popular with React developers, but has grown in popularity in the web development space since it was open sourced by Facebook in 2015. What makes GraphQL so useful is that it specifies both sides of the equation in client/server API relationships.