A Brief History of GraphQL
Tags: graphql, architecture, beginners, programming
Published: 2021-05-02 11:55:39

I recently started using GraphQL, and I love it. 

To be fair, at the beginning it was a bit tricky to stop thinking in the usual RESTful way, but playing around with it for a couple of hours, things started to make sense. Then I started to research the history of GraphQL and found it to be very interesting, and I wanted to share it with you guys.

In this article we will cover:

- History of GraphQL
- Problems with traditional RESTful API's
- Basic Introduction to GraphQL
- Benefits of GraphQL

## 2004 — 2006

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c8tpsei80rr4ko6kf9ip.png)

In 2004, the social media site "Thefacebook" was released. 

It was first only for Harvard students, but within the first month quickly expanded to Standford, Columbia, and Yale. 

This expansion continued to include most universities in the United States and Canada. 

In 2005, the company dropped "The" from its name and now called itself Facebook.

During that same year, Facebook reported that it had almost 6 million users. 

By 2006 Facebook opened its doors to everyone over the age of 13 with a valid email answer.

## 2007

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b2ovij9jz1y6dtlia1uc.png)

On January 9, 2007, Apple introduced the iPhone. This breakthrough technology made sure to include with it the "best" browser in the world, Safari.

That same year Google announced Android. 

2007 was a very defining year because it was the beginning of the transition from sites to native mobile apps. 

## 2009

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qell4pe8ssbf2f4ibpay.png)

At this time Facebook was growing in popularity and was not worried at all about the transition from desktop to mobile, because they thought that both Apple and Google would compete to make the best mobile web browsers. 

And Facebook was going to make the best web-mobile browser experience.

Boy, were they wrong...

## 2012

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/itng39mt71vptxb8yk4k.png)

Fast forward 5 years, Apple focused all its resources on native mobile apps, while Google didn't even bother with developing a proper web-mobile experience. This has left Facebook with a dilemma, the mobile market is steadily outgrowing the desktop, and the two most popular mobile operating systems have horrible browsers. 

As Mark Zuckerberg puts it:

> Our biggest mistake was betting too much on HTML5

This same year, Facebook was planning to go public, but there were risks due to the fact that Facebook didn't properly transition to the mobile market. 

Something had to change.

Facebook hired a bunch of new senior iOS engineers, and with the help of existing engineers decided to rewrite the Facebook iOS app, starting with the news feed. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iwwevq72zovti2es5muj.png)

They immediately hit a roadblock, the original news feed API returned data as HTML. So as standard back in 2012, they decided to translate this into a RESTful API. 

This introduced many problems:

- **Slow on network** - one API couldn't return all the data needed, so the client (iOS app) was forced to make multiple requests back and forth to different APIs.
- **Fragile client/server relationship** - changed to the API needed to be carefully carried over to the client code, or the app would fail and crash. There were maintenance issues with API docs, making them often out-of-date.
- **Tedious code & process** - client work, was very coupled with API responses, so if the API changed some of its response formats, the client code must change accordingly. Engineers at Facebook had to manually maintain client model classes, network logic, and many other stuff to make sure that the right data is loaded at the right time before rendering the view.

With all these issues in mind, bright engineers at Facebook decided to challenge the RESTful approach. 

This is where GraphQL started.

### What is GraphQL?

At its core, GraphQL is a query language that is used to fetch only the data that the client wants from the database.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/73j7h2lv0eaujdci4run.png)

This approach brought many benefits:

- **Fast on network** — unlike RESTful, a GraphQL query describes only what's necessary to the client, no need to make multiple requests to the server, only one will suffice.
- **Robust static types**  — it allows clients to know what data is available and what type of data it is.
- **Empowering client evolution** — the format of the response, is controlled entirely by the client's query. So server-side code becomes much simpler and easier to maintain. When you remove old fields from an API, these fields will be deprecated but still continue to function. This gradual backward compatibility process removes the need for versioning. After so many years, Facebook is still at version 1 of its GraphQL API.
- **Empowering developer tools** — GraphQL is a platform for creating great developer tools such as code generators, API explorers, and IDE integration.
- **Documentation is a first-class citizen** — documentation is automatically generated and always up-to-date.
- **Query Arbitrary Code** — GraphQL is adaptable, it's not about databases. It can be adopted on top of an existing RESTful API and can work with existing API management tools.

### Moving on

In the Fall of 2012, Facebook released its new iOS app powered by GraphQL and Facebook has continued on that path ever since.

## 2013

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hga9m6boyoim0k20r0tp.png)

Within the same time period, another group of bright engineers at Facebook started an open-source project called React. This became Facebook's most popular open-source project, this highlighted to the GraphQL team the importance of open-source. Keep in mind, at this time GraphQL was only used internally within Facebook.

## 2015

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qc129npt0mc7ggnob78o.png)

A couple of years later, Facebook wanted to showcase a new open source project called Relay. 

Relay is a framework that ties React and GraphQL together. 

But they couldn't showcase the project, because GraphQL wasn't open-source. 

After intensive thought, the GraphQL team decided to go open source. It started out by releasing a specification and NodeJS implementation.

- GraphQL Specification: [https://github.com/graphql/graphql-spec](https://github.com/graphql/graphql-spec)
- GraphQL.js: [https://github.com/graphql/graphql-js](https://github.com/graphql/graphql-js)

By the end of the year, countless contributors started implementing GraphQL in the programming language of their choice.

## 2019 — 2021 and beyond

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/71jpc4sq6t77zz74gtvg.png)

GraphQL started as an internal tool in Facebook, to fix the issues they had with RESTful APIS. 

When it went open-source it was mostly used by hobbyists, now it is used in big corporations such as Netflix, Amazon, GitHub, and countless others. 

The community also grew there are GraphQL meetups in every continent, and major conferences in America, Europe, and Asia.

## Conclusion

GraphQL was originally built to solve Facebook's native news feed API for iOS. It was quickly implemented to solve more problems at Facebook, and eventually went open-source. Solving more problems in a variety of companies. 

Do you think GraphQL is industry standard or needs a couple more years to be recognized as one? Let me know in the comments section below.