GraphQL is a query language and server-side runtime created to better align frontend and backend design. It uses an object-like schema to request data with fine-grained control over what is and isn’t accessed. GraphQL is not a database; it primarily contends with REST APIs.
Facebook—or as the cool kids call it, Meta—relied on a REST API from its early days. (A REST API exposes various public endpoints for applications to request data, transacting with the database on behalf of the user). While a serious upgrade from their older HTML-driven backend, the REST API soured as Facebook grew to be the most popular social network. Complex intra-related data was only accessible through a combination of endpoints, so Facebook’s frontend had to make multiple consecutive requests before loading a view. This hurt loads times and network efficiency! Not to mention, developer productivity: maintaining alignment between the frontend and the sprawling user data kept growing more tedious.
The situation compelled Facebook to spearhead development of GraphQL, a query language designed to fetch relevant data in a single query. GraphQL dramatically improved Facebook’s performance. At the time, GraphQL remained an internal framework granting Facebook a competitive edge over other social media companies. This remained the case for a few years—GraphQL stayed in secret, technically preceding Facebook’s other successful developer product, React. In fact, only after React’s ultra-successful launch did Facebook open-source GraphQL.
Since GraphQL’s open-source launch, hundreds of frameworks and products have emerged to adapt GraphQL into different languages, databases, and ecosystems. Today, GraphQL is used by companies of all sizes, including some household names such as Github, Instacart, Shopify, Starbucks, and Wayfair.
GraphQL can be used to query data from all sorts of databases, including relational databases like mySQL or Postgres and non-relational databases like MongoDB. GraphQL is favored by developers that care about network and server efficiency. While GraphQL is a great for many applications, some common niches for GraphQL are SaaS applications and social networks.
GraphQL is both a query language and a server runtime. The query language looks a lot like JSON, but with only the keys, no values. Meanwhile, the server runtime exposes a single endpoint that receives all the GraphQL queries.
A common misconception, however, is that GraphQL directly connects to the database; because GraphQL was designed to be a general-purpose query language for all data sources, GraphQL pairs with third-party libraries for translating GraphQL queries into various native database languages. Some popular services to connect GraphQL and databases include graphile/postgraphile (Postgres only) and Hasura. These libraries translate each GraphQL query into a single query or set of queries.
GraphQL can be used at any stage of a project’s journey. GraphQL is easy to set-up for most databases and is well-suited for projects using Javascript backends. Because GraphQL doesn’t dictate which databases needs to be used, it can be implemented side-by-side a REST API, allowing for incremental migration from REST to GraphQL. Many companies—including GraphQL’s original developer, Meta—switched to GraphQL far into a project’s life-cycle.
Because GraphQL was built as a response to REST’s pitfalls, the fantastic way to grasp the fundamental advantages of GraphQL is to understand the disadvantages of REST. Like GraphQL, a REST API serves as a bridge between a database and a frontend. Specifically, a REST API implements and maintains:
user, organization, books), REST can provide endpoints relevant to each set and object type.However, a REST API is a rather rigid paradigm for accessing data. Endpoints typically have limited options (by design, hypothetically they could have infinite). This different-data-per-endpoint approach creates two common problems—over-fetching and under-fetching.