GraphQL: The Documentary
Summary
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.
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
🚀 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.
Mindmap
Keywords
💡GraphQL
💡Mobile Strategy
💡API
💡Community
💡Open Source
💡Newsfeed
💡Prototype
💡Engineering Culture
💡Mobile Shift
💡Open-Source Community
💡Client-Side Development
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
浏览更多相关视频
![](https://i.ytimg.com/vi/7Aj6MLmngsA/hq720.jpg?sqp=-oaymwEmCIAKENAF8quKqQMa8AEB-AH-CYAC0AWKAgwIABABGHIgTyhGMA8=&rs=AOn4CLDyby-KJYxBy7hC5dnj3vAZI8Bapw)
Osvaldo Spadano | Akoova | Unbound Commerce: Harness the Power of Open Source!
![](https://i.ytimg.com/vi/ykFvRoe8xzo/hq720.jpg)
What Could Go Wrong with a GraphQL Query and Can OpenTelemetry Help? - Budhaditya Bhattacharya, Tyk
![](https://i.ytimg.com/vi/1UzSDMJRh8c/hq720.jpg)
History of Python | Python Tutorials for Beginners #lec2
![](https://i.ytimg.com/vi/_dDaNgBDoHY/hq720.jpg)
How to Use Llama 3 with PandasAI and Ollama Locally
![](https://i.ytimg.com/vi/o8NPllzkFhE/hq720.jpg)
The mind behind Linux | Linus Torvalds | TED
![](https://i.ytimg.com/vi/r1h3EYsdvws/hq720.jpg)
Using Open Source Tools to Build Privacy-Conscious Data Systems
5.0 / 5 (0 votes)