There have already been a lot of experiments in putting React in a web worker (one example http://web-perf.github.io/react-worker-dom/), and unfortunately those experiments have had mixed results. Some things get faster, others slower. Some overhead to development and deployment. Etc.

Web workers incur some cost in moving data in and out of them, which is part of what complicates things. You can read more in the section on Workers in https://github.com/reactjs/react-future

GraphQL itself does not perform access control for you, for the same reasons that GraphQL does not fetch your data for you - it leaves this up to you for maximum flexibility.

Most GraphQL servers have a concept of "context" which lets you provide an extra value to every field resolver during a query, and this is designed for exactly this case: the context is a perfect place to provide the "logged-in user" or "ACL roles" or whatever you like to call your authentication data.

Then in your field resolvers, you have access to this authentication data to decide if it's better to return null if the authed user shouldn't be able to access the value.

Falcor is also awesome. When the GraphQL team first heard about it, we met up with the team from Netflix and we swapped notes.

It was pretty exciting to us that Netflix saw very similar problems to be solved and even arrived at a similar looking solution, and that we had both been using our respective solutions in production for a few years. It was a sign to us both that we weren't crazy.

There are some important differences between the two though:

• Falcor returns Observables, GraphQL just values. For how Netflix wanted to use Falcor, this makes a lot of sense for them. They make multiple requests and present data as it's ready, but it also means that the client developer has to work with the Observables directly. GraphQL is a request/response model, and returns back JSON, which is trivially easy to then use. Relay adds back in some of the dynamicism that Falcor presents while maintaining only using plain values.

• Type system. GraphQL is defined in terms of a type system, and that's allowed us to built lots of interesting tools like GraphiQL, code generators, error detection, etc. Falcor is much more dynamic, which is valuable in its own right but limits the ability to do this kind of thing.

• Network usage. GraphQL was originally designed for operating Facebook's news feed on low end devices on even lower end networks, so it goes to great lengths to allow you to declare everything you need in a single network request in order to minimize latency. Falcor, on the other hand, often performs multiple round trips to collect additional data. This is really just a tradeoff between the simplicity of the system and the control of the network. For Netflix, they also deal with very low end devices (e.g. Roku stick) but the assumption is the network will be good enough to stream video.

It likely has no effect. Node bumping to v6 mostly reflects Node's libraries including breaking changes, but React does not use any Node library.

At least logically yes. It's important to maintainability for React components to avoid the kind of conditional logic where if (serverRender) it does something different or reaches into your API in a different way.

However they don't necessarily have to live in different services, or on different machines. That's up to how you're organizing your system architecture.

Awesome! I'm glad you're doing this. It's great that these kinds of tutorials come from folks outside the GraphQL and Relay teams since you have perspective that we do not.

Absolutely! In fact, GraphQL was originally designed to be used by iOS apps. It was quickly after used by our Android apps, and only a while later used by our React views as part of the Relay project.

Thank you for your time :)

ShibesBot

Relay is an implementation of the Flux concepts. Relay requires you to have a GraphQL service.

Our iOS and Android apps are almost entirely powered by GraphQL (but not Relay, as they're not JavaScript).

Parts of those apps, and in some cases whole apps (Ads Manager) are built with React Native and use Relay with GraphQL.

We use Immutable.js in a lot of our client code, especially along side React and using an architecture where there is a single immutable state at the top of the app. Our Ads Manager uses Immutable.js for its apps on the web, and in their react native based iOS and Android apps. Our Messenger web (messenger.com) uses it, and commenting on anything in news feed, or writing a new post uses it in the Draft.js project (https://facebook.github.io/draft-js/).

Every day is different, but most every day I'm writing code, reviewing code from my coworkers and open source community, and answering questions on github.

I'm not sure yet! I'm always looking for gems in areas of programming outside typical front end or app development where we can stumble upon relevant ideas.

I think video game engines are also a great source of inspiration.

Sometimes it's hard for "spare time" and "work time" to separate (see burnout above) since people are often just working on the things they're excited about all the time.

For me personally, since I work on our Product Infrastructure team, my main priority is building the right tools and libraries for Facebook's projects. I do far less direct product work, however I still do a little.

However, I used to work primarily on product, but still spent some of my time on product infrastructure. GraphQL was originally born while I was working with the Mobile team on redesigning News Feed. At that time I was spending part of my time designing News Feed, and part of my time designing GraphQL, and the two became fairly inseparable as getting GraphQL at high quality was critical for getting News Feed at high quality.

Open Source is a little different since a lot of the primary audience is outside of Facebook. I've found that the best way to prioritize it is to ensure that it aligns directly with Facebook's goals.

Only open source stuff that's important to your company. That ensures that continuing to work on the things that are important to your company benefits open source, and open source contributions are far more likely to benefit your company.

We do! A lot of our client-side tools are written in JavaScript, and run in Node, especially now that Node is a pretty ubiquitous tool for developers to have on their laptops.

For example, Remodel (https://github.com/facebook/remodel) is a tool for auto generation of model classes for iOS, and it's installed via npm.

Also, all of our internal GraphQL client side tools for iOS and Android at Facebook use Node and are built on top of graphql-js (github.com/graphql/graphql-js).

We're not using Node much on the server side of things, but mostly because there hasn't been a serious need. Between our services built in C++, and our application server in Hack, we're pretty well covered.

There have actually been a few cases where we've run JavaScript on the server, mostly to do some server-side rendering of React components, but for those we actually haven't used node and instead used v8 directly.

For the same reason that TypeScript is superior to Flow in many ways, Flow is superior to TypeScript in many ways. In practice, the two have just made different fundamental decisions that have resulted in tradeoffs.

A few examples:

Nullability. Flow started from day one with Nullability in mind, and that was also one of primary reasons the project was started in the first place. Typescript was not, but adding nullability support in after the fact is not an easy thing to do because it changes the meaning of existing code. While Typescript plans on adding strict nullability checking in v2.0 (some recent great PRs have landed), you'll still need to opt-in with a compiler flag and many existing libraries that export types will have to either update or just be unsafe to nulls.

Nominal vs Structural types. Type checking languages open a lot of questions, there are a lot of ways to do it. Typical object-oriented languages like Java or C# typically use Classes and Interfaces to implement Nominal types - that is the name of the class or interface determines if something adheres to a type or not. TypeScript chose this path, and therefore relies heavily on the use of Interfaces and Classes. Typically functional languages like Haskell or ML implement Structural types - that is the structure of the data within some value matches the type signature or not. Flow chose this approach because it matched up with how the team saw JavaScript being used, and helped to type things like returning plain Objects with fields.

New Language. TypeScript is actually a new language, it adds new kinds of things that JavaScript doesn't have like Enums, Interfaces and Class properties. It also explicitly excludes some stuff that you could do in JavaScript, but doesn't fit well in TypeScript. Of course, this is a cool thing! Flow decided to make a different decision and only type existing JavaScript. This has an interesting property where type-checking and compilation can be separated into different steps. In order to turn Flow code into JavaScript, you simply remove the type hints (or comment them out). This ended up being really important for Facebook's build tools (we have a LOT of JavaScript) but also the team felt confident that such an approach was interesting in its own right.

Also, at the end of the day, Flow has improved greatly from watching what TypeScript does and TypeScript has improved from watching what Flow does. The two teams often talk to each other to share ideas, and even if all of the above weren't true, I think some healthy competition in technical projects is a great driver of progress.

The Relay team is building debugging tools that make it more clear what's happening with a given mutation and config, and longer-term, making the API lower-level and more explicit.

There are resources at facebook.github.io/relay/docs/guides-mutations.ht…

Though we should definitely write even more about mutations, since this is often an area where questions arise.

I often try to explain GraphQL in terms of the functions that each field represents.

For regular queries, it's pretty straight forward. To get my name, imagine the name field maps pretty cleanly to a user.getName() method, makes sense. To get my user object, maybe user(id: 123) maps to app.getUser({ id: 123 }), also fairly straight forward.

For mutations, it's exactly the same concept, but the underlying functions have side effects. They first do something (anything) to your system and then return something related to the change it just made. So perhaps likeStory(id: 456) maps to app.likeStory({ id: 456 }) which first makes sure that we update the database to show that I've liked the story, and then returns the story itself, so we can ask new questions of it, like how many people like it now.

What clientside routing system do you use inside the components? It seems there isn't one compatible with React and ReactNative. How do reuse functionalities between the two?

I highly recommend https://github.com/reactjs/react-router for building things on the web, where things are URL based. ReactNative has it's own router that's designed to work very well with the OS native navigations.

We're often not reusing functionality between the two because they're so different, and each platform deserves to feel native. Instead we're reusing the React components themselves which make up the app and UI logic of various screens.

What do you think of the "React Native Web" approach and consider the Web a rn platform?

This is a really interesting idea for future exploration and a lot of people on the team are experimenting with it. One serious missing piece is how layout is performed, on the web we don't have APIs to measure how text will layout, where we do have those things on iOS and Android native views. Starting to fill in those blanks over time by working closely with browser vendors and standards committees will help us explore this.

I don't think you're missing anything. Records are great for all the reasons you claim here!

We do use Records quite a lot at Facebook. For example, the Draft text editor (https://facebook.github.io/draft-js/) uses them extensively.

I've never used MobX, so I honestly can't speak for it.

In general, I'm not surprised that we're seeing an explosion of tools and libraries for building immutable state based architecture in applications. Each tries a new idea that the previous hadn't, or reframes in a new way. Many of them will probably fade to time behind those that found the right abstractions, but the exploration process is a critical part of getting there.