 All right, bear with me as my slides are off template. So I have my notes over here. And also, I'm super happy to hear that more people know about GraphQL than watch the Oscars. New milestone. So morning, everyone. I'm super thrilled to be part of this summit. And I also want to share my personal experience with all of you about this project that I've been working on for the better part of seven years, GraphQL. And for those of you I haven't met yet, my name is Lee Byron. And for 10 years from 2008 to 2018, I worked at Facebook as a product designer, manager, and engineer. I spent the first half of my tenure helping Facebook make the transition to mobile, and the second half, building and sharing open source technology. I worked on some projects you probably already know. I was an early contributor to React. I'm the author of Immutable.js, and I'm one of the co-creators of GraphQL. And these days, I support web engineering at Robinhood, where we're democratizing access to our financial system. And by the way, if that mission resonates with you at all, please get in touch, because we have a ton of ambition, and I really need your help. So I eventually want to tell you more about what GraphQL is and does, if you don't already know. But I think what might be interesting is to first tell the story of the initial conditions that led to us building it in the first place. Facebook was built for the web. In fact, even our native mobile apps were really just thin wrappers around our Facebook mobile website. We bet big on the web. And I remember when Steve Jobs introduced the iPhone in 2007. He called it a breakthrough internet communication device, and he made sure that Safari, the best web browser in the world, was running on iPhone. And then Google, the biggest name in web and the creators of Chrome, responded with Android later that same year. And we thought, hey, these two are going to compete on having the best mobile web browsers. And we're going to build the best mobile web experience. Boy, were we wrong. Five years later, an Apple had placed all of their energy into native apps and had left mobile Safari years behind in web standards. Google had even bothered. The Android browser was slow and buggy, and it wouldn't be another year until we saw Chrome for Android. Mark called our bet on web a mistake. And at the same time, it was clear that the transition to mobile devices was happening more rapidly than we anticipated. And as we prepared to go public, our S1 filing highlighted this as a risk. We knew that we were in trouble. Failure to adjust to major shifts like this in the past had crippled and killed many other companies. So the circumstances that we found ourselves in when building GraphQL were neither academic nor theoretical. So what we decided to do was build Newsfeed, which was the first thing that you saw when you opened the Facebook app as a native iOS view backed by a RESTful API. And we immediately encountered issues. It was slow. We had to coordinate network requests for many related models that make up Newsfeed, and this caused multiple round trips over flaky mobile 3G connections. And it was fragile. Changes to the API needed to be carefully carried over to the client code, or the app could just crash. API docs were often out of date with the implementation. And it was tedious. Client work was often blocked on deploying the server whenever our API responses needed to change. And we had to manually maintain client model classes, network logic, and a bunch of other stuff to make sure that the right data was loaded at the right time before rendering a view. So with all of these issues in mind, we took a first principles approach, the perspective of product engineers, a prototype called SuperGraph, and we decided to rethink established best practices. This ultimately led us to GraphQL. So let's take a closer look. This is the hello world of GraphQL. If I somehow managed to forget my own name, I'd write this query. And I'd send it to a GraphQL API and get back this. And the first thing that you'll probably notice is that a GraphQL query describes the shape of its response. To expand on this a little bit, I might also want to photo of myself and whoever might meet at the next couple of events that I'm attending. That, too, would get back a matching result. A GraphQL request always has, or GraphQL response, always has exactly what the request asked for. Nothing more and nothing less. And there's plenty more to say about the GraphQL language, but here in just these couple examples, we can get a clear sense of how it works. And GraphQL ultimately helped us solve the problems that we are encountering with restful APIs. And first of all, it's fast. Because each GraphQL query describes exactly what's necessary, the backing service only needs to fetch and prepare what's asked for, and the entire result can always be delivered in a single network round trip. And it's robust. GraphQL APIs describe what's possible with static types. Clients describe the requirements with GraphQL queries, which are really just selections over those types. And that means that a query can be verified before it's run, actually before you even commit it into your client-side code base. And on the server, changes to GraphQL types can be statically checked for breaking changes, which eliminates an entire class of software risk. And it's empowering. A GraphQL client describes exactly what they need, which means that they're rarely blocked by waiting on some server-side change. And this means that GraphQL APIs never need to version. In fact, seven years later, Facebook is still on version one of its GraphQL API. Pair this with GraphQL static types, and you now have a platform for building great developer tools, like automatic code generation, API explorers, and IDE integration. And documentation is a first-class citizen of the GraphQL type system, so docs are automatically generated and always up to date. And also importantly, it was adoptable. Despite the QL, GraphQL is not about databases. Just like most REST APIs, GraphQL types are backed by arbitrary user code, which means that they can be used atop existing services and APIs. This allowed GraphQL to be quickly adopted across Facebook, driven by product engineers, and without any significant changes to our existing systems. So in the fall of 2012, we released our new iOS app powered by GraphQL, and Facebook has continued on that path ever since. And around the same time, others in our group had started another project, React. In the next year in 2013, we open sourced React. That ultimately became one of Facebook's most important projects, and it really highlighted the value of open source to our team. And a couple years later, my teammates gave a really amazing talk about Relay, which is a framework that ties together React and GraphQL. It produced a ton of interest, and so the team was inspired to share Relay with the open source community. But they couldn't do that without GraphQL, and so we thought, does it make sense to open source GraphQL? And I'll admit, at the time, I was skeptical. Would people find GraphQL useful for typical APIs, or was GraphQL only really useful for complex things, like newsfeed? And would other notable companies use it? And even if they would, what would it even mean to open source it? GraphQL was really just a bunch of PHP code interwoven with Facebook's core systems. And I didn't really think that sharing a PHP library was going to gain that much traction. But we realized that really the idea, the language, and the interface was what made GraphQL interesting, and less so the actual implementation. So we wrote a specification and a matching reference implementation for Node.js, which we figured would get a little bit more traction than PHP. And we announced GraphQL as an open source project later that same year. So we shared the specification, and then we called on the community to help us write implementations in their back-end language of choice. Totally a Hail Mary pass. But by the end of the year, six such projects were already in the works. And today, GraphQL implementations are available in over a dozen different popular languages, all managed by different community members. And while the GraphQL community started as hobbyists, it quickly grew to include real companies, many of which now you've probably heard of, such as the New York Times, Walmart, Intuit, Airbnb, Netflix, Twitter, Amazon, GitHub, and many, many more. The community is also worldwide. There's GraphQL meetups on every continent, and major GraphQL conferences in America, Europe, and Asia. Today, GraphQL has been an open source project much longer than it was internal to Facebook. The last four years have shown that my early skepticism was unwarranted. The community contributing to and using GraphQL has become far bigger than just Facebook. And to reflect this, we've really shifted our focus to developing GraphQL into a stable base, a top which many tools and businesses can thrive. So to help achieve this and ensure a healthy ecosystem for the years ahead, we're creating something new. In partnership with both Facebook and the Linux Foundation, today we're announcing the formation of the GraphQL Foundation. And so our mission with the GraphQL Foundation is to accelerate development of the GraphQL ecosystem and ensure and enable widespread adoption. And we want to do that in two important ways. First, in collaboration with the Joint Development Foundation, or the JDF, we're going to create a standards body and a technical committee responsible for the advancement of the GraphQL specification and the acceleration of future open standards built around GraphQL. And then the continuing spirit of our existing working group, this is going to be free to join and open to all contributors. The GraphQL Foundation also seeks to create a space for open collaboration and coordination between the many companies who hope to see the GraphQL ecosystem thrive. The Foundation will serve as a neutral open source home for projects and help fund community initiatives. Founding members already include Facebook, AWS, IBM, Intuit, Neo4j, Salsify, Apollo, and Hasura. We're just getting started and we need your help to accomplish this mission. So if this sounds like something that you or your company aren't interested in participating in, please learn more at foundation.graphql.org. And thank you so much for listening to me out. Thanks. That's all. That is cool. First of all, awesome. If you ever get sick of Robinhood, can you come rumble Linux Foundation? Like, you did such a better job than I did. Explaining that. Really amazing stuff. I mean, this, I think this is the future of the API economy. I mean, like, it's an amazing accomplishment. That's the hope. Yeah. Thank you. Thank you so much.