GraphQL Galaxy

GraphQL Galaxy 2022

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. How did, which probably you're one of the best, if not the best person to answer this, how did GraphQL start? What's the origin 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 we called Ents. 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's 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 internalized browser and it would just consume all the RAM on your device and the app would crash. So it was slow, it was buggy, it crashed a lot. Basically, the web technology, at least in that moment, was not growing and scaling, developing at the pace that we needed it to. So we had created a project to go back to native development. And this was in 2012, which is still relatively early for native mobile engineering, but sort of clean slate, new project and Xcode style started creating a new iOS app. Had a little skunkworks 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 like stuff happens behind the scenes in PHP and then HTML comes out the other side to serve a web page. And not a ton of thought had been put into an API, not as sort of like a partnerships thing. Like 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 happened to be supporting this team at the time. Their engineers are working on my team. And they're bounced into this problem. We're like, yeah, all right, well, let's go dig around and see what we can find. And we started looking at various APIs we built before, and they were all kind of underwhelming. And there's this new one that we 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 ends. It was really exciting. But if you've ever had to write a join between six tables, your brain starts melting. And basically, you would 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 got to be a better way. And so we went to the author of Ent, which was Nick Schrock, who was sort of galaxy braining this idea that what if you could write PHP that wasn't PHP, but 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 Schaefer. And he was in the middle of migrating News Feed, which is one of the oldest codebases of 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 it's 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 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 that sense 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 codebase, 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 codebase they're using. Obviously, the GraphQL infrastructure there has evolved considerably over that time, but to this day, GraphQL is the way in which 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 basically 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, that was written to being exposed to this and how you solved it, I think today that's probably one of the reasons why GraphQL is so popular. Or at least what I can see as well in the day to day, people are really excited about GraphQL because of that. So basically, 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 for that. This is really exciting. Yeah, the latter is very surprising to us. I think we saw it as exciting, but it felt complicated to us, which made sense for the surfaces of product that we're building, which were in fact quite complicated. And it took some convincing to, and quite a lot of simplifying energy went into the variants that ended up getting open source, 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 managed to open source it, which is never easy in almost any company. So once you open source it, I wonder, GraphQL basically exploded. And there are so many today companies and different solutions and different things that our each community is using. I wonder, 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? And that could include where it ended up with, or maybe even use cases that you never thought happened. 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, in ways that initially I thought would be maybe inadvisable or kind of nuts, but have actually ended up being very interesting. There was some talks before about applying GraphQL over graph databases. 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, don't make me replace my database. No, no, no, no, no, we don't want to replace your database. It's just purely a... 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 atop graph databases, we're like, ah, this is moving in exactly the opposite direction of the FUD we're trying to clear. And this seems 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 Closure Script environment. And Closure Script 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. Yeah. I think... So as someone who runs, like 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's 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. And I will 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. So 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 lets you 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. And 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 front end libraries, which are also sort of embracing this idea of sort of continuous data delivery and continuous UI rendering as like 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, I always ask myself, you know, you were in Facebook doing all of this, and creating it and inventing it, opening to the world. And then you also now have the experience after, you know, later you moved to Robinhood and now in Watershed as a product engineering lead, like, how is your personal experience of graph and you're doing, you know, I think, you know, 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 back end service and our front end 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 where we're trying to approach it as minimally as possible. We have like one file that defines our whole schema and one file that pulls in all of our resolvers and then that's kind of it. But nonetheless, it does feel more complicated than I want it to feel, even in the approach that you're trying to sort of do the minimally viable infrastructure around it. It's working very well for us, but you know, one of the things that I think is a yet unsolved problem in this space, and I really hope some 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. 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 ID 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 code first 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 code first. 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 that 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, ping both me and Lee at any time you can. Thank you, Lee. This was fascinating. And thank you so much for joining me, for the folks at home. You can go to also the Andromeda channel on Discord and ask questions and Lee will be there as well. Yeah. And thank you so much. And back to you, Cecilia. Thank you, Lee, for joining. Thanks all.


Lee Byron

GraphQL Galaxy 2021

Moderator - Uri Goldshtein  Panelists:Lee ByronSasha SolomonBenjieBrielle Harrison <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>