AMA Session with Lee Byron
This talk has been presented at GraphQL Galaxy 2022, check out the latest edition of this Tech Conference.
AMA Session with Lee Byron
This talk has been presented at GraphQL Galaxy 2022, check out the latest edition of this Tech Conference.
GraphQL was developed at Facebook in response to the need for a more efficient and structured way to fetch data for their new native mobile applications. Traditional APIs were found lacking, prompting the development of a new system that better suited Facebook's product architecture and mobile requirements.
The initial development of GraphQL was a collaborative effort by Nick Schrock, Dan Schafer, and Lee Byron. Their combined efforts over a focused period resulted in the creation of the prototype that included many features of today's GraphQL.
After its initial creation for Facebook's mobile apps, GraphQL's infrastructure evolved significantly over the years. It became integral to the way data is served to Facebook's apps, maintaining its core principles while expanding in complexity and capability.
GraphQL allows for precise data fetching with a strong type system, reducing over-fetching and under-fetching problems. It provides a more efficient, powerful, and flexible alternative to traditional REST APIs, particularly useful in complex systems and various client requirements.
After being open-sourced, GraphQL gained rapid adoption across various industries due to its efficient data handling capabilities. It has enabled countless companies to optimize their APIs and improve client-server interactions, fostering a large community of contributors and users globally.
The GraphQL Foundation is an organization dedicated to maintaining and advancing GraphQL. It offers a platform for both individuals and companies to contribute to the project, influence its direction, and ensure its ongoing success and health through collaborative development.
Current developments in GraphQL include features like 'defer' and 'stream' which enhance real-time data capabilities, moving GraphQL beyond traditional transactional uses. These features allow for continuous data delivery, aligning with modern development practices in reactive programming and UI rendering.
Thanks, Lee, for joining. How did GraphQL start? The original story of this? How did we all end up here in this weird conference? Two things were happening at Facebook. The migration from PHP code base to structured product infrastructure. The move to mobile. Mobile development at Facebook was web only. Performance issues led to a project for native development in 2012. The team realized the need for a product API.
So, yeah, so, thanks, Lee, for joining. I'm really excited for AMA. And let me start with maybe the first question, which probably you're one of the best, if not the best, person to answer this. How did GraphQL start? What's the original story of this? And how did we all end up here in this weird conference? Yeah. This is a throwback, because this was, at this point, over 10 years ago, which is kind of crazy.
To kind of set the stage, two things were happening at Facebook at this moment. One was our monolith code base that served Facebook.com was doing a migration from early phase PHP code base to more structured with great product infrastructure. We have this sort of ORM-esque kind of layer that ends and we're starting to introduce type systems into the code base and that was creating this sort of very amazing abstraction away from underlying systems and data storage, and you could just sort of interact with these high-level objects to get the data that you needed to put together any particular web-based product that you were doing. This was great.
Another thing that was happening was the move to mobile. So, Facebook, of course, started as a desktop web only platform way back in 2003-2004, and from there slowly made its way into mobile. The first kind of cracks at mobile were, if you remember, WAP, the like HTML variant that was all black and white and had no images. Like that for flip phones, like I think that was the very first version of Facebook for mobile. And then that sort of evolved as devices evolved and sort of followed the inertia of that, and that meant that all mobile development at Facebook for many years was really web only. There was an iOS app, but it was super limited. It only basically did you could look at your newsfeed and that was kind of it. And eventually even that got replaced with the full web app. There was sort of a wrap around it. And it sucked. It was really, it wasn't great, like the performance was bad. We tried to do really cool, like, animations in the, you know, the internalized browser, and it would just consume all the RAM on your device, and that would crash. So it was slow, it was buggy, it crashed a lot, and basically, the web technology, at least in that moment, was not growing and scaling, developing it at the pace we needed it to. So we had created a project to go back to native development. And this was in 2012, which was still relatively early for native mobile engineering, but sort of clean slate, new project in Xcode style, started creating a new iOS app. A little skunk works team of three or four people, iOS developers building this thing. And they realized that they just couldn't get the right data that they needed, because all of Facebook's development to that point was basically just stuff happens behind the scenes in PHP, and then HTML comes out the other side to serve a webpage. And not a ton of thought had been put into an API, not as sort of a partnerships thing. We had developer partners on Facebook that used a developer API. But we hadn't thought about a product API. Like, what would it look like to build a true Facebook product on top of an API? So, I happen to be supporting this team at the time.
We started looking at various APIs we'd built before, and they were all kind of underwhelming. And there's this new one that we had built called FQL, which was sort of a variant on SQL, but was layered on top of this new ORM system we had built, these ENTs. It was really exciting, but if you've ever had to write a join between six tables, it's just like brain starts melting. I was like, this is nuts. I don't think SQL is the right tool for this. There's gotta be a better way.
They were engineers that were working on my team. And they bounced into this problem, and were like, all right, well, let's go dig around and see what we can find. And we started looking at various APIs we'd built before, and they were all kind of underwhelming. And there's this new one that we had built called FQL, which was sort of a variant on SQL, but was layered on top of this new ORM system we had built, these ENTs. It was really exciting, but if you've ever had to write a join between six tables, it's just like brain starts melting. And basically, we'd write these FQL queries that only maybe two people at the whole company could interpret. And they were like hundreds of lines of SQL to write these join queries. I was like, this is nuts. I don't think SQL is the right tool for this. There's gotta be a better way.
Comments