- Alright, hi everyone how're you feeling? It's the end of the day. I'm the last thing between
you and drinks on the roof so I will take my time. (laughing) You know I'm really excited to be here and see this huge audience
that's kind of crazy, you know, GraphQl's four years old but it's only been public
for a little over one year and when we first opened source GraphQL, if you told me that a
little over a year later I'd be closing at a
conference dedicated to it, I probably wouldn't have believed you. And really at that
time, I wasn't even sure if GraphQL was gonna be
relevant outside of Facebook. Of course, you all here today
have proven me so very wrong. And I am thankful for that. It's actually really amazing that today almost all of the talks you heard were from people outside of Facebook, all using GraphQL within the last year. It's amazing. And our community, our GraphQL community, which is way bigger than just the people who are in this room has been growing rapidly. Way faster than I've seen
some of the other communities that we've started at Facebook grow. And speaking of these expectations, sort of shortly after we
opened source GraphQL last year I started to scribble down
what I thought would happen. It's kind of like my best case scenario for a secret master plan for
GraphQL world domination. This is what it looks like. (laughing) Yeah. First I thought, you know,
we'd see some hobbyists and personal projects
in the first few months, you know, cause they've
got nothing to lose. Why not try something new? And then maybe in the first
six months we'd see it implemented in a couple of new languages, that's why we shipped it as a spec rather than just software. And then maybe somewhere
close to the one year horizon, we'd start to see some startups and some riskier crews take on GraphQL and maybe at a year and a half mark we'd see some really cool
tools for using GraphQL. And then closer to two years
we'd see medium-sized companies and then like closer down
here to like four years we'd see big companies and tech giants. For the first few months
I was pretty excited. I was like, "Oh yeah this is happening. This is awesome." And then I saw a handful of people, a lot of them in the room, some of them who did the TEDtalks start to pick up GraphQL and start some of those early personal projects
that were really exciting. Then we got here way
faster than I thought. So I thought it was gonna
take about two years for GraphQL to get implemented
in most major languages so I put like a rough
line at like 10 languages. That happened in like
three and a half months. It's blown out of the water and I think it's pretty safe
to call GitHub a large company, and I think it's pretty safe
to call GitHub a large company, maybe even a tech giant. And they're of course roleing
out public GraphQL APIs now. Now we're not to this last step, ubiquity. We're not here yet. So we have a lot of things
that we still need to build, but I just want to say
overall I'm just so impressed by how quickly we've blown away my totally wrong assumptions
about what would happen. And for those of you that I haven't had the opportunity to meet yet, hopefully I'll get to meet some
of you up on the roof later, my name is Lee Byron. I work at Facebook on a team
called Product Infrastructure, where I was one of the co-creators
of GraphQL four years ago and I now have the distinct pleasure of managing the evolution
of the GraphQL language and help it integrate into some of our other services at Facebook. So since the creation of GraphQL
I've watched our use of it evolve to cover more
of the Facebook product as well as watch GraphQL itself evolve to handle different
scenarios and use cases. And even when we open
source GraphQL last year, we were in the middle of one of the most significant evolutions of GraphQL since it's creation. And over those four years I've learned a lot about how to best use GraphQL and today I'm gonna share some of those things with you today, but we've also heard a lot of stories and practical advice so far so I want to go further than that. I want to talk about some of the advice that I can provide from building that I can provide from building and scaling and using GraphQL services, but also the best practices
from building GraphQL itself. And then after that I
want to talk about some of the stuff that's guiding
the future evolution of GraphQL since I know that's
kind of a popular topic. But before we do that let's rewind a bit and look at a brief history of GraphQL. So hopefully it's interesting to hear a little bit about where this thing came from and also maybe dispel any notions that kind of GraphQL arrived
into this world fully formed in the state that you find it today. Certainly not true. So first came the original idea, which came from my co-worker
who's sitting in the back, Nick Shrock. He introduced what he
originally called SuperGraph. So he was one of the founding members of our Product Infrastructure team and up until this point, he was helping to build our servers data loading and privacy checking abstractions. And he had this idea that we could take all of the work that we had done so far and then expose it over an
API for our mobile apps, which at this time were
just getting rebuilt. So Nick built a prototype of SuperGraph, really over the course of a couple days. Then enough of us were excited that we started doing the initial development of what would be the very
first version of GraphQL. I was working really
closely with our iOS team on improving their newsfeed API. And so Nick and I started to work together to adapt SuperGraph to
support newsfeeds use case. And then Dan Schafer,
who's also here today was an engineer on the
newsfeed server team so he definitely was part
of making all this possible and joined our crew as well. So things happened quickly
and we evolved GraphQL to meet the needs of the iOS newsfeed and within three weeks we had
something that they could use and then a couple months after that we had completed support for
all of newsfeed on GraphQL. And then in August of 2012
we launched this new app, the new iOS newsfeed
and when other teams saw just how fast it was and
then heard from that team about the developer experience, we were quickly inundated with requests to extend GraphQL to support
more products at Facebook. First we had profile then
photos, groups, and events and this is when we actually bothered to form a team around GraphQL so we could support this
thing that we had built. And during this time
we learned a lot about how to design good APIs and I'm gonna talk a little bit about that later, but most of our work in this time was just making sure that the type system continued to make sense as we evolved it over the four years. We heard a little bit about
that in the panel today, but I'll talk about that as well. But also in this time we encountered all of the different use cases that we had for GraphQL that we didn't anticipate. So during this window of
time we added fragments, mutations, subscriptions,
native code generation, persistent queries. We built Graphical. We built Relay. So a lot of the stuff that's
either been folded into GraphQL or has since become best practices, or other open source projects were all started or built
during this window of time. Then in January of last year,
Dan Schafer spoke publicly about GraphQL for the very first time in a talk at the React Conference in 2015. And honestly we are just totally
overwhelmed with reception. It was like a footnote in a conversation about kind of how we were
building things at Facebook and people grabbed onto it and said, "When can we have this?" We're like, "Woah." This was not supposed to be
an open source announcement. We just wanted to tell you
what we were working on. So this got us all fired up. We were like "Alright this great. We gotta figure out how to
share GraphQL with the world." But what does that mean exactly? How do you do that? You know, GraphQL's server was tied deeply into how Facebook worked
and we didn't really know how to extract it. But we also weren't that proud of just how complicated GraphQL had gotten over the previous years of adding all these
additional things into it. You know all these quirks
and inconsistencies and the assumptions that we made when we first started
GraphQl back in 2012. They were all still there. So we decided to reevaluate. We redesigned all the details of GraphQL. We made improvements. We fixed inconsistencies. We redesigned the syntax and the semantics in order to incorporate everything that we had learned over
this window of time. And this process took months. It required a way more
deliberate and careful process in comparison to the
early, rapid iteration that characterized the early
development of GraphQL. And this ended of course with us open sourcing a specification that describes GraphQL and how it works, as well as a new reference implementation written in JavaScript. And we choose JavaScript, not
just cause we like JavaScript, we do like JavaScript at Facebook. But because it's ubiquitous language. More people know it than
almost any other language and it let us build tools on top of it that were very portable. In fact the version of Graphical that we rebuilt during
the same window of time in open source shortly after this is built on top of GraphQL JS. And then anyone in the audience, who's maintaining an open source project knows what I mean when I say
that open sourcing something is the beginning not an end. So we knew that we were
gonna get a ton of feedback on this thing that we had just announced, or rather we hoped that we
would get a lot of feedback and we definitely did. And so we released GraphQL
with technical preview right in front of it. We did that on purpose
to set expectations. This was something new. This was something that
we were still working on and it was going to continue
to evolve over time. And during this period of time, we started to see all of the things that a lot of people have
presented about today. Implementations in GraphQL
started by the community. Today you can find that in over
a dozen different languages and I won't go deeper into
that cause we already saw in the keynote this morning
just how many awesome projects are being built in GraphQL, which brings us up to recent events. So a little over a year
ago GraphQL's being used not just at Facebook but at
a whole bunch of companies, big and small. And then last month to reflect this, we finally removed that
technical preview moniker. And we launched a new
website at GraphQL.org to help people learn more about this thing that we'd all built. And if you haven't checked it
out yet you definitely should. A lot of the community
members, folks in this room, contributed a lot of the work involved to make this thing work so it's really an effort of the community. And so as GraphQL evolved
within Facebook over the years we've added a lot of
stuff to our GraphQL API. And over this period of time
we've learned a lot about what's important and why
when designing those APIs. So I want to talk about
some of these best practices that we've boiled down from
the lessons that we've learned. And, you know, since we've already heard a little bit about
some of these best practices, especially around clients
and my co-worker Joe already talked about clients. So I'm gonna focus
specifically on API design. And let's jump right into it. Alright, most important. Naming matters. We already heard a little
bit about this in the panel: What do you do when you have to change the name for something? Naming things is super
important in GraphQL APIs, especially since if you're
not used to designing APIs you might think like, "Ah,
we'll come up with a good name. If it's not good, whatever,
we'll refactor it. Refactoring's easy." But no, GraphQL API as soon as a client is making use of a field,
you're kind of stuck. A naming mistake can be really expensive. So beyond silly mistakes, you know, hopefully we can avoid those. An important question to
ask while designing APIs is will a new engineer understand this? And that means no code
names or server side lingo. Imagine that most of the engineers that are gonna be using your API might not find it so easy to go figure out how that field maps to
some underlying system. Maybe they're spending all their time in an iOS or an Android code base, or their just new and they
can't figure that out. So it's really important
not just to have names that are good but to have names
that are self-documenting. And also we're kind of
spoiled by really cool tools like Graphical so must of us don't actually read API documentation. We just go here and we start typing what we think the thing will be named and if something comes
up we're like, "Oh cool. That's probably what I want." So naming things that adhere closely to what those things actually
do is really important to help make this
experience actually work. Alright naming matters so much
when we talk about GraphQL because we talk about
GraphQL as being versionless, a versionless API, as
long as we only add to it, all existing queries continue to work and you don't need versions. And I often here, "Yeah, yeah, yeah, okay. That's great in theory, sure, but like how do you actually handle
breaking changes in public?" I'm like, "No, actually at Facebook we don't do breaking changes." They're extremely rare. And that's because we design GraphQL APIs with designing for the future in mind. So we ask ourselves this, what
would version 2 look like? Not version 2 of the API, version 2 of the product or the feature. So usually when we're designing an API we have some product or feature in mind and we're mapping from
that back to the API that we want in order to enable that. So think about what would the next version of that thing look like? Will this API support that, you know, magical world that you've dreamed up? If not, maybe your API
isn't quite right yet. Spend that time to think how will our product evolve in the future? Another important lesson that we learned when we first rolling out
GraphQL in the beginning was to stop thinking
in terms of endpoints. And this is actually harder
than I thought it was gonna be. You know most traditional APIs, they start with some
new product experience and then they work backwards to design the API endpoint for
that product experience. But of course GraphQL exposes all the data from a single endpoint so this habit can be pretty hard to break if you try to just like shove
it into your schema this way. And this is especially hard for things that we don't typically think
of as like objects in a graph. One example that comes up often is search. So with search it's immediately obvious that you eventually want to
get to objects in a graph but it's maybe less clear
how you would get there. So if you're thinking
in terms of endpoints, you might start with
creating one-off objects that are really defined only
as their purpose as an endpoint as opposed to describing the semantics of the data that you're modeling. And if you instead frame that problem in terms of objects taken in a graph, and you separate the data
away from the feature that you're building you
can do a lot of cool stuff. So for search this might lead
to a search type in the graph that you can get from a particular
query string as an input and once you have that object in the graph you're back to the same
kind of data semantics of relationships between objects. You can go from your search
object to result objects, and now that search is just
another object in the graph you can start to imagine new use cases and how you might connect
that object to other objects. So here is just one suggestion. A search might point to
other searches to tell you suggested searches based on
the one that you just did. That's how typeheads work. And this has the
extremely powerful outcome of creating a single, cohesive graph that allows API users to
create subsets of your API of the API graph in ways that
you might not have imagined when you designed it in the first place in order to enable new
kinds of product experiences that you never thought of when
you were building that API. Related to that when we're modeling data we want to model as objects in the graph, it's important to stay away
from trying to model them as the view that we're going to support and instead stay focused
on that semantic data. So here's another question. Will this work for future clients? Usually when we're building
an API with an initial client in mind, like an iOS app, we think about "Is it gonna work on a desktop app? A feature phone app? Maybe an app for a TV." That all might have different demands but still access the
same data under the hood. We want to make sure that
we're not tying our APIs too closely to the demands
of our initial client. And at Facebook this
actually was really important because we were really careful when we were designing that newsfeed API to stay as semantically pure as possible and that enabled later, pretty wild experimentation
with the newsfeed interface in apps like Facebook
Paper or Facebook Home. And let's look at this as an example. So say we wanted to
suggest some gift cards when it's our friend's birthday. It might be tempting
to look at this mockup and then come up with this query. Right, we've got a product
that we want to know about. And then we have some attachment
data, all on our story. But of course we want to
model the underlying data, not just the view so maybe we actually want something more
like this on the right, where instebawigit is a
pointer to that product and we can start to ask
a little bit of questions about that thing on its own
and then here's some piece of information that's really
not about the product. It's about a representation of it. We can include that as well,
but we can give it something with a more semantically
reasonable name than just subtitle. Doing this is cool because as we play with this and as our designers come up with more interesting ideas for
how we might represent this, it's really easy to
later change this query to represent the slightly
different version of what we want without having to go back
to the server and say, "Oh, actually instead of attachment image can we have this attachment big image?" Instead of attachment title, can we have attachment short title cause we're running out of space? Don't do that. Just model the data. Shortly after releasing
GraphQL a lot of the questions that I heard and a lot of the
topics that we've heard today were like how do you do blank in GraphQL? Right, authentication, authorization, cashing, database query, optimization. And for us at Facebook the answer is almost always you don't. You don't do that in GraphQL. You know GraphQL's designed
to be this thin interface that sits atop all of
your existing systems and systems yet to be built. And this is one of the first
lessons that we learned when we were building GraphQL at Facebook. And it doesn't mean that
you can't have those things it just means that the
GraphQL service layer is probably not the right place for them. And by handling authorization,
database access, and all of these other
concerns below GraphQL the engine itself can then
end up being pretty resilient to swapping those
implementations out in the future as you end up migrating
between different services and your platform evolves. So Dan Schafer, one of our co-creators, did a really awesome talk about this, this year at React Europe. So I really highly recommend that talk. And then Robert Zoo, who's
also one on our GraphQL team wrote an excellent guide
that goes into this in depth on the GraphQL.org site,
called "Thinking in Graphs." So while GraphQL should be thin, it should also be a seam
between the semantic meaning of your data and then how that data's actually stored and retrieved. And that means hiding some of
those impelentation details. And, you know, some implementation
detail ends up exposed that might change in the future. Some client inevitably
is gonna rely on it. We have one example where in
order to figure out how photo you had this ID for the photo that was the ID for the album it was in and then a colon and then
the ID for the photo. And some enterprising engineer figured out that you could just split by colon and get the ID for the album
and they were off to the races, which was great until we
changed the infrastructure for how you got to albums and photos and then all that code
broke and we're like, "Wait, what? How did that break?" Right, we were leaking
an implementation detail. So ask yourself what happens when our implementation changes? That might mean moving
from sequel to mongo. It might mean deploying microservices away from your monolith. It might mean lots of different things, but it probably means that the way that your data is stored and accessed is gonna change in the
future as your stuff evolves. And so think does the API
that I'm representing now continue to make sense when that happens? And what kind of encoding details am I letting bleed through
when this is happening? And if we do this right, it lets us do lots of really awesome stuff. We can prototype fast,
scale easily, and then deploy new services without
ever interrupting our clients. And at Facebook we've done this. You know, in the last
four years we've shipped lots of infrastructure,
new services, new stuff that ranks newsfeed,
machine learning services, all kinds of really sophisticated stuff and our four-year old
iOS and Android clients still continue to work with
the exact same semantic API. So these are the questions that came up as we were talking through
these best practices. These are some of the most
important best practice that have helped us
maintain the same schema over four years at
Facebook, while continuing to build and ship new products, features, and infrastructure, most
importantly, all the time. We derived these questions
by asking ourselves how to evolve APIs, but now I want to take a
little bit of a step back and talk about some of
the lessons learned, not just from using GraphQL
but from actually building it. So I think if we look
back we can extract some of these principles into
something of a design philosophy that helped guide both the
initial development of GraphQL and the recent redesign. These principles guided GraphQL but I think they're
really just as applicable to building any kind of tool, language, anything like that. So if you in the audience are
working on something like this hopefully this is relevant
to you beyond just GraphQL. And let's start with, what's
hopefully the most obvious. When designing anything,
a language or a library, it's critical to start with solving a single important problem. For GraphQL that was getting all the data that we needed for our
Facebook's newsfeed over iOS over increasingly terrible
mobile network connections. This basically all but completely
ruled out REST right away without devolving into, you know, like the typical collection of
random custom JSON endpoints with a bunch of resources jammed together in a way that clearly wasn't REST at all and we just didn't want to do that. We actually tried that and we abandoned it pretty quickly
for obvious reasons. Also don't just solves any problem. Solve the most important
problem that you can find. In 2012, it was a little
bit of a while ago, and I'm not sure if you remember this but our mobile apps were
truly terrible at that time. In fact, when Zuck filed our IPO that year he specifically called
out the investor risk that mobile was driving
an increasing amount of our daily users and we hadn't figured out how to be good at it yet. So this was not a theoretical
problem by any means. This was an existential
threat to the company. Failure to adjust to
major shifts like this has crippled or killed other
huge companies in the past. So starting with an important
problem grounds you. It keeps you honest about what
you're trying to accomplish and it helps you drive the
early prioritization features. You know the most novel
aspects of GraphQL, giving clients control of data
with higher, quicker queries that can be resolved in one
roundtrip to the server. These were all established within that very first initial prototype in response to the problem at hand. So remember to stay focused on what the most important
problem is that you're solving, and use that to crystallize
what it is that you're building. And we've heard a lot today
about GraphQL first development and I think that's actually
really good advice, but what's driven us so far
has been being client first and using client first development. You know mental models are so important to how we think as programmers. Everything we make is ethereal. It's in our heads. But there's lots of
different kinds of systems and different kinds of
programmers and mental models and they don't always
match up with each other. So an important part of
us designing GraphQL was being kind of unabashedly driven
by the needs of the client, the consumer of the language. And hopefully it doesn't
come as a surprise that you know, not
every great iOS engineer is also a top notch network engineer and a database engineer
and web API designer. Our iOS engineers, they just wanted to think in terms of model objects and the JSON data that they needed to make those model objects work so we designed GraphQL to mirror JSON. And those who take a
trivial look at GraphQL they often accuse us of
being database nerds, where everything looks like a nail for a database language hammer. Right, and they foresee doom and gloom. But in practice it's totally the opposite. We are product people. And we designed the API that we wanted to use to build products. So if you're building a new
kind of language or a library, especially one that connects different kinds of systems and programmers together, try to escape the mental
models of what it does and instead put yourself
in the shoes of the person who's gonna be using it
and try to figure out what it is that they're
trying to accomplish. For GraphQL, that was realizing that it was way more important to
declare the data that you needed instead of how you got that data, which led us to the declarative
query in the first place. Reestablish, rethink
established best practices. This tweet is one of my favorites. It was posted in response
to us announcing React at JS Con in 2013. at JS Con in 2013. And this was relevant to GraphQL as well. Probably the most common question I got, especially right after announcing GraphQL is why we didn't just
use REST, SOAP, OData, JSONSchema, JSONAPI, RAML,
Swagger, RDF, OWL, or CORBA. You know, we're one of the other major established technologies
for building APIs. And you know just because
there's a best practice or even just some other
tool that's out there doesn't necessarily mean
that it's the right solution to your particular set of problems. And none of these were right for ours. So I think it's important
to respect and to honor, and most importantly, to
learn from best practices. But not to be held hostage by them. I love this interview with Elon Musk, where he talks about reasoning
from first principles, where he talks about not
just evaluating technologies and ideas as they're described but instead boil things
down to their fundamentals and then work them back up
with the good feedback loop. And speaking of having
a good feedback loop, it's so important to have
a real first consumer of your library or tool or language. Whenever you're designing something new, it's really easy to find yourself considering all the
possible future use cases and possibilities and then wanting to design for all of them up front. But it's basically impossible to predict the details of all of those and the devil's in the details, right? Otherwise what you end up doing is basically guessing, you know? And even the smart of us, smartest of us, sometimes guess wrong. And regardless of whether
you're right or wrong, those decisions stick around and they can lead to poor trade-offs or unnecessary complexity. GraphQL's first client
was newsfeed for iOS. We embedded ourselves on that team and we let their needs and priorities drive how we were designing GraphQL. So when we had ideas for
adding some feature to GraphQL having this first client helped us ensure that we were actually solving
a real problem that they had, rather than just our assumption of what the problem would be. But out of all the lessons learned I think this one is
actually the most important and it's come up a couple times today, which is to provide an
incremental adoption strategy. Our iOS team wasn't just
gonna like start over and rebuild their entire data layer just because we'd made GraphQL. So instead what we did is
we made it easy for them to replace one REST
endpoint, one resource, one data model at a time, and roll things out iteratively
so they could make progress. And having this path for
incremental adoption, I think it's critical for
the proliferation of ideas because it lets you try out a new idea in the context of an existing application where things are already working and you're already measuring
stuff like is it fast? Do people like it? How many times are they clicking
this button or whatever. So you can evaluate the
strengths and the weaknesses of this new piece of technology
before making a decision to just go whole hog and
build with it everywhere. And I think the single
worst strategic mistake that a software company can make is to rewrite everything from scratch, which is what happens when you don't have an incremental path. If your library or framework requires rewriting your entire app to adopt, then it's adoption itself will be slow. Joel Spolsky wrote a blog
post about this 16 years ago, which is nuts like this
blog post could drive a car. And if you haven't read it yet, it's not too late, it's 16 years old, but it's still highly relevant. Go check this one out. Alright, and speaking of adding features your first response to
every new feature request should be YAGNI. Do you guys know what YAGNI means? Yeah, yeah if you do you're
gonna say it with me, alright? Ya ain't gonna need it. That's right, okay. I heard from some in the front but now I gotta hear from everyone. And I see people up top
too who are all gonna say, "What do we say to adding new features?" - [Everyone] Ya ain't gonna need it. - Yeah, okay good. This is one of my favorite lessons. And it was probably the hardest
for me to learn personally. You know we want to
avoid implementing things that we foresee we'll
need, in favor of things that we actually need to
solve a real problem today. The burden of proof should
lie on the new feature for proving that yes,
truly we are gonna need it. So ask yourself, can we solve
this problem some other way with tools and features we already have? And if we can but it's awkward, like just how awkward is it really? Like can we go without the new thing. Because when we add the new thing what we're doing is adding cognitive cost. It's not just how hard it
is to implement, you know, implementing stuff is the easy part. It's more to learn and it's more to teach and it's more stuff for
future features to bump into. You know have you ever tried to like add a feature to
something and you go like, "Ugh, never mind we can't do it cause it conflicts with this other thing that we added poorly in
bad taste a year ago." Yeah, that's what happens
when we do these things. YAGNI, YAGNI, YAGNI. So during the redesign process of GraphQL, I was actually talked out
of a huge number proposals with this argument alone, YAGNI. And speaking of the redesign effort, it's really important to avoid
the second system syndrome. This idea comes from the
book the Mythical Man Month by Fred Brooks, which is one of my faves. It claims that the first
time you build a new thing you know you're a beginner so you're gonna be naturally conservative. But the second time around,
you've got experience. You know what you're doing. You've got success under your belt. So you're gonna pull out all of the stops and do all the things you were too afraid to do in the first time. And you're gonna end up
totally overdesigning it. And as the primary designer
of the GraphQL language this was definitely something
that I suffered from. So YAGNI can help but I think the best way to combat this is to have an editor. So as a designer I have
a propensity for ideas. I love to create new things and I tackled this redesign effort with a ton of creative exploration
and I was pretty gun ho about every idea that I come up with. I was like I'm sure all
these ideas are great. But if I was a designer than
my teammate Nick Schrock should be considered the editor. His role was essentially
to play devil's advocate, you know, to be an all
around pain in the ass and argue against every idea that I had. But you know in doing so, he helped identify the
proposals that meant well, but just weren't worth it. But once I was able to convince him that a change was worth
it, he did a complete 180 and became the biggest advocate for it. This process also helped us clarify how we talked about GraphQL and the changes that we
were gonna make to it, which helped us pitch them
to the rest of the company and then later the whole
developer community. And ultimately my editor Nick, he ended up being the best
person to persuade others of what we were doing because
he himself had been persuaded. So if you consider yourself
the designer or the architect for a language or a library or a tool or any piece of software,
you should make sure that you have a collaborator
who is taking on this role of an editor because I think
it's really, really hard to keep both of these
competing mentalities in one person's head. And GraphQL changed a lot
in those first few months. And we were able to do that
because we sat right next to the people we were impacting. But later as GraphQL was used
across the whole company, it became significantly harder to change. We had to coordinate a lot more pieces. You know change is still
possible even in a big company, but as we prepare to open source GraphQL we realized it was gonna be way harder to make significant changes
after a lot of companies, all of you had already
started to rely on it. So while you're interested in redesigning GraphQL for a while, and I knew it was gonna be a lot of work, it was really this drive to open source that sparked the motivation
to actually make it happen. I think most of us open source
our projects way too early. And I hope that's not too
bold of a statement to make. You know I love and deeply
believe in open source, but really it's the complete opposite of having a first client. If you're idea really is great, then you can quickly get tons of clients and that's not necessarily
what you want for a young idea. Not only can it make it more
difficult to prioritize, but it also removes a lot of the freedom to evolve and move quickly
that's especially important during the early development of ideas. And you know GraphQL couldn't have, could maybe have not worked. It was lucky and beneficial that it did, but it was a huge risk to
build something totally new, especially during a period
of existential crisis about mobile apps at Facebook. And in my experience, solving
a really important problem is typically when most
engineering managers and teams would encourage sticking to what works and avoid taking what might
seem to be unnecessary risks. And when Nick shared his first prototype, he definitely got a fair amount of push-back exactly like that, but ultimately we were
allowed to prove the idea mostly because of early enthusiasm from our first client, that iOS team. So some of the projects that
I'm most proud of at Facebook started this way, including
both GraphQL and React and what I've taken away from it is not just to take
risks, but in particular to trust experienced engineers like Nick to decide when the risk is worth taking and let them hold accountability
for those choices. So if you run a team, try
to push decision making and accountability to
your strongest engineers, especially if they think the time is right for something new. So from Nick's SuperGraph
prototype in 2012 to powering mobile newsfeed at Facebook to open sourcing it last year, you know, to all of you using it, GitHub launching a public
API in this conference, GraphQL's already been
through quite a lot. But it definitely feels like we're still in the beginning for GraphQl, you know, the community's still
growing really fast and as it does we're seeing a lot
of more use cases for GraphQL and a lot of new and interesting ideas. Opportunities for GraphQL
to evolve further. But now that more people
and projects and companies are relying on GraphQL, how
exactly should it evolve? What is that we should be striving for? And how should we evaluate
changes to GraphQL? I've actually been thinking
a lot about this lately. First, I think it's important to stay true to the original purpose of GraphQL, to provide a complete description of all the data that we need, all the data available on a service, and to let clients declare exactly what they need in single roundtrips. But there's some priorities that we want to maintain as well. And the first is backwards compatibility. So a huge reason why GraphQL
is so useful for us at Facebook and I imagine many of you as well is because we're able to fulfill queries from iOS and Android apps
that we launched years ago. Despite changes both to our
schema and to GraphQL itself. That means that we need
to be really careful that the future changes
to GraphQL are introduced without breaking existing
uses whenever possible. And then there's
simplicity and performance. I'm sure many of you
have heard this adage: performance is a feature. And whenever we're evaluating new editions we want to make sure that
we're taking into account the performance of having those features implemented in real GraphQL servers. But more importantly for
GraphQL simplicity is a feature. New proposals that simplify
are gonna be way more valuable then proposals that complicate. And then finally there's
stability and predictability so GraphQL's already evolved quite a lot over the last couple of years,
but it's gonna be harder to do that now that it's
implemented in a dozen languages and used by tons of different companies. It's important that we can
continue to build an ecosystem of tools and services that are stable and behave predictably. So with these in mind
I've come up with a rubric or sort of a set of questions that we can ask for any proposed change. Are we solving a real problem? Does this enable new use cases? How common are those use cases? Can we enable those use cases without having to change GraphQL? And if so, just how awkward is it? Remember, YAGNI. These also encourage collecting some data around showing just how
common some usage patterns are and it'll help us understand the value that any change would have. But also because GraphQL's
being implemented by many different people for
lots of different environments, it's really important that
the evolution of GraphQL happens in a transparent way. And because people are
using GraphQL in new ways beyond how we've just used it at Facebook it's also really important
that anyone can contribute. So we're really close to this since all development happens on GitHub but I want to propose a slightly more formal process for this. And that's to center
around RFCs and champions. So RFCs, RFC stands for
requests for comments. And what it is is a document that starts a conversation
about a proposed change. It tracks prototype implementations and ultimately proposes the spec text to be added to the GraphQL spec. And these are RFCs are
all gonna live on GraphQL in the open so that as
a poll requests probably so that everybody can easily find those and read them if they're interested. And behind each of these
RFCs will be a champion. So a champion is someone who's willing to put in the work required
behind developing an idea, writing that RFC, creating some fork of a popular GraphQL server
library to implement it, to see how it works, satisfying any concerns
raised in the process all the work involved and
generally owning that RFC all the way from introduction
to landing in the spec. And in addition to writing these RFCs I think we should also keep
a regularly development cycle and release schedule. This process is gonna be kind
of intentionally slowly paced but that's to make sure things
stay stable and reliable. So first what we'll do is every month we're gonna have a Google Hangout meeting, where we can go through
all of the open RFCs with the champions and with
GraphQL server implementors to talk through concerns
and to make progress so stay tuned for the scheduling
of the first of those. Then every six months we're
gonna release a new version of the GraphQL spec that will include whatever changes are ready. So when the six month time comes, the train leaves the station. That gives GraphQL implementors
a predictable calendar of updates rather than having to just kind of chase the current
state of the GraphQL spec. We've actually largely
kept to that already. After initially launching
the spec last July, we caught a version of
October of last year and then again in April of this year, and that means that the October version of the GraphQL spec is next, which will be arriving later this week. So I'm excited that we're
making the evolution of the spec more of a community effort to include more folks in this room and beyond, but you may be thinking I
don't know if I have an idea on how to make the spec better. How else can I help? Great question! Developing the spec is not what I hope most of us are working on and focused on. It's really not where
we need most of the work in the GraphQL ecosystem right now. Instead let me look
back on that master plan that I scribbled a long time ago. Well we're way further ahead than I expected on most of these. Where we definitely still need focus is in building and improving
the tools for using GraphQL in lots of different environments. Whether that's building
bessen class ID integration, performance analysis tools
for graphical services, or better GraphQL
clients on every platform there's tons of
opportunities for improvement across all of the tools that we're using. And I really think that great tools are what will make GraphQL ubiquitous. And that's where we need all of your help. So once again let me just say how proud I am to get to
close out this conference. Totally crazy that four years ago we started working on this project that today have all of you working on it. You know, when we open
sourced GraphQL last year I really had no idea
what would happen next and it's totally exceeded my expectations to see so many high-quality
presentations today from tons of different companies that are all using
GraphQL in different ways. And what's really exciting
is to see the community grow to the point where we can
like barely fit in this room and we're not all even here, right? Like all the people who showed up and we still can barely fit. So please let me say
thank you one last time for helping to make
GraphQL what it is today and just how excited I am for what we can all be building together. Truly, thank you all. (audience applauds)
