In February 2012, developers at Facebook set out to design a mobile-friendly Facebook iPhone app using native iOS tools. Frustrated by issues with their existing APIs, the developers needed a better, more efficient way to request and deliver data to their iPhone app. They created GraphQL and put it in first production in August 2012 with shipment of the new Facebook iPhone app. This open-source data query language for APIs was publicly released in 2015.
In large part, GraphQL was created to overcome the challenges of accessing complex data through REST APIs. Typically, REST APIs need to load from multiple URLs. GraphQL APIs allow you to request multiple types of data, all operating on a single endpoint. You don’t have to deal with multiple REST calls to request data on like objects. With GraphQL, you can create a single query to access the same information.
GraphQL uses a type system to describe what data can be queried and is used to validate queries. Because GraphQL isn’t tied to a specific database or storage engine, the client specifies the data it needs in the form of a query. The server sends back the response in the exact same shape, including only the data requested.
GraphQL query request, using a JSON-like syntax:
GraphQL query response includes only the data you requested in the same format:
Many applications don’t have a formalized client-server “contract” like GraphQL does. Product developers access server capabilities through multiple endpoints, writing custom code to fetch the data they need. The servers define procedures and return data. While this approach offers simplicity, it becomes less and less efficient as application complexity grows, systems age, or both.
In a REST API, for example, when information from a specific endpoint is needed, the request can’t be written to limit the fields that the REST API returns. The response provides a complete data set. In other words, data over-fetching occurs. In contrast, the GraphQL open-source data query language uses a syntax that allows you to tailor requests so they return only the needed information, from specific fields within each entity, for multiple objects.
GraphQL uses a predefined schema that describes the queries allowed and types of data that can be fetched. This approach makes it easy to develop applications without having to make assumptions on the field types. Among the other advantages of GraphQL:
Projects that took weeks before can be done in hours.
Queries return predictable results.
Apps are fast and stable because the server isn’t controlling the data.
Over- and under-fetching data is eliminated.
Network and memory usage decrease. With automation, the savings really start to add up.
Product developers can query for precisely the data they need in a declarative, hierarchal way that’s more natural to the way they think and work.
In March 2017, our development team created our first GraphQL service, Rubrik Cloud Data Management (CDM) UI. Shortly after we put the CDM UI initial concept through its paces, we chose GraphQL as the primary API architecture for Polaris, our SaaS platform. It offers users significant efficiency, performance, and agility benefits.
While GraphQL can be a powerful alternative to REST APIs, it isn’t a replacement across the board. In some scenarios, you still might find REST APIs to be preferable.
To learn more about the GraphQL open-source data query language, see our introduction to GraphQL and Rubrik.