REST is rigid. GraphQL is flexible. When frontend engineers demanded more power over network payloads, Facebook created a revolution.
1The Inflexibility of REST
In a REST API, the URL dictates the data. GET /api/users/5 might be written by a backend developer to return 50 fields of user data. A year later, a new mobile app is built that only needs the user's avatar image. The mobile app still has to call /users/5 and download all 50 fields, wasting precious cellular bandwidth (Over-fetching). The alternative is asking the backend team to build a completely new endpoint (/users/5/avatarOnly), which scales terribly.
async function execute() {
// See concept above
}
2The Single Endpoint Solution
GraphQL abandons the idea of multiple URLs. Instead, a GraphQL API exposes exactly one endpoint (usually via POST to /graphql). The client sends a JSON payload to this endpoint. Inside that payload is a 'Query' string. This string explicitly lists the fields the client wants. If the client asks for id and name, the backend returns a JSON object containing strictly id and name. The client is now in total control of the network payload.
async function execute() {
// See concept above
}
3The Contract
GraphQL relies on a strongly typed Schema. The backend defines a schema file outlining every possible 'Type' (e.g., type User { id: ID!, name: String! }). This schema acts as an unbreakable contract between the frontend and backend. Because of this strict typing, tools like GraphQL Playground or Apollo Studio can auto-generate interactive documentation and provide frontend developers with autocomplete as they type their queries.
async function execute() {
// See concept above
}
