GraphQL is a query language (that’s what the “QL” stands for) for APIs and a runtime for fulfilling those queries with your existing data. Basically, it is used to load data from a server to a client -- it’s a way to get data from an API into your application. And as you’ll see, it does this in a much more efficient manner than traditional methods and services.
So what is this query language that powers hundreds of billions of API calls a day, how exactly is it used, and why? Let’s take a look at why front-end and back-end developers are so intrigued by its capabilities.
The Origin of GraphQL
GraphQL was developed by Facebook in 2012 because the team needed “a data-fetching API powerful enough to describe all of Facebook, yet simple enough to be easy to learn and use by our product developers” when building the mobile applications. Since then, the querying language has steadily grown in popularity -- in part to Facebook open-sourcing the language in 2016.
GraphQL has proven to be incredibly effective for building modern mobile and web, giving developers a flexible, rich technology for extracting data that is more efficient and less sprawling than REST APIs. The real secret is that GraphQL ensures that the developer and application only loads the relevant and absolute necessary data, even if it's from multiple sources.
When Facebook needed an API data version of News Feed, they considered RESTful server resources but found differences between the data in the app and the server queries they required. GraphQL allowed the team to approach data-fetching in a new way.
GraphQL vs REST
GraphQL is much different than a standard REST API where you typically have a specific endpoint or resource you’re hitting that determines an entire block of data that comes back in the returning JSON response, which then needs to be parsed and scattered.
GraphQL is instead established around schema, queries, and resolvers and rather aims to improve upon the REST philosophy by allowing you to ask for a specific piece of data -- not just the entire block. No need for parsing through a long stream of data -- you only get what you ask for. And what you ask for could be compiled from several different REST APIs.
However, let’s remember GraphQL and REST are two different things -- GraphQL is a language and a technology, while REST is an architecture pattern, which means that even as teams increasingly adopt GraphQL, it does not mean the end of the road for REST.
In fact, if you haven’t run in into any issues with REST, GraphQL may be of no use to you at all. In this way, GraphQL has been valuable for teams who have been limited by traditional REST APIs, which often arises with apps that have a complex UI/UX and typically require multiple endpoints.
While GraphQL may just seem like fancy new technology created by Facebook, many are finding that the implementation is actually quite practical.
GraphQL has proven itself as a solution to aggregate data from multiple sources, specify data, and describe data.
Once you understand some of the underlying concepts, finding projects that can benefit from GraphQL may eventually lead to depending on it as a core framework for future development.