We recently sat down with GraphQL co-creator Lee Byron to learn about the history and future of GraphQL. Hope you enjoy!

The Origins and Future of GraphQL

Ten years ago Lee Byron was a graphics engineer designing interactive news graphics at the New York Times when a friend approached him to join a small social media startup based in San Francisco, California. The company was Facebook, which had only just surpassed MySpace as the world’s most visited social media website at the time. Four years later Byron would find himself managing the team working on the Facebook native iOS app when the first seeds were planted for what would later evolve into GraphQL.

The Adventures of SuperGraph

“We started this little skunkworks project where two engineers from my team and two engineers who were relatively new to the company started building out what would become the native iOS app for News Feed,” Byron said.

The team produced a high quality, working prototype. However, they were not out of the weeds. When Byron spotted that News Feed stories were missing because they had used a three-year-old, unsupported platform partner API, he realized they would need to build a new one from scratch.

“That kind of sent things to crisis … They thought they were almost done and it turned out they had a ton of stuff left to do so I started focussing in on those problems and I was like ‘Okay, I need to build a News Feed API somehow. Who are the people I need to talk to? How does that need to get done?’ A big problem is that the News Feed is incredibly complicated and typical API technology probably wouldn’t do quite the right job so I started sketching out what a good API might look like. It definitely wasn’t what GraphQL is now but it was sort of like really beginning inklings in that direction.”

He added: “Meanwhile another one of the GraphQL co-creators Nick Schrock had just spent the last couple of years working on a bunch of data infrastructure on our server side and had spent a little bit of time exposing some of that over APIs, not GraphQL but a different kind of API, and had an idea about how this could be made much, much more simple so I credit Nick Schrock with the first prototype that really resembled GraphQL. He called it SuperGraph.”

🎁🎉 Happy 5th birthday to @GraphQL! It was five years ago that @schrockn wrote the “SuperGraph” prototype, and it’s been a wild ride since! pic.twitter.com/EZ9FfrtMnD

— Lee Byron (@leeb) March 3, 2017

A member of Byron’s team introduced him to Schrock and Dan Schafer, hailed as the best News Feed engineer at Facebook at the time, and the trio started work an initial version of GraphQL.

“The three of us got to work trying to figure out how to build a better News Feed API and we just got super far down the rabbit hole,” Byron said. “I think just a month or two of iterative improvements on what started as a prototype enfolding all of our ideas ended up being the first version of GraphQL.”

The launch of the native iOS app, helped by the introduction of GraphQL, was a success and the excitement around GraphQL and its capabilities made other Facebook teams interested in using it. As a result, Byron and the early GraphQL team would go on to develop a whole ecosystem around GraphQL; how it integrated with the iOS and Android apps, how it integrated into the server and GraphiQL, the in-browser IDE.

The final phase of the project was the decision to open-source GraphQL in 2015, something that was driven in part by the successful release of React, Facebook’s open-source JavaScript library, and also by the desire to open-source Relay, Facebook’s open-source JavaScript framework, which was inherently linked to GraphQL.

“We were excited about it. I mean, sharing things with the community is always good but it would be a lot of work and we weren’t totally sure people outside of Facebook would even care or find value in it. We thought maybe this was something that only solves a Facebook problem and wasn’t a generic solution but the Relay team had us excited so we followed that path and I’m super happy that we did. GraphQL now has a really big community outside of Facebook.”

Release and Adoption of GraphQL

The adoption of GraphQL took far less time than the team initially predicted. Speaking at the first ever GraphQL Summit in October 2016, Byron said he hoped GraphQL would be picked up by big companies within four years and reach ubiquity within five years. Byron laughed when he reflected on the accuracy of those predictions.

“I think I overestimated how long it would take for large companies to adopt it and underestimated ubiquity. It’s probably because “ubiquity” is kind of vague but certainly I still talk to tons of people who work in the API space and at best they say “Oh GraphQL, I think I’ve heard of that before but I don’t really know what it is”. It’s certainly better this year than it was last year and better than the year before that.”

He added: “I remember going to an APIDays conference shortly after the first GraphQL Summit and literally there were zero talks on GraphQL. After the next one, there was a whole track talking about GraphQL. The one after that GraphQL was featured in one of the keynotes and there wasn’t a specific track but GraphQL was scattered around. So it’s definitely picking up steam. I think there’s visible progress towards a ubiquity if we want to talk about ubiquity as knowledge. People are aware of the technology and what it does and why they should use it or not.”

One of the biggest surprises for Byron was seeing Github become one of the early adopters of the technology, particularly as he considers them an API leader.

“I was really surprised to see that within a year of GraphQL being open-sourced, Github decided that their public API would be GraphQL. That was particularly significant because they kind of helped to popularize REST. You know REST has been around for a while but it wasn’t really the dominant, popular way to build APIs until Github decided to build their API and they used REST and they made a big deal about it and wrote a bunch of blog posts and everybody paid attention. I thought “Wow, this API is really well built, it must be because of REST” and it was to a large degree but it’s also because the people at Github are really smart and they built a really great API. It’s really exciting to me that I consider Github to be sort of an API leader and they jumped on that first and they’re not the only ones any more.”

GraphQL and REST APIs Can Co-Exist

Although GraphQL has been lauded as the natural successor to REST technology, Byron is modest about its capabilities and believes the two can co-exist.

“I’m certainly not one of those people who that think I’ve invented the silver bullet here and everything should be GraphQL and there’s no room for anything else. I think that would be a little unwise. I think REST is an amazing technology so I would be really sad to see it disappear.”

We’ve compared the differences between REST, GraphQL, gRPC, webhooks, and more on the blog lately and found unique strengths among the formats for various scenarios. Similarly, Lee sees plenty of things that REST does better than GraphQL and vice versa. Specifically, he sees that the dichotomy represented in public vs. private APIs.

“I do think that as GraphQL continues to expand in scope we’ll see a much healthier balance between the two. My expectation was that public APIs would remain REST because that was simpler and more familiar where internal APIs, so to build your company’s own product, would use GraphQL because while it brought more complexity, it also brought some more expressiveness and capability.”

As GraphQL continues to grow, one of the things Byron is excited to see is more public APIs adopting the technology, like companies have done with REST.

“I think the space of public APIs or partner APIs is particularly interesting because I think the vast majority of GraphQL adoption so far has been for a company’s own internal projects. For example, Walmart uses GraphQL but they use it for the Walmart app. It would be really interesting if GraphQL starts to be used for these public and partner APIs so that we have companies that are working with each other. Then, it’s not just about the API design and the mental model within that company, but between companies.

I think that could be really interesting because it could help start to build one conceptual graph of all information. I don’t think GraphQL is going to be the technology that gets us there but that’s one of the big dreams of the internet is that we could have the one data internet but we need to start having some serious conversations along that path if we ever want to get there. I think GraphQL could be a really useful stepping stone on that path.”

Hopes For the Future of GraphQL

Despite being happy with its growing popularity and the open-source development around it, Byron hopes to see more growth in GraphQL tools and integrations.

“It’s kind of sad that there’s the Apollo Client for iOS and Android and then that’s kind of it,” he said. “There needs to be many competing pieces there and that’s true for any sort of technology that’s reached ubiquity has at least two if not closer to a dozen different options for how you would go about implementing that. If you wanted to build a web server, there’s like hundreds of ways to build a web server in dozens if not hundreds of languages and that’s kind of where I want to get to with GraphQL as well.”

Byron left Facebook after a decade of service to become head of web engineering at FinTech startup Robinhood earlier this year, citing the desire to work at a smaller company and its refreshing vision as some of his reasons for leaving.

“Robinhood’s roughly the same size today that Facebook was when I joined it and I really missed that. I realized that some of the best work I did at Facebook was when they were a little smaller. Not that Facebook’s not a great place to work now, it’s just I really appreciated having the smaller work environment and was happy to have that back.”

“I’m also interested in finance in general so it’s a new space for me to learn which has been pretty fun and then they’ve got a bunch of really interesting technical challenges and people challenges. That’s my bread and butter. I really love technical problems and people problems. I’m interested in product problems too but it’s new to me so there’s room to learn.”

On top of that, he is still the editor of the GraphQL spec and runs the working group meetings to ensure that GraphQL continues to improve while also maintaining stability.

“One my of goals for GraphQL is that it is stable because Amazon, Twitter, Pinterest, Airbnb, Facebook, Walmart, and so many other companies have bet their future on GraphQL. If GraphQL changes too rapidly, engineering directors at those companies may feel shaken and question the choice to use that technology. At the same time I want to make sure that there’s room for GraphQL to grow and improve and those improvements don’t have to come from me. I don’t think that I’m the smartest person in the room. I want to make sure that experiences of people from lots of different companies and environments can help influence that direction.”

GraphQL is still a new technology. It’s inspired large open source community, and adoption has been impressive in a short time span.

“GraphQL is still new. I’m really impressed with how much has been built by the open-source community and how much adoption has happened within the open-source community, especially the large companies. I mean, there’s a ton of large companies that are using GraphQL and that’s only three years out from open-sourcing, I think that’s pretty incredible but there’s always room to grow.”