GraphQL: The Documentary

Summary

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

Takeaways

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

Outlines

00:00

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

05:04

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

10:08

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

15:09

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

20:10

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

25:15

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

Keywords

💡GraphQL

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

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.

💡Community

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

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.

💡Prototype

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.

Highlights

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.

Transcripts

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