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
Iām wondering if there is any content like that about React.js.
Wonderful recap of how we got to where we are and helps paint a picture of where we're going. Awesome mini documentary. It's all about the shape of your data and the context-aware names of the domain you're working within.
I fell out of love web development personally when my PHP apps were getting too complicated and tangled up. Django (and the world of Python) made me fall in love with it all over again. React did the same thing for me years later but in a higher-level UI space and GraphQL made me realize how it's all possible while maintaining simplicity and separation of duty.
Very neat to see so much come from a PHP world.
Thanks for sharing. Had forgotten this was going to be released.
[removed]