Why reinvent the wheel?

A few days ago at the React-Europe conference, I shared a project that I have spent more than three years on - GraphQL.

After the meeting, many participants asked me:

How does Facebook keep producing new technologies that "reflect current *** practices"?

Since this is the React conference, let's start with React.

Two years ago

When we open-sourced React two years ago, it was the butt of jokes in the JavaScript community; even people inside Facebook (including myself) didn't think it was a good idea. Jordan Walke's persistence and idealism eventually had an impact on everyone. At first we thought he was crazy, and he was a lunatic, but he did find something. Now, we see that React has changed the way we "build" things on various platforms. Adam Ernst borrowed some of Jordan's ideas and "built" ComponentKit for iOS. Of course, our own iOS team was also full of suspicion when they first came into contact with it; but once again, ComponentKit has greatly changed the way we "build" iOS programs.

React and ComponentKit were both projects initiated by individuals within Facebook. In fact, the direction of these projects was contrary to the original development methods of the engineering team at the time. React directly challenged some JS frameworks that we were very optimistic about at the time. In fact, when we first started developing ComponentKit, we had already "created" and used some iOS UI frameworks internally.

There's nothing wrong with the other tools, and they're not bad (they're actually pretty good, after all), but they're not the best either.

They each have their own pros and cons, and have their own advantages and disadvantages. Only in a free development environment can engineers "create" some tools that they think are more efficient to help them complete their work.

The adventurous culture of engineers

At Facebook, we not only allow, but encourage engineers to do these fun "experiments". In fact, these projects are still risky, not very sexy, and often fail (need to be fixed). Then you will find "experiments" like React, ComponentKit, HHVM, GraphQL, Immutable.js, Flow, Pop, and AsyncDisplayKit. These are all worth taking risks. For a company like Facebook with a strong engineering team, one of the advantages is that it can fully allow engineers to try these experiments, instead of focusing on scrum or working for the company's short-term performance.

Each of the projects mentioned above has faced strong opposition. Some people (sometimes even me) would like to admit failure early on. However, they don't stop. Facebook not only has a good engineering management philosophy, but also has a great management team - they know the importance of trusting engineers. Even if the project encounters opposition from colleagues, even if the value of the project is unknown, even if there are more important things to do, Facebook's management trusts their engineers to take risks that are worth taking and focus on areas where they believe they can have an impact.

My group, Product Infrastructure, has the same philosophy as most Facebook groups: engineers have an impact on the world beyond the company's products. The open source projects mentioned above have strong communities, and each has a profound impact on the entire Internet/software industry. Open source is not just a public welfare ideal, it is also an important part of how we learn and show the impact inspired by our work.

A healthy open source environment is also very beneficial in the recruitment process. Some job seekers I have interviewed told me that they paid attention to Facebook because they saw projects such as React, AsyncDisplayKit, and Pop, and wanted to participate in these projects. These projects attracted very smart talents, which naturally created a virtuous circle.

Success is not found in isolation

As the project becomes more and more interesting, its potential is seen by more people, and a team is formed - then a snowball effect naturally promotes the entire project. At Facebook, it is not uncommon for engineers to work on projects outside of their job responsibilities; or to be transferred from one group to another; and this culture allows the snowball to roll. This also means that there are many unsung heroes behind each project.

I'd like to name a few (far from all) of the early contributors to GraphQL: Nick Schrock, Daniel Schafer, and myself.

Beau Hartshorne was an indispensable catalyst for GraphQL. He identified and pointed out the problem, found the right people, and inspired us to find solutions to the problem. Sometimes it's hard to see the forest through the trees, and Beau's a rare person who is always looking at the forest.

Jonathan Dann and David Renie were two of the iOS engineers who drove the first version of GraphQL. They did a lot of work integrating GraphQL into News Feed. They also helped build some very important infrastructure that we still use today.

Rasmus Andersson had a fresh vision for a different way to transfer data in mobile apps; this became the basis of our Android SDK. Some of his ideas also inspired Relay - a tool for building web apps with GraphQL.

Two other early members of the GraphQL team, Nathaniel Roman and Charles Ma, helped develop GraphQL client tooling.

Scott Wolchok single-handedly organized and improved the data model for GraphQL's iOS and other cross-platform client tools. His rigorous thinking inspired us to study the progress of cross-cutting.

Today, there is a mature team dedicated to supporting and investing in GraphQL, servers, client tooling, and Facebook's type system.

Our Mission

It is precisely because of our focus on continuously producing long-term value that Facebook has been able to "create" some technologies that "reflect current best practices" and have a significant impact in the industry. We dare to try and fail; we believe that engineers can do the right thing. When some "experiments" seem a little interesting, people full of ideas and smart people will spontaneously come together to realize this "experiment".

At Facebook, our responsibility is not just to build Facebook, but to make the world more open and connected. Our Product Infrastructure team helps us accomplish this mission by open sourcing these tools.