What Is GraphQL and Why Would You Need It?

Not so long ago, GraphQL was the new kid on the block, offering an alternative approach to writing queries and how data is received. It quickly gained popularity amongst web development teams and engineers for its nimble performance, light state management and excellent (and interactive!) documentation.

But where did it come from? How does it differ from REST? What does it mean for the end user?

GraphQL’s origins

Facebook began working on GraphQL over ten years ago, before releasing it publicly in 2015. By 2018, ownership was moved from Facebook themselves to the GraphQL Foundation, part of the Linux Foundation. As a query language for APIs, GraphQL simply specifies how data can be requested before being loaded from a server and to a client. 

A deeper dive into GraphQL

GraphQL is defined by what is called its flexible data fetching. This means that the application will only load the relevant data from the server, and will structure that data in a hierarchical way, thus avoiding complex queries.

In simpler terms, imagine you’re building an app that requires dynamic data. This will require an API to deliver that data, but not necessarily all of it. Think of it like a pick ‘n’ mix – you’re only getting the ones you want and not the toffees. GraphQL excels at delivering only the required data and in a sensibly structured way. This will avoid headaches for everyone, human or machine, including over-fetching (too much data), under-fetching (too little data), dependent requests (many requests for data) and multiple requests (waiting for one to resolve before you can execute another).

This power and flexibility over more traditional APIs radically improve application performance, whether a single-page app or a mobile app – great for users, and particularly those on a slower connection (remember, not all parts of the world enjoy blazing fast internet).

If you have a spare thirty minutes, check out Honeypot’s ‘GraphQL: The Documentary, which offers some great insight into the creators and the community.

GraphQL vs REST

These are both great interfaces for APIs, but it can be difficult to directly compare the two as it’s not quite that simple. REST is widely used and has become ‘the standard’ for many, with its stateless servers and structured access to resources. But REST APIs can be seen as inflexible, particularly when presented with the rapidly changing requirements of the clients accessing them.

REST gathers data from multiple endpoints, whereas GraphQL sends a single query. There’s also the issue of over/under fetching (which we mentioned above).

REST APIs are often structured according to the views inside of its respected app. Useful for the client, but makes it difficult for rapid iterations at a front-end level. For example, any changes made to the design could mean that more data (or less data) is required. Therefore, the back-end needs updating to account for this. As you can imagine, this hampers speed and productivity – not at all useful for agile technology agencies like ours.



GraphQL works with many programming languages

Because GraphQL is a communication pattern, it supports over two dozen programming languages, including JavaScript, Go, PHP, Python, Ruby, Elixir and C#. There’s a huge choice of servers recommended by GraphQL.org, with a popular choice being the Apollo Server project, which has great documentation and self-documenting API.

Other benefits of GraphQL

  • Very simple versioning, plus backward compatibility. As we know, GraphQL will only return the data that’s been requested, so it’s easier to add new capabilities.
  • You don’t need to be an SQL expert. That’s because GraphQL makes it easy to query data using web standards.
  • Great for complex systems and microservices. Because GraphQL unifies APIs and ‘hides’ their complexity, multiple schemas (or data sources) can be consolidated into one global schema (as shown in the diagram further up).
  • Out of the box validation and type checking. There’s no need to validate data formats, as GraphQL takes care of it. So developers only need to write resolvers, which is how the data is received.



AndAnotherDay’s Head of Development, Tom Clarke, on why we like GraphQL

“A number of years ago, whilst building a data-heavy platform, we decided to use GraphQL based on what we’d read about it. It sounded like the perfect approach for building this kind of digital product and helping us handle everything from projects to user data to authentication, and even analytics. But at this point our GraphQL experience was limited. We had already started the project using traditional REST APIs, but we decided to take the risk and try GraphQL – the main draw at this stage being the amount of data we were dealing with, and a pressing need to reduce the payload size.

“GraphQL enabled us to fetch all the data required and return only the specific data needed by the platform. This reduced the size of and sped up the dashboard we were building. GraphQL also allowed us to use the REST APIs that we had built, so that no previous work was wasted. Once the GraphQL server was up and running, and configured (which didn’t take long at all), we were able to focus on writing our resolvers to fetch and return data in the format the front-end required. Before we knew it, about six months in, we had achieved more on our platform than we had in the two years prior (keeping in mind this wasn’t a full-time project for us)!

“From here, we fell in love with GraphQL. It didn’t just speed things up, but it allowed for cleaner code throughout the whole project – from back-end naming conventions through to the front-end. Suddenly we had a project where back-end and front-end developers actually felt more comfortable switching the different areas. We continue to pick up the pace on this solution, introducing new features to the platform in days rather than weeks.”


GraphQL isn’t the perfect solution for every project, but when working with you to develop your ideas into a fully spec’d solution, it is something we will certainly consider if appropriate.