AMA Session with Lee Byron

Rate this content

AMA Session with Lee Byron

19 min
08 Dec, 2022

AI Generated Video Summary

GraphQL at Facebook started as a solution for the migration to structured product infrastructure and the move to mobile. The birth of FQL highlighted the need for a better tool than SQL. The impact of GraphQL has been impressive, with unexpected growth and usage in various domains. Exciting developments include new features like defer and stream, making GraphQL a live, continuous data delivery and UI rendering tool. Personal experiences with GraphQL involve using it to move data between backend and frontend, with challenges in integrating it into IDE environments.

1. The Origin of GraphQL at Facebook

Short description:

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 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.

2. The Birth of FQL and the Need for a Better Tool

Short description:

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.

3. Innovating Across the Internet

Short description:

We went to the author of ENT, Nick Shrock, who was inventing a new programming language called Supergraph. We worked on aligning the elements of News Feed migration, mobile development, and the new Ent layer. In a couple of weeks, we had a working prototype of half of what GraphQL is today. We shipped the new version of the iOS app with News Feed on top of it, using GraphQL as the data serving infrastructure.

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.

4. The Impact of GraphQL and Unexpected Growth

Short description:

You set up to solve this for Facebook, but ended up solving it for countless companies. The growth and usage of GraphQL has been impressive and surprising. It has been used in interesting ways, including applying it over graph databases. The combination of React and the ClojureScript environment has brought about new ideas. GraphQL is being adapted and expanded to new languages, domains, environments, and use cases.

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.

5. Exciting Developments in GraphQL

Short description:

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. The most exciting things happening currently in GraphQL are the enthusiasm people bring to solving small problems and the development of new features like defer and stream, which move GraphQL from being transactional to being a live, continuous data delivery and UI rendering tool.

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.

6. Personal Experience and Challenges with GraphQL

Short description:

I'm interested to know about your personal experience with GraphQL after leaving Facebook and going through different phases. How is your day-to-day with GraphQL now? At Watershed, we use GraphQL to move data between our backend service and frontend client. It's a different use case from Facebook, and we're trying to approach it minimally. However, one unsolved problem is taking cogeneration out of the puzzle and making the integration of GraphQL into the IDE environment smoother. We're actively exploring possibilities and researching limitations of TypeScript. Thank you, Lee, for joining and sharing your insights.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Rock Solid React and GraphQL Apps for People in a Hurry
In this talk, we'll look at some of the modern options for building a full-stack React and GraphQL app with strong conventions and how this can be of enormous benefit to you and your team. We'll focus specifically on RedwoodJS, a full stack React framework that is often called 'Ruby on Rails for React'.
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.