May 12, 2022

The Heroes of GraphQL

TimSuchanek avatar

Tim Suchanek

TL;DR: GraphQL is a powerful technology that has transformed how data is accessed and used by apps. Its success is due in large part to the hard work and dedication of the people who have built it and continue to innovate within the ecosystem. From the original creators at Facebook to the many open source maintainers and contributors, the GraphQL community is a vibrant and growing community of builders and problem solvers. We'll have a look how this early technology could even get to this wide adoption and what the latest outcomes from the working group are.

GraphQL is an advanced and damn powerful technology. From ProductHunt weekend warriors to Fortune 500s — it already powers a significant part of the internet.

But how did we get here? How can a technology become so useful and powerful that it gets adopted by Facebook, Netflix, Yelp, Coursera, Microsoft, Amplitude, Atlassian and many more?

It’s the people. Incredible human beings have made this possible. Actually humble human beings. They’d never brag or boast about it. For us, they are the heroes of GraphQL and we want to dedicate this blog post to the people who made this incredibly colorful and vibrant ecosystem possible.

The story of GraphQL

There are great companies like Meta, Shopify, Netflix, Apollo, The Guild, and Hasura, who carried the flag for GraphQL in recent years. And while there are and were many many more influential people in the GraphQL ecosystem than I’ll talk about today, I want to talk about a few select individuals here that I believe had a particularly high impact (making this subjective and by no means exhaustive). You might say, “But what about the contributions of So-n-So?” Make a strong enough case and this blog post could get a sequel 🙂

At the beginning of 2012, three talented computer scientists working for a company called “Facebook” needed to solve a problem. They were about to work on the new iOS app of the social network and hit severe performance problems. They faced many tough technical challenges, which they needed to overcome. They were trying to get a wrapper WebView in a native iOS shell running. HTML5, however, wasn’t ready yet. A performant web app on the iPhone 10 years ago? Keep on dreaming. The web wasn’t ready yet, and the mobile app was crashing all the time, as the old devices ate too much RAM.

Mark Zuckerberg even said in 2012 that betting too much on HTML5 was the biggest mistake they ever made.

So it was time to start from scratch with a brand new iOS app.

While exploring the problem space and what to improve, the team of Lee Byron, Nick Schrock, and Dan Schafer realized, that one of the biggest issues wasn’t just shipping performance code to the iPhone. It was about how that app actually gets its data. There was no concept of a data layer abstraction on an API level. This existed on a PHP runtime level, like an ORM. As Facebook already had their fork of PHP called “Hack”, they had a powerful feature: Async/await. Nick was already working on an internal tool called “Ent,” which is an abstraction on top of Facebook’s “Tao,” used to access data and manage permissions. The question was, how could iOS developers now access Ent in their iOS apps the same way a Hack developer could do in the backend?

Rethinking data access from the iOS app

A naive approach would have been to directly expose Ent to the frontend. The problem with that is, that you’ll have a lot of back and forth: First get the user, then the posts, then the comments and back in the days with the latency of 3G networks that was not an option. They needed a way to batch that on the server-side, where these round trips can be very fast, as they’re happening in the same datacenter.

There already was an internal tool called “EntLoader”, which allowed you to specify the data you want, which then would translate to an efficient query plan, using the entities under the hood.

The idea was to expose in a way that you could write this EntLoader code in the iOS app. So Nick sat down, implemented a way to send this PHP-like code to the backend, parse it there and resolve the data. He called it “SuperGraph” and with that, an early version of GraphQL was created.

The team then took the tool, showed it to the mobile engineers and asked: Is this useful? Is this helpful?

The mobile engineers loved it.

But there was one missing piece. At that point, one big JSON blob would get returned, without any types, which is hard to deal with. Lee Byron was aware of that problem, and really wanted the goodness from RPC protocols like Thrift, GRPC, Protobuf or Cap’n Proto. Lee had a 3,000-line Thrift document written for Facebook’s newsfeed, which was the first feature they were working on with the new iOS app.

At this point they said: Why not combine the two ideas? Being able to query the data you want and having a strong typesystem. The idea of GraphQL was born.

Releasing GraphQL

They had a tight feedback loop with the developers who actually needed to access the data and their solution was getting more popular within Facebook. Other developers outside of the newsfeed team now also wanted access to this new powerful tool. It started spreading like wildfire.

To hear more about the origin story of GraphQL at Facebook, I highly recommend listening to this podcast snippet.

Since its incubation, GraphQL not only transformed data access at Facebook, but also transformed many more businesses. By now it’s an open standard that has been open sourced.

The three original authors of GraphQL took the technology, refined it and made it available for everyone at ReactConf in September 2015. Early adaptors and tech enthusiasts took the GraphQL specification and started implementing it in all kinds of languages, from Scala over JavaScript to Python.

Sangria GraphQL

In July 2015, Facebook released the GraphQL spec and in the same month, Oleg Ilyenko, a Berlin-based software engineer started implementing it in Scala. He called the project Sangria. In the coming years, Sangria would be the most advanced GraphQL server framework — even today it still sets a high bar.

Oleg was not only was an early GraphQL enthusiast, but he also understood the potential of it. Imagine implementing the spec just a few weeks after releasing it! He also was a damn good programmer. Sangria, which Oleg created on the side and later worked on more seriously at Commercetools, is now used by thousands of businesses, including Twitter.

Back in 2016, I was the first engineer at a startup called Graphcool, a backend as a service (BaaS) for GraphQL. We called it “The modern, GraphQL-based Firebase alternative.” Basically Firebase, but with all the benefits of GraphQL around data fetching and the type system. When creating such a BaaS, you want it to scale. And as much as I love Node.js, the story around multithreading is still limited. In addition, back then there was no TypeScript. You had an early version of Flow. So we decided to go with the ecosystem with the most mature GraphQL server implementation: Scala and Sangria. In addition, Scala has Akka, which is a powerful actor-based concurrency framework that can scale across thousands of machines.

In the time we built out Graphcool, it was a pleasure to meet with Oleg now and again to discuss API design over a pint, as he was also in Berlin. One time, I needed to do GraphQL AST transformations to support a new feature for Graphcool, for which he then added advanced type magic for the AST visitor in Sangria to be able to manipulate a GraphQL document AST.

You might have noticed that I used a lot of present tense here. Oleg was in Berlin. Yes, Oleg was. In May 2019, Oleg, an incredible human, who really pushed GraphQL as a technology forward, left us for ever.

Oleg, we will never forget you, you did incredible, meaningful work for the community. Thank you.

In 2018, Graphcool, the GraphQL BaaS renamed to “Prisma.” The main insight motivating that change was that coupling your database directly with GraphQL is not a good idea and that database tooling needed an overhaul. With that move, Prisma moved away from being a GraphQL-centric company to becoming a database-centric company. From then on, my involvement in GraphQL shrank, as I was now focusing on databases.

In the two years that followed, I was mostly focusing on helping to build out Prisma’s database tooling, including Prisma Client, Prisma Migrate and Prisma Studio. I didn’t have the use-case to work on GraphQL APIs, so I paid less attention on what was going on in the ecosystem.

Coming back to the GraphQL ecosystem

In the midst of building a side project in 2020, I decided to have another look into GraphQL. I discovered that what had happened in the ecosystem in those two years was incredible: the GraphQL foundation was established in November 2018, and the GraphQL Working Group, established in 2017, was building the future of GraphQL — or what we know of GraphQL today in monthly online meetings.

This reunion with GraphQL ultimately led to the creation of Stellate.

Innovations in GraphQL that took place in the last few years:

When I joined my first GraphQL Working Group meeting a few months ago, I was astonished.

Lee Byron is still facilitating the sessions, keeping at it after so many years. People like Rob Richard, Benjie Gillam and Ivan Goncharov are showing up again and again, year after year, driving the major efforts as mentioned above.

Without them, GraphQL would not be where it is today. Not even close.

I remember talking to Benjie at GraphQL Europe in 2018, where he told me about the Postgraphile logo (Postgraphile is a project that exposes Postgres as a GraphQL API), which he created it in VIM. Benjie is a true legend and has pushed forward many efforts in the ecosystem, including championing @oneOf, and working on the spec.

At time of writing, many more people are now active in the working group. Last Thursday over 22(!!!) people joined it in the pursuit to make GraphQL even more awesome than it is. Representatives from Microsoft, AWS, The Guild, Apollo, Meta, PayPal, Postman, Netflix and many more were present. It’s a wonderful space where ideas are carefully debated — weighing the costs and benefits of every solution.

While for sure not everything is perfect, we as a GraphQL community are in a really good spot. We have a stable spec that’s protected by the GraphQL foundation. We have a vibrant community of open-source maintainers — creators who solve problems in new ways, always raising the bar. We have companies being created in the GraphQL space, enabling the wide adoption of GraphQL.

It’s a true joy to be part of this community — a community of builders and problem solvers who want to make APIs more accessible and scalable for the world.

Whether named in this post or not, I want to thank everyone who made GraphQL what it is today: an enabling technology that is on its way to ubiquity.

Thanks to Lee Byron & the Stellate team for reviewing early drafts of this article.