AMA Session with Lee Byron

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.

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.

And so we went to the author of ENT, which was Nick Shrock, who was sort of galaxy braining this idea that what if you could write PHP that wasn't PHP, but was like, kind of looked like PHP, and then you could send it to the server. And because it was almost PHP, you could basically just evaluate it, but it wasn't really PHP, so there wasn't the security risks. And basically, he was inventing a new programming language for doing cross-internet, almost like a multi-phase RPC. This was super exciting. He called it Supergraph.

And we were also, of course, building a new version of Facebook. We were working on News Feed first. So we went to the tech lead for News Feed, which was Dan Schafer. And he was in the middle of migrating News Feed, which is one of the oldest codebases the company at the time, to this new Ent layer, adopting the new best practices within the company. And then my team was trying to figure out the mobile stuff. And so the three of us sort of got into a room and was like, okay, there's got to be some elements of the three things that we're working on that align. And then we basically just didn't go home for a week straight. We just couldn't stop ourselves. We got so excited about this. And in a couple of weeks, we had a prototype working that was basically half of what you would use in GraphQL today, with a language and a parser and an evaluator, and it layered on top of Ents. And so in that sense, it had Resolver functions. And it worked. And we handed it to our iOS engineers and they were super excited about it. They started using it and it did everything we needed it to do. We shipped that new version of the iOS app with News Feed on top of it, profile and the rest, and actually that code base, that lineage of the iOS app is the one that exists to this day. If you use the Facebook app, that's the same origin code base they're using. And obviously the GraphQL infrastructure there has evolved considerably over that time, but to this day, GraphQL is the way in which that, all the data is served to that app.

So that's the origin story. That's where GraphQL came from. That's an amazing story. I mean, for me, even though I know a bit of the story, I think it's always very interesting because I think it also speaks a lot. There's a lot to learn also for the community. There's a lot to learn from that story today. Because I think everything you described about exposing data in a way that is structured well for the product, and on top of any data source that wasn't necessarily supposed to be exposed, and how you solved it, I think today that's probably one of the reasons why GraphQL is so popular. Or at least, you know, what I can see as well, like in the day to day, like people are really excited about GraphQL because of that.

So basically, you know, you set up to maybe solve this for Facebook specifically, and you ended up solving it for, I think, countless companies around the world. So thank you, this is really exciting.

Yeah, the latter was very surprising to us. I think we kind of saw it as exciting, but it felt complicated to us. And which made sense for, sort of, the surfaces of product that we're building, which were in fact quite complicated. And it took some convincing, and quite a lot of simplifying energy went into the variants that ended up getting open sourced, which is quite a lot better than the one that we had started with 10 years ago.

Yeah, pretty wild. Yeah, I think, yeah. It's not only that you've created something so valuable, but also that you've managed to open source it, which is never easy in almost any company. So, you know, once you open sourced it, I wonder, you know, GraphQL basically exploded. And there are so many today companies and different solutions, and different things that our huge community is using. I wonder, you know, when you look at everything that happened, what are the things that you actually predicted or thought, Oh yeah, that was supposed to happen? And what are things that you were like, Whoa, I didn't expect any of this to actually happen, or like, you know, and that could include where it end up with, or maybe even use cases that like you never thought that.

I think I've been impressed and surprised by the majority of the growth of the project and everyone who is using it. And everyone's using it in really interesting ways and ways that initially I thought would be maybe inadvisable or kind of nuts, but it actually ended up being like very interesting. There were some talks about applying GraphQL over graph databases. And this was like FUD that we had to clear very early as people looked at GraphQL and thought, Oh, because it has QL in the name, it must be a database language. And I already have a database, like don't make me replace my database. Like, no, no, no, no, no, no, we don't want to replace your database. It's just purely an orchestra. All it does is call functions under the hood. There's no database here. And so as soon as we heard people are going to use this on top graph databases, we were like, this is moving in exactly the opposite direction of the FUD we're trying to clear. And it seemed probably not great, but actually ended up being incredibly interesting. And there's like a separate line of thought around when we open sourced React and not too long after that, we saw Ohm, which was sort of the combination of React and the ClojureScript environment. And ClojureScript is just action packed full of super interesting ideas that really deserve to break out of that ecosystem, but sometimes struggle to just because the environment is so, like the Lisp environment is so different. But one of them is this idea of pull queries. And it wasn't until after, I mean, of course, GraphQL is in its package new, but it has a lot of ideas that are not new. And that was one that was sort of surprisingly aligned. And another very interesting thing that we're seeing is like influences between the two. Another one is just seeing the number of people who are adapting and expanding GraphQL to new languages, new domains, new environments, new use cases.

I want to say I expected that, I hoped to see that, and the sort of speed at which that occurred was faster than I thought would happen, which is great. So as someone who runs and I said in the introduction basically manages the GraphQL Foundation and the GraphQL Working Groups, what in your mind are like the most interesting things, the most exciting things that are happening currently in GraphQL and also maybe how people can join or hear about it more?

Yeah. The GraphQL Foundation is super fun because there's sort of two ways to get involved. You can get your company involved, which is a great way to sort of like have a little bit of influence over the overall direction of the project at large. There's a financial element to that. That is how we help fund the project being healthy and successful. But you could also show up as an individual, which is completely free, you don't have to do anything. You just show up to our Working Group meetings and you can participate in the development of new features to the GraphQL language as a whole.

I'll give you a boring answer and then an exciting answer to this question. And maybe this is like the wonkery of me, is one of the things I find very exciting is just the enthusiasm people bring to the smallest of problems. Because the smallest of problems multiplied by an incredibly large number of developers who use GraphQL is actually extremely important. And so people are sweating the details and really making sure that the quality of R is extremely high. You'll see topics pop up that like, unpack small discrepancies in the spec that would manifest via a bug that they found. Like, they found a bug somewhere, and they worked backwards all the way to the point where they realized that there was ambiguity about what the right answer should have been. And then they fixed it all the way in the spec, and then worked it all the way forward again. I love that. That's the thing that gets me excited. But then in terms of sort of new surface area to GraphQL, it's got to be defer and stream. So this moves GraphQL from being a transactional thing to being a live thing that happens over time. And we have a one version of this, which is subscriptions. And this was probably the biggest change since open sourcing it, and that happened a number of years ago. But that is more about the given an event stream that occurs somewhere under the hood, an event occurs, and then you still do sort of the transactional thing. Like, you run a GraphQL query every time an event occurs on some event stream under the hood. But defer and stream, let's say, given a particular set of data that you need, a GraphQL query, you can kind of get it streamed to you over time. An array of things could come back in chunks, or there could be a fragment that you say, like, I need this, but not immediately. So, if it takes a little bit of time to prepare, I can defer it. And that is extremely difficult to get right. Asynchronicity creates a ton of corner cases, and the folks who have been working on this have been doing a fantastic job pressing at the edges and making sure that it's going to be great. And I'm very, very excited to see what this does in terms of unlocking new development models, especially as I'm watching the development of React and other open source frontend libraries, which are also sort of embracing this idea of sort of continuous data delivery and continuous UI rendering as a thing that gets merged. These two things go hand in hand, and I'm really excited about that.

Thanks. Yeah, this is really, really exciting, I think. I get to talk with you a lot. I get to hear a lot of talks from you. And I think I always have, now that I can ask you a question, and I always ask myself, you were in Facebook doing all of this and creating it and inventing it, opening to the world, but then you also now have the experience after later you moved to Robinhood and now in Watershed as a product engineering lead, how is your personal experience of graphics? And you're doing, I think we all, you talked a bit about what's happening and how you manage the community and the big stuff that are happening outside in the community. But it's interesting for me to hear also from your personal experience after now, after leaving Facebook and going through a couple of different phases. How is your, and if your day-to-day with GraphQL today, how is it for you? What are you using? What do you see? If at all, or-

Yeah, we use GraphQL Watershed. It is the way in which we move data between our backend service and our frontend client. And it's great. It's a super different use case from Facebook, which has this massive schema and it's super challenging. It needs a ton of infrastructure. To Watershed, we're trying to approach it as minimally as possible. We have one file that defines our whole schema, and one file that pulls in all of our resolvers, and that's it. Nonetheless, it does feel more complicated than I want it to feel, even in the approach of trying to do the minimally viable infrastructure around it. It's working very well for us, but one of the things I think is a yet unsolved problem in this space. And I really hope someone can crack it, is to take cogeneration out of the puzzle. Using GraphQL with cogeneration is fantastic. You can generate your TypeScript types, or your Swift types, or whatever front-end client environment you're using, but it introduces this step, and it's tough to edit code in one file and then immediately see your environment updated in another file, and there's this other thing you have to do that feels like a one-off. And I don't know how to solve that problem, but that's the one that if anyone has got like a super crazy ambitious idea, is how do you make integrating GraphQL into your IDE environment and making the cogeneration step disappear into the background? I think that would make things feel much smoother.

Yeah, I couldn't agree more, I think, and this is for us also, by the way, working, this is a problem or something we're looking at both at the back end and the front end, right? Like the back end you have CodeFirst libraries, I think the latest one that we are most excited about in the JavaScript, the TypeScript world is POTUS, I don't know if you had the chance to look at it, but it's very exciting and it actually skips the whole code gen process and on the front end, I think there's a lot of new things, like things that are also CodeFirst. There's all kinds of different solutions out there and we're looking actually actively looking into what are the possibilities there. But also, we're researching some of the things are also limitations of TypeScript but I think there are some works in it so yeah, I'm also I'll join your shout out, so if someone is exploring it, yeah there's promise and like if someone wants to work on this, I think both me and Lee at any can. Thank you Lee, this was fascinating. And thank you so much for for joining me, for the folks at home, you can go to also the Andromeda channel on discord and ask questions and we will be there as well. Yeah and thank you so much and back to you Cecilia. Thank you Lee for joining.