GraphQL: The Documentary

24 Jun 201927:57


TLDRDan Schafer, a software engineer at Facebook, recounts the origins and development of GraphQL, a data query and manipulation language created to address the challenges of building a native mobile app for Facebook. Initially an internal solution, GraphQL was open-sourced and rapidly adopted by the community, leading to widespread implementation across various industries. The talk highlights the importance of empowering engineers and the potential of open-source collaboration in driving technological innovation.


  • 🚀 The inception of GraphQL dates back to 2012, when Facebook faced challenges in adapting to the mobile shift and enhancing their mobile strategy.
  • 🛠️ The initial prototype, 'SuperGraph', was created in just a couple of days, marking the beginning of a revolutionary approach to data querying and manipulation.
  • 🤝 A collaborative effort between Dan Schafer, Lee Byron, and Nick Schrock, along with other engineers, led to the development and refinement of GraphQL.
  • 📱 The motivation for GraphQL stemmed from the need to build a better mobile experience for Facebook's users, particularly focusing on the iOS app.
  • 🔄 The traditional REST API was compared to a vending machine with multiple trips for data retrieval, whereas GraphQL allowed for a more efficient, single-request data access.
  • 💡 GraphQL's design empowers engineers to tackle high-level goals with creativity and innovation, as demonstrated by its organic formation and rapid development.
  • 🌐 The open-sourcing of GraphQL in 2015 and the subsequent publication of its specification fueled the growth of a supportive community and diverse implementations.
  • 📈 The adoption of GraphQL by major companies like GitHub and the development of tools like GraphiQL have contributed to its widespread use and acceptance in the industry.
  • 🔧 GraphQL's flexibility allows it to serve as an aggregation layer, enabling it to integrate with existing systems and provide a smoother transition for companies adopting it.
  • 🔗 The future of GraphQL is envisioned as an industry standard, driven by its collaborative community and the potential to revolutionize client-side development and API design.

Q & A

  • Who are the key individuals mentioned in the script who contributed to the creation of GraphQL?

    -The key individuals mentioned in the script who contributed to the creation of GraphQL are Dan Schafer, Lee Byron, and Nick Schrock.

  • What was the primary motivation behind the development of GraphQL?

    -The primary motivation behind the development of GraphQL was to address the technical challenges and inefficiencies Facebook faced with their mobile strategy, particularly with their iOS app and the need for a better mobile experience for users.

  • How did the shift in consumer behavior towards mobile devices impact Facebook's technical strategy?

    -The shift in consumer behavior towards mobile devices highlighted the need for Facebook to rethink their mobile strategy. It led to the realization that their existing approach, which involved using web technologies to build mobile apps, was not providing the desired user experience. This prompted the decision to rebuild the Facebook iOS app from scratch using native technologies.

  • What were some of the limitations of Facebook's existing APIs that made the development of GraphQL necessary?

    -Facebook's existing APIs were not designed to support the rich, hierarchical data structures required for a full newsfeed experience. They lacked the ability to expose a nested and interconnected data stream, which was essential for delivering the mobile app experience that Facebook aimed to provide.

  • How did the culture at Facebook influence the development and adoption of GraphQL?

    -Facebook's culture, which empowers individual engineers to innovate and solve high-level goals, played a crucial role in the development and adoption of GraphQL. Engineers were given the freedom to explore new solutions, leading to the creation of GraphQL as a more efficient alternative to their existing APIs.

  • What was the initial code name for the prototype that later became GraphQL?

    -The initial code name for the prototype that later became GraphQL was 'SuperGraph'.

  • What was the significance of the release of the native iOS app 5.0 for Facebook?

    -The release of the native iOS app 5.0 for Facebook was significant because it marked the first time that GraphQL was deployed in the wild. It represented a major step in Facebook's mobile strategy and the successful application of GraphQL in a real-world scenario.

  • How did the open-sourcing of GraphQL influence its adoption and growth?

    -The open-sourcing of GraphQL led to rapid adoption and growth. It allowed the community to contribute to its development, leading to implementations in various programming languages and the creation of a rich tooling ecosystem. This also led to wider recognition and adoption by companies across different industries.

  • What was the role of GitHub in the validation and promotion of GraphQL?

    -GitHub played a significant role in validating and promoting GraphQL by adopting it for their public API (v4). This move provided a strong endorsement of the technology and signaled its potential to become an industry standard.

  • What does the speaker predict for the future of GraphQL?

    -The speaker predicts that GraphQL is entering a new phase of its life, where it will become an industry standard for data querying and management. They anticipate that GraphQL will continue to be developed collaboratively by the community and widely adopted by various sectors.

  • How did the success of GraphQL impact the speaker's perspective on open source communities?

    -The success of GraphQL made the speaker realize the power and potential of open source communities. They initially underestimated the impact of open sourcing a document and a piece of software, but the community's spontaneous formation and contributions to building implementations and tooling ecosystems proved to be remarkable and pivotal to GraphQL's success.



🚀 Introduction and Background of GraphQL

The speaker, Dan Schafer, introduces himself as a software engineer at Facebook and one of the creators of GraphQL. He reflects on the growth of the GraphQL community from 200 people two years ago to 800 at the current conference in Berlin. The origins of GraphQL date back to the industry shift towards mobile, where Facebook's initial mobile strategy was not effective. The company realized they needed a better mobile experience, leading to a complete rewrite of the Facebook iOS app using native technologies. The server-side architecture, which was not designed for mobile applications, posed significant technical challenges.


🤝 The Emergence of GraphQL

The narrative continues with the challenges Facebook faced in building a mobile API to support newsfeed and the need for a change in internal development approaches. The empowering culture at Facebook allowed individual engineers to propose solutions, leading to the creation of GraphQL. The story highlights the collaboration between Dan, Nick, and Lee, who worked intensively to develop GraphQL. The team aimed to have the new API ready for production by a specific deadline, with the iOS app rewrite and GraphQL needing to work in tandem. The effort resulted in an intense, yet exciting period for the developers.


📈 Adoption and Evolution of GraphQL

GraphQL's initial deployment was with the release of Facebook for iOS 5.0, marking the beginning of its use in the wild. Over the next year and a half, the GraphQL API was expanded to cover most of the iOS app's functionalities. The speaker discusses the multiple round trips in mobile development and compares traditional REST APIs to GraphQL's efficiency. The analogy of a vending machine is used to explain the benefits of GraphQL's ability to fetch exactly what's needed in one request. The speaker also mentions the early days of GraphQL's open-sourcing and the anticipation of its potential impact on the industry.


🌐 Public Release and Community Involvement

The speaker shares the journey of GraphQL's public release, the creation of the specification, and the reference implementation in JavaScript. He talks about his own experience as an early adopter and the rapid uptake of GraphQL by the industry. Companies like Twitter and Medium adapted GraphQL for their needs, creating a gateway on top of REST APIs to gradually migrate to GraphQL. The speaker emphasizes the flexibility of GraphQL as an aggregation layer that can work with existing systems and the rich tooling provided by the open-source community.


🔥 Growth and Impact of GraphQL

The speaker discusses the rapid growth of GraphQL in its first year after open-sourcing, with implementations in various programming languages. He highlights the pivotal moment when GitHub decided to adopt GraphQL for their public API, signaling the technology's potential for widespread adoption. The speaker shares his experiences with the community's excitement and the diverse applications of GraphQL, from car companies to the police in Switzerland. He reflects on the power of open-source communities and the joy of programming that GraphQL brings to developers.


🛣️ The Future of GraphQL

The speaker envisions GraphQL's next phase as an industry standard, driven by collaboration within the community. He reflects on GraphQL's journey from a Facebook internal tool to a widely adopted community tool and anticipates its future as a standard across the industry. The speaker emphasizes the joy and creativity that GraphQL brings to software engineering, allowing developers to build more efficiently and effectively. He concludes with a reflection on the success of open-source projects and the willingness of the community to contribute to realizing a shared vision.




GraphQL is a query language for APIs and a runtime for executing those queries with your existing data. It was created by Facebook to solve specific problems they were facing with their mobile applications, particularly with the iOS app. It allows clients to request exactly what they need, reducing over-fetching of data and improving the efficiency of data retrieval. In the video, the speaker discusses the evolution of GraphQL from its inception as a solution for Facebook's internal needs to becoming an open-source project adopted by the broader software development community.

💡Mobile Strategy

Mobile strategy refers to the approach a company takes to engage with users on mobile devices. In the context of the video, Facebook's initial mobile strategy involved using web technologies to build mobile apps, which resulted in a subpar user experience. The realization that this strategy was not effective led to a shift in Facebook's approach, with a focus on building native mobile applications using technologies better suited for mobile platforms.


API stands for Application Programming Interface, which is a set of rules and protocols used for building software applications. In the video, the need for a new API to support the newsfeed and address network issues was a driving force behind the creation of GraphQL. APIs are crucial for allowing different software systems to communicate and share data with each other.


In the context of the video, 'community' refers to the group of individuals and organizations that contribute to and use GraphQL. The community is responsible for its growth, development, and adoption. It includes software developers, companies, and hobbyists who have collectively built an ecosystem around GraphQL, creating implementations in various programming languages and contributing to its tooling.

💡Open Source

Open source refers to a philosophy and practice of allowing others to view, use, modify, and distribute a work under certain licenses. In the video, GraphQL was open-sourced by Facebook, meaning the company made the codebase publicly available for anyone to use and contribute to. This has fostered a collaborative environment where the community can improve and expand upon the original code.


Newsfeed is a feature commonly found in social networking services, like Facebook, where it displays a continuous, regularly updated list of summaries of new content posted by friends and connections. In the video, the need to build a better newsfeed experience for the mobile app was one of the key drivers behind the development of GraphQL. The newsfeed required a more sophisticated and efficient way of handling data retrieval than what the existing APIs could provide.


A prototype is an early sample, model, or release of a product built to test a concept or process. In the video, the initial prototype of GraphQL, called 'SuperGraph', was created by Nick Schrock in a few days. This prototype laid the foundation for what would become GraphQL, allowing for the exploration of the idea of an object graph from back to front, which was a departure from the relational system approach.

💡Engineering Culture

Engineering culture refers to the values, practices, and attitudes that define the work environment and approach of engineers within an organization. In the video, the engineering culture at Facebook is highlighted as being particularly empowering, allowing individual engineers the freedom to innovate and find solutions to high-level goals. This culture was instrumental in the creation of GraphQL, as it encouraged engineers to take ownership of the problem and collaborate to develop a new system.

💡Mobile Shift

The mobile shift refers to the industry-wide trend of consumer behavior moving from desktop computers and browsers to mobile devices. This shift has significant implications for businesses and technology companies, as it requires them to adapt their strategies and products to cater to the growing use of mobile devices. In the video, the mobile shift is a key factor that led Facebook to rethink its approach to mobile applications and ultimately to the creation of GraphQL.

💡Open-Source Community

An open-source community is a group of individuals who contribute to and support the development of open-source projects. These communities are characterized by collaboration, shared knowledge, and a collective effort to improve and maintain software. In the video, the open-source community around GraphQL is highlighted as a driving force behind its rapid adoption and growth, with members contributing to its tooling and spreading its use across various platforms and languages.

💡Client-Side Development

Client-side development refers to the process of creating and maintaining the client-side of web applications, which includes the user interface and user experience. This involves writing code that runs in the user's web browser or on their device, as opposed to the server-side, which handles backend processes. In the video, client-side development is discussed in the context of how GraphQL has impacted and improved the efficiency and ease of data retrieval for front-end developers.


Dan Schafer, a software engineer at Facebook, discusses the creation and evolution of GraphQL.

GraphQL was developed about seven years ago by Dan Schafer, Lee Byron, and Nick Schrock.

The growth of the GraphQL conference from 200 people to 800 attendees in just a few years reflects its increasing popularity.

The origin of GraphQL dates back to the industry shift towards mobile and Facebook's struggle with their mobile strategy.

Facebook's initial mobile strategy involved using web technologies, which led to subpar user experiences.

GraphQL was born out of the need to rebuild the Facebook iOS app with native technologies and a better technical architecture.

The collaborative and empowering culture at Facebook played a crucial role in the development of GraphQL.

The initial prototype of GraphQL, named 'SuperGraph', was written by Nick in just a couple of days.

Lee Byron and Dan Schafer joined Nick in developing GraphQL, leading to an intense two-week period of development.

GraphQL was first deployed in the wild with the release of Facebook for iOS 5.0, marking a significant milestone in its development.

The decision to open-source GraphQL was influenced by the foresight and initiative of its creators.

GraphQL's ability to serve as an aggregation layer and integrate with existing systems has contributed to its widespread adoption.

The community-driven development and tooling around GraphQL have been instrumental in its success.

GitHub's decision to adopt GraphQL for their public API v4 was a turning point for the technology's recognition and growth.

GraphQL's potential to become an industry standard is highlighted by its rapid growth and diverse applications.

The power of open source communities in driving the development and adoption of technologies like GraphQL cannot be underestimated.

GraphQL's unique approach to data querying and manipulation has solved a multitude of front-end development problems.

The story of GraphQL illustrates the impact of empowering engineers to innovate and the importance of community in shaping technology.



For those of you who don't know me, my name is Dan Schafer, I'm a software


engineer at Facebook and along with Lee Byron and Nick Schrock helped to create GraphQL


about seven years ago it is unreal to be here I feel like I


say this every time because every time it's true you know looking around the


room it was 200 people two years ago 400 people last year 800 people here in


Berlin today for a GraphQL conference this doesn't happen without you the


community so thank you all for coming


this is GraphQL think I'm not giving anything away there I feel like at this


point the story of GraphQL we've told it a bunch of times you know we've told


that story of the initial prototype in February of 2012 and you know hacking in


the corner and trying to figure out what this was going to be and eventually


shipping it in the iOS app in August the open sourcing in July of 2015 and then


of course where we are today but the story that we haven't told quite as much


and the story that I think is really important to understand GraphQL and why


it exists and a lot of the decisions we made is that pre-history what I'd like to


talk about today is what GraphQL was before GraphQL


the origin stories of GraphQL really date to sort of a shift in not just what Facebook was


doing but in the industry as a whole and that shift was mobile it was clear at


that juncture in the industry that massive amounts of adoption and usage


was shifting to mobile like a systematic shift in consumer behavior it was also


very self evident that the Facebook mobile strategy was not working we were


a web company we were really good at building websites let's have our mobile


app be a website like that's what we can do we can deploy it quickly we can take


a lot of our experience and apply it there and what we were realizing about


about 2011 is this was just not going to give an experience that we wanted our


users to have we had built these apps that were leveraging web technology in


order to build mobile apps and that was not working at a technical level every


year the native applications got higher and higher quality and and the mobile


browsers got kind of worse and worse in buggier and buggier and slower here we


were with our Facebook mobile website with our native apps just being thin


wrappers around this website and it wasn't good I mean now Mark (Zuckerberg) famously


says that the decision to adopt HTML5 on mobile was the worst decision in the


company's history the biggest risk that he noted in that was that we hadn't


figured out mobile yet and we were watching this industry shift from


desktop computers and browsers to mobile phones and we didn't really have a good


wrap on that so this was a big deal the inability of a large technology company


to adjust to a technology shift as big as the mobile


shift is the type of thing that will like consign a seemingly unstoppable


Empire to the grave in a matter of a few years right so this is a big deal at the


company and so we really took a hard look at what our strategy on mobile


was and said you know what we need to rewrite the Facebook iOS app we had spun


up a team filled with a lot of iOS veterans, a lot of them who were new to the company and


then they also injected some existing folks from Facebook to rebuild the iOS


app from scratch using native technologies the standard joke is they


started and hit file "new project" they started with our existing


APIs and immediately hit issues we had never built a mobile application where


all of the logic happened in the application and it treated the server


like just a API to load data from that kind of technical architecture had never


existed before it wasn't just that you had a list of stories or each story had


no here's the person who wrote the story here's what they said


here's a list of comments done no they were like interconnected and nested and


recursive and there's a lot of really complicated things going on those api's


at the time weren't really designed to allow you to expose a full rich newsfeed


like experience they didn't have sort of this hierarchical nature they didn't


have this easy ability to select what you needed they didn't have the ability


to you know display a list of heterogeneous feed stories which was


something that we would need to do and so we had all these like problems that


were coming to us we had to build an API to support newsfeed we had to deal with


this network issue we had to kind of change the way that we were thinking


about building things internally from returning HTML files to returning raw


data and then these mobile teams that were trying to build this


compelling app so a lot of these like questions were bubbling up in parallel


around the company we sort of emerged at the start of 2012 going you know what we


are probably going to need a new newsfeed API in order to build the


mobile app that we want to deliver to our users


one of the things I think was unique about Facebook at the time and it really


still holds true today is just how empowered sort of individual engineers


are to figure out what is the right way to accomplish high-level goals and in


this case you know the company did have this high-level strategy we knew that we


had to build this native mobile app we had to have a better experience but even


that's probably saying too much I don't know that we necessarily as a high-level goal


needed a native mobile app that's almost too tactical


we knew that we needed a better mobile experience that was sort of the vision


that was the thing that the company was oriented around and the decision of ok


this needs to be a native app in order to accomplish that, that was engineers on


the ground saying hey this is how we're going to build the experience that our


users want. Without a culture that really encourages that level of creativity that


level of innovation and that empowerment of like hey yes, I'm gonna go work with


these two people who you know my manager probably knew who they were but like you


know that wasn't a collaboration that we were trying to do strategically or


anything it was just the right thing to do and so we did it


the very first sort of piece that happened was when Nick wrote up just a


prototype the initial prototype only took a couple of days to write. He wrote


this prototype it was called "SuperGraph" he put the the code up for review and


and tagged like a dozen people instead of like mapping what we had this kind of


like object graph and like contorting it to be a relational system what if we


just make it an object graph all the way from back to front it was super


interesting and I immediately kind of got addicted to this idea and then


that's when Lee entered my life and he you know he didn't have a bowtie on but


he hopped down to my desk he's like this is really interesting I have some


feedback what if we also did this Oh what if we also did that oh I've been


already thinking about the newsfeed problem and how to relate it from the


mobile site so what if I took my idea and introduced it here I know Nick was


looking at this I know Lee was looking at this Bo was someone on the mobile


team who was looking at this and eventually the three of us got to


talking that's when Dan got involved and so


we're starting to talk to Dan about this and and then he got really


excited about the idea as well it's like oh this is this is a really interesting


way of how how we could tie all these things together I was also kind of


talking to Dan a lot during this time and we had worked together so the team


kind of naturally organically formed and then we were off to the races. And that


led to probably the most intense two weeks of my career so far you know even


six years on nothing compares to it, where Lee, Nick, myself and I believe


Jonathan Dan, who was an engineer on the iOS app at the time, basically found four


desks that were sort of off in this corridor that you know no one was really


using at the time because we had plenty of space on campus we had just moved


and like let's go and build this thing even then we weren't a hundred percent


confident that was the right call but we thought it was worth trying and so we


got some some head space to try that out. Dan was utterly critical because he knew


more about newsfeed and the way it operated than anyone else at the company


what Lee brings is that deep hardcore computer science like he can


write a parser, he can write a compiler and he also brought a certain design


aesthetic to it as well that was kind of the combination that


made it work we took a hard goal and we started racing towards that. This thing


has to be up, production-ready, serving api requests, and to do everything


that newsfeed does by this date. A lot of clocks had to strike midnight at the


same time in order for this to work. The feed rewrite needed to work we needed to make


GraphQL work, the native mobile team had to execute and there's a ton of unknown


technical complexity and all that stuff. And then we just kind of got into this


rhythm where you start working like ridiculous hours not because anyone was


asking us to you but like we were addicted it was one of the coolest


experiences of my life to just be so excited about what we were working on


that you know we almost couldn't be torn away from it GraphQL started to kind


of take shape in those couple of months and this sort of went until August, it was


actually mid-August that we released what was at the time known as Facebook


for iOS 5.0, it was the native rewrite, it was the first time that GraphQL was


deployed in the wild and really over the next probably year and a half


expanded sort of the surface area of the GraphQL API to not just cover newsfeed


but really to cover most of the product that is the iOS app you know


then and the iOS app today and that was sort of the end of that initial chapter of


GraphQL's development I might self-emulate. Alright, the one stick I have


is explaining it in terms of multiple round trips so I explained it okay..


You have a mobile phone, you have a server, it's like a vending machine and


so traditional rest is like you press one button and get one thing and then


this problem happens where you press one button get one thing you have to press


lots of buttons one at a time and that's slow so what people do is they make a


special-purpose buttons that like say like one button you get


four things another button you get five things. This reminds me of the episode of The Office


where all of Dwight's stuff gets locked in the vending machine. Just a handful of


like quarters and he has to, one at a time, retrieve every desk item from the


vending machine Well but if like that bag of


quarters was also in the vending machine like you got to put a quarter in to get


the bag of quarters out so that you can put a quarter in to get another thing


out like I can only do one at a time imagine you invent a new thing where you


can press exactly the buttons you want and then get it in one shot but in combination


with that, it's way more fun.


I have no idea if Nick anticipated that GraphQL


would be where it is today three years ago but it wouldn't surprise me if he


did like that is sort of his you know that gift of foresight and the


ability to say you know what just as in 2012 we could sort of guess or he could


sort of guess like this is going to become the future of you know Facebook's


native mobile apps, in 2015 I think he was looking saying you know what this


could be big, this could really you know change the industry


I definitely was


trying to persuade Lee to open-source this for a while I think I


referred to it as my Byronic fantasy actually my initial reaction wasn't like


that sounds amazing like when can I start helping it was "are you sure?"


Convincing Lee to do something is a process and then all of a sudden "I agree!


and we should totally redesign the language and open-source a version that we


don't use." and I'm like what are you talking about? So my pitch to Nick was


let's take a first principles look at GraphQL, if we started GraphQL with what


we know now and redesigned it, what would we build? A lot of the changes


that we ended up making a lot of the you know things that makes it feel even more


designed today than it did in you know 2012 came from Lee and then the thing I


was able to sort of look into was like okay if we're gonna be you know at React


Europe in July, where do we have to be by June? Where do we have to be by May? We


had this vision that this could really change the industry and we had a thing


that we're like yes this is ready to go this is gonna be usable you kind of have


that special feeling like wow this is actually gonna be a system that is gonna


move the needle this is gonna be the way we're gonna


build apps now. All of us kind of understood that like if successful that


would be true so it was you know it was an exciting thing to build. We decided it


would be really nice to announce all the work that we had been doing publicly to


a crowd and so React Europe was the next conference coming up that we knew would


have reasonable attendance and kind of aligned with this community that we


wanted to talk to we called it a draft, there's definitely parts that were


still very rough and the reaction kind of blew us away


Good afternoon thanks for


joining us today let's start by talking about client-side development today this


is GraphQL since January inspired by your enthusiasm, Nick, Dan and I, along


with a handful of our co-workers, have been busy on a project to evaluate every


detail of GraphQL, making improvements, fixing inconsistencies and writing a


specification that describes GraphQL and how it works we really hope that


this helps those of you who are excited to build versions of GraphQL for your


own servers. GraphQL has a lot of excitement in the community we tried to


design what we thought was the ideal API for front-end developers and then work


backwards to the technology we've already seen you know a ton of people


interested on GitHub. So today I'm really excited to share with you that we have a


working draft of the spec that is now public


Later in 2015 is when the GraphQL spec was first published along with the


reference implementation in JavaScript and I was one of the first users of


the JavaScript reference implementation I'm pretty positive that Tim Griesser


and I put that into production like two weeks after it was first announced we


were even starting to like see like could we build something kind of like


GraphQL like very quickly that was like not fully featured but kind of gave us


similar benefits and right as we were starting to actually think about doing


that is when GraphQL was first released and so we started using it right away


GraphiQL the tool that lets you kind of explore your GraphQL API that was also


announced at the same time and I immediately wrapped it with like


an electron wrapper so that I could use it outside of it being being hosted on a


web server somewhere and that graphiql-app is still on my GitHub and is used


all over the industry and I built that like within hours of GraphiQL first


being released which was which is pretty funny so I was definitely a GraphQL early adopter


Twitter's kind of been like an inspiration at least for like


Medium and other places because they're like a big company that's using GraphQL


I was kind of like one of the driving forces at Medium for trying to get


GraphQL going. Everyone does it a little bit differently but a lot of people who


are using, who are coming from like a kind of like a legacy system like they


aren't starting off with GraphQL just like immediately usually people are


like oh GraphQL is gonna be awesome but we can't do it you know just plug


everything in so we have to put it on top of something so they create this


like GraphQL gateway that sits on top of the REST API and that's like that


kind of like you know gives you the time to sort of start migrating stuff off of


like rest if you want or changing it around or doing something else on the


backend while still getting like the benefits of GraphQL that's like what


Medium did, it's actually also sort of what Twitter did so we have GraphQL and


we're using, some of it's sitting on top of a REST API, but it's also connecting


to like other micro services and stuff but we actually have this intermediate


system called Strato which is kind of like you can think of it as like a


virtual database kind of thing so what GraphQL ends up doing is just


querying Strato and then Strato kind of gets all the data and it's already like


defined there for you and so from that you're able to generate the schema and


everything's kind of nice so now it's like all you have to do is kind of like


make one update to Strato for like oh I want to add this like new like some new


data to it and it's kind of automatically generated now it's in the


GraphQL schema and you don't have to you don't have to like be hand you know


or like hard-coding anything in the schema you can just like develop way


faster instead of having to go through like the whole process of like


connecting everything.


It got uptake faster than I anticipated for sure.


GraphQL came out of the gates with a lot of people really in support early on it was


way more positive than we had thought and it really quickly became clear that


there was this demand in industry for a solution like GraphQL the solution that


we'd come up with, the problems that we were trying to solve weren't specific to


Facebook, they were something that a lot of companies were having.


Prisma, you know Johannes


at Prisma spotted this really early and started prototyping really


interesting ideas and then there's a bunch of other companies that thought


wow like this presentation they're talking a lot about the same problems


that we're facing we should try this


The client-side developer tooling that that GraphQL and the open source kind of


community around GraphQL provides is like it's unparalleled compared with


anything in the rest ecosystem a developer can with minimal minimal


amount of code get data into their component if they're using React on the


web or into their views in iOS or Android with basically zero boilerplate


I think that GraphQL is very interesting in the sense that it is not


a you know one shop fits all. like it's gonna rule your world and you got to


rewrite everything, like a lot of power comes from GraphQL being an aggregation


layer, so like if you got an old soap API that no one knows how to run ok cool


just wrap it with GraphQL


To me GraphQL feels a lot like React


just you know you look at React just like a whole bunch, a whole class of


problems that you had when you're building UIs just disappear


and with GraphQL, a whole class of problems around what is my data and how


do I get it in the form that I need it and you know into the website


just disappear and it really solves a lot of front-end problems


so this first kind of year after open-sourcing, it developed really rapidly


within six months we had implementations of this thing in most of the


programming languages that we cared about which was completely shocking it


started with these new companies that thought this is interesting we want to


try it a lot of hobbyists building it out and so I think the community


developed really rapidly as a result of having those pieces out. The moment when


we really went oh wow this is going to be big


it was GitHub, which is GitHub at one point reached out and then eventually


announced that they were going to have their public API their v4 API be a GraphQL


API. Once that happened that was sort of the moment we all went okay cool we've,


this is going to take off.


It was in 2016 when we started to explore kind of what


sort of new tools can we add to our users' toolboxes and that was when the


idea of GraphQL came up someone someone pitched it internally opened up an issue


and said what do you all think about this at its core it's just a document


right it's just a piece of paper that says when you return data to your users


do it in this way and they can ask for this but what we ultimately really


wanted was a way to empower our users to be able to get to ask us for the data


that they need and that was where the the power of GraphQL really shined so


in early 2016 one of our engineers took about a week or so to do a proof of


concept he was able to accomplish it in about a week and a half and we had like


the ability to get repositories and users and all of this data in just the


matter of a week which was unbelievable and so it was about eight months later


that we released our GraphQL API in early access that was the time when


there weren't really many other public APIs that were GraphQL APIs


Facebook, the inventors of it, had only created it and used it internally and


they had a different type of API, not a GraphQL API, that they exposed and so we


had the good fortune of being able to talk with Lee and Dan and Nick about this


is where we'd like to go with this this is the the public version that we would


like to launch what do y'all think and they were they were ecstatic they were


thrilled they were they were so excited being able to see what the schema could


look like and so I believe it was in October of 2016 we launched kind of our


alpha our early access of a GraphQL API and I remember Kyle Daigle and


Dan getting on stage and kind of demoing it and I'm sitting in the front row


being like this is so cool this is this is that eight months of hard work and


being able to think about what our users could build with it was amazing and


after that it just kind of spread like wildfire we we had the opportunity of


companies coming to us asking like hey what's your experience been with GraphQL


There were all these different organizations that were saying hey how


did you do the public API because that was something that was relatively new I


think Shopify had started to do that as well but again the GitHub API is just so


broad that there's so much data to cover and so I remember at GraphQL Europe


hearing from like car companies, the police in Switzerland I believe


it was where like they're implementing GraphQL and like they're powering these


really amazing technologies and that was just surreal to see and that was where


we started to see the community really start to explode and more and more


interest which was fascinating


My parents were so excited like you're doing a taping for a documentary you're


gonna be in a documentary. Oh it was so funny, like it was my contractor, a new hire I


have, his second day, and then they come in and it's like "Oh I gotta do a filming."


I'm really excited to see GraphQL sort of enter this next phase of its life


where it started its first three years as a Facebook internal problem built


really to solve like a very specific problem, which was the newsfeed API


for our iOS app and then it expanded from there to solve more problems at


Facebook it open sourced and it became a community tool initially used by


hobbyists but eventually used by companies and so for the last three


years that's been the story of how GraphQL has gone from a Facebook tool to a


community tool and I think it feels like to me that it's about to enter in the


next phase of its life which is becoming an industry standard that's kind of


where I see GraphQL going forward is hopefully an industry standard and


one that's collaborative by all the people that have been helping so far the


joy of programming the joy of software engineering in general is like you've


been given this toolbox it's like go and make whatever you want like go and make


whatever you have in mind. Basically the world is your oyster


And I think GraphQL for a lot of people is like it was this tool that


they never had before they've never used before and once they had it they were like


wow I can build more fun stuff with this I can you know create greater things and


you know GraphQL somewhat spread throughout Facebook and spread


throughout the industry because people liked using it and you know if there's


one takeaway it's like if you build something that people like using it'll


generally do pretty well I totally underestimated the power of these


open source communities because like I said before previously


in the interview, we just open-sourced a document


and a piece of software that was written to execute that document effectively it


wasn't being used in production at Facebook and then it was we had to rely


on this community of people to form spontaneously and then build


implementations of this in different languages and then actually


productionize it and build an entire tooling ecosystem around it I didn't think


that was ever gonna work and I was totally wrong if an idea makes sense to


people and it just clicks with their mind and they can see the vision they're


actually willing to do a lot of work in order to see it executed and then share


their work and it's a pretty remarkable thing to see

Rate This

5.0 / 5 (0 votes)

Related Tags