AMA with Lee Byron

Ask Me Anything

Lee Byron

Held on

Message from Lee ByronAMA Host

Thanks for having me here!

How does Facebook use server side rendering? How many projects are using that? I tried it but my workmate thought it was too slow compared to normal template engines. What do you think?

First of all, yes. Facebook uses server-side rendering heavily. Probably about 90% of was first rendered on the server. Much of Facebook is actually pretty static in your browser, only dynamic portions like comments and chat use React.

However, there are very few places where we're using React to render on the server, and this is mostly a decision based on our server environment (Hack) and the history of how Facebook was built. React itself was partly inspired by XHP ( which Marcel Laverdet built at Facebook in 2009 to componentize our UI.

XHP let us write small modular UI components with render functions and introduced a new XML-like syntax to PHP (hence the name). If this sounds similar to JSX and React, there should be no surprise. We already knew React's component model was a good idea from years of using XHP to do server-side rendering.

In terms of performance, it's true that constructing components has a modest overhead to simply concat-ing strings together, however this hasn't been a burden. Also, we've found that this is more than made up with our ability to leverage the better abstraction in numerous ways: better component libraries, easier maintenance, and even parallelizing data fetching with UI rendering (

What do you think about CSS Modules?

It seems to be that css modules are perfect for styling of react components. What is your opinion?

Thanks. Michael.

I actually haven't used the latest proposed versions of CSS Modules directly myself, but we use something really similar to it at Facebook. Tim Yung built Facebook's version of CSS Modules in 2012 to be used alongside XHP, and later with React.

One thing that we did differently at Facebook, is we disallowed importing CSS rules into any file other than the XHP/React component. That helped enforce that a component should expose the right API via it's props to be styled correctly and that other components couldn't import a rule in order to override it. That also meant that we never needed to add anything magical to JavaScript to "import" a CSS file, instead relied on a naming convention where Button.js would sit next to Button.css

The last benefit of modular CSS that we really liked was the ability to minify the class names themselves. When looking at the DOM in our development environment we see full class names like ".Button_ColorBlue" but in development we just see ".a5u". That helps on file size, and ensures no one can "guess" what the actual class names in the browser will be.

I'm really excited about GraphQL, particularly its type system and introspection capabilities.

  • What do you see happening to GraphQL in the short/mid future? Any plans to extend the spec with new major features or is it mostly going to remain as it currently is?

  • What tools, other than GraphiQL, you imagine can be built on top of it? Is there anything Facebook uses internally? Are there any new tools being developed?

Me too! :)

The last year or so of the GraphQL spec has been about honing what we have, and making sure how GraphQL works is clear and that it can be implemented in many environments. In many ways, GraphQL works and should be considered nearly stable, but there are also a lot of opportunities for GraphQL in the mid-term future.

One of the things I'm most excited about is extending GraphQL from the single-request-single-result model to single-request-multiple-results. For example, to enable some information in a request to be delivered before the server starts preparing other information, or even to keep an open connection to subscribe to live-updating fields. Right now GraphQL doesn't have a great story for reactive applications, but we're already seeing that start to change. I think a lot of future focus will be around this kind of exploration.

As for tools, most of what we do at Facebook and what we hope to see in the community is leveraging introspection to automate the things you would usually do manually. GraphiQL was a pretty obvious one for us in the early days, and we're excited that we could release it. Automating documentation and illustrating what a good IDE should look like was important to us. We're now seeing some of the GraphiQL features being integrated into existing IDEs where you're actually writing your code. At Facebook, we rely a lot on automated code generation (e.g. Especially in our iOS and Android codebases, we have tools which generate parsers, models, caches and other data layer code based on our GraphQL queries. That helps us protect against under-fetching and maintain type safety on those platforms.

Thanks for your time Lee.

With each major release in React, do you guys work on upgrading the components used in Facebook? If yes, how do you manage to do that considering such a huge codebase?

We do! In fact, we're not only updating to the latest version when it is released, we're usually using the master branch of React in production at Facebook.

Keeping this constraint means that no single change to React can break existing components. The team is usually really good about doing research in our codebase first to understand what might break given a change (we also have a lot of unit tests), and that's usually the origin of warning messages that are introduced in some versions of React. Breaking changes in React usually take two major revisions where they take only one in most libraries. First to introduce the warning, then to introduce the breaking change.

It also helps that most of the development in React is simplifying, and there haven't been many serious changes to its API since it was open sourced in 2012, so even with a really large codebase, there haven't been many opportunities where the team has needed to upgrade things.

For the few times when breaking changes are introduced, a member of the React team (often Ben Alpert) will take responsibility for making any relevant changes across our whole codebase. We're often using automated tools to help make this easier, like jscodeshift (

What's your take on Falcor (from Netflix) and how it compares to GraphQL/Relay?

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.

  • What should engineers do in order to avoid burnout?
  • What are your productivity hacks? What tools do you use to manage your time and works?

These are excellent and important questions!

What should engineers do in order to avoid burnout?

Burnout is real, and dangerous. I've suffered from serious burnout a couple times in my career so far, and I've worked with others who have as well. First, I don't think it's anything to be ashamed of. I was ashamed when I was first burnt out, especially since everyone around me seemed like they had so much more energy than I did. The most important thing I did was talk to someone about it. I talked to my coworkers and my manager, and they helped me through it.

I find, especially in engineering, when you feel burned out, there's a tendency to want to quit. Quit what you're doing, quit the company, but that's not always the right answer. Instead what you often need is a change of attention. Here are my suggestions:

REST, seriously. Get a full night sleep. Actually take weekends. Not just when you're feeling burned out, but all the time. Also take regular vacations to the degree that you're allowed. Actually disconnect from work on the vacations.

It's okay to have busy weeks, or the occasional all nighter, especially right before launching new things. That can be exciting! But take care of your body and mind.

Variation. If you're working on the same problems for 5 years, you're going to get bored. Software engineering is a huge huge space though, there's no excuses for boredom. At a minimum, take some time to learn new things and experiment with new technologies.

At Facebook, we have a program called "Hack-a-month" where you loan yourself to an unrelated engineering team for one month to take on a small project. A couple things happen that are important: a) you get a change of scenery and get to work on a new kind of project, b) you learn about new people and teams in the company c) your team has to figure out how to survive without you for a month. Some hack-a-monthers decide to stay on the new team, but many go back to their old teams, but find that since the team had to work without them for a month, many of the things they found boring aren't their job anymore and there's space for new work.

Will Facebook re-code its current app by using React Native?

Already done!

More specifically, there are portions of the main Facebook app which is built in React Native, and other portions which are not (bet you can't tell), and that's likely how things will continue for the foreseeable future.

React Native can be used in an incremental way, and we definitely take advantage of that. We're building a lot of new things in React Native, and we're converting some things where it makes sense, however we never convert things simply for the sake of having done so. There's a lot of good reasons to leave some of our highly performing products as they are for now.

  • I want to know what is the best flux implementation that we should adopt : Redux / Reflux / Flummox / Alt etc

  • What libs do you recommend for writing tests : enzyme / sinon / chai / jest?

  • Do you think the Apollo project by Meteor is something that we should consider using?

I want to know what is the best flux implementation that we should adopt : Redux / Reflux / Flummox / Alt etc

I'm sorry to say that there is no best because "best" is relative to what you need. All of these libraries are better at some things at the expense of others. In fact depending on what you're trying to build, it could be the case that none of these are best.

Redux has gotten a lot of attention lately for being very simple (only a couple hundred lines of code) and very flexible, so that might be an interesting place to start.

What libs do you recommend for writing tests : enzyme / sinon / chai / jest?

What's important is that you're writing tests, period! I typically use mocha or jest as my test runner, and then use whatever tools I need to write useful tests, which often includes chai, sometimes sinon and occasionally enzyme.

Shameless plug also for testcheck ( which enables generative property testing. Something I so rarely see in the JavaScript community, despite how useful it is. Many of the tests for Immutable.js use testcheck.

Do you think the Apollo project by Meteor is something that we should consider using?

It's super early days for the Apollo project. I think it's a really exciting project, but just keep in mind that its young. I think if the kinds of problems that Apollo solves is relevant to the problems your application has, then you should consider it.

What do you think of the Apollo stack by Meteor which uses GraphQL?

It's really exciting stuff! One of the areas we've been researching is how to add Reactivity and live data to GraphQL and the Meteor team has been running ahead with building this kind of thing. I'm really excited about where things can go and what we can build from here.

How do you balance working on product / internal product infrastructure / open source stuff while at Facebook?

FB's open source work has raised their profile a lot in the OSS community, but it still sometimes feels like projects are often being worked on in people's spare time rather than on "work time".

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.

Server Side Rendering : Do you think it's a good idea to separate API server from the server that renders React components?

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.

Hey Lee,

Last year you shared a roadmap with us:

Is it still current? I'm curious about the topics 'performance' and 'serialization'. v4.0 hasn't received some love on Github for a long time now.

My issue is that I can't throw immutable.js into any code without receiving performance penalties. I'm trying to convince some of our dev teams to use immutable data structures.

For React.js projects it's easy, just use life cycle methods and React will perform faster. But what if we want to use immutable.js in pu​re Node.js projects? Our devs are arguing about performance penalties now. Creating and destroying data structures in looping scenarios doesn't perform that well compared to POJS data structures.

And serialization in server-side-rendering projects. What's the status here? Will you serialize some code logic wich ensures immutability on de-serialization or what can we expect in the future?

This roadmap is still current, though progress has been incremental. A lot of the work so far this year has just been modernizing the Immutable.js codebase, though some incremental work on performance is already happening. We haven't yet cut to a new branch, which is why you're not seeing much specifically on the v4.0 branch.

The performance penalties you see can range a lot depending on how you use it. In a lot of the places I've seen Immutable data structures used with high performance, there's a good understanding of what operations are slow and fast.

For example, operating over an Immutable structure in a loop is slightly slower than using it's mutable brethren, about 15% slower by my measurements because of crawling a tree rather than a list.

Creating and destroying data structures also depends a lot on what operations you're doing. David Nolen, in one of his presentations illustrated how building an Immutable list by pushing in numbers 1 to 1,000,000 could actually end up being faster than doing the same work with a plain array. Why? Because of course under the hood, an array is also creating and destroying memory buffer space, and the shape of the memory used by the Immutable data structures allowed for more reuse and ended up being slightly faster. Crazy!

However there are some operations that aren't O(1) in Immutable, or are naturally significantly slower. Anything that results in re-indexing an Immutable list, for example, is O(N). Or the worse of them, toJS() which performs a recursive deep copy of the entire data structure. If you want to do a performance audit, just look through your codebase for toJS(), and try to remove them.

My issue is that I can't throw immutable.js into any code without receiving performance penalties. I'm trying to convince some of our dev teams to use immutable data structures.

At the end of the day, Immutable data structures are not designed to be faster than their mutable brethren in isolation. There will always be a performance overhead to using them, even after we make it through more of our 2016 roadmap of perf improvements. Instead, immutability enables new kinds of techniques for whole-program optimization, like memoization, that simply can't be done with mutable data.

Unfortunately you can't just throw these things into any code and expect speed gains, but instead need to design for the opportunities it presents, as React already has.

And serialization in server-side-rendering projects. What's the status here?

The idea is if you're using Immutable.js on the server and the client, or you want to stash it away in localstorage or something like that, rather than converting to JSON and then reparsing, we should have different ways to represent this. There's been some experimentation here, and there are some great other projects which support this like Transit. David Nolen wrote a great post about this a while ago (

Hi Lee. Is GraphQL used for service to service communication at Facebook ? If not, why ?

GraphQL is not used for service to service communication at Facebook. It was originally built to layer over our application logic just before data is sent to mobile clients, and has been used that way ever since.

Most of our service to service communication happens using Thrift ( originally built by Mark Slee at Facebook.

There are some commonalities between GraphQL and Thrift, they both define a type schema and they're both handling RPC. However they then diverge. Thrift works well with a speedy service to service connection (usually within a datacenter), and expects tons of requests per second from a single client, while GraphQL is designed for crappy slow mobile connections, and maybe a few requests per minute per client. Thrift instead focuses on extreme efficiency at the network and memory levels, and is often used with services written in C++.

Does Facebook use Node.js in production with any aspect of their technologies? If not, any chance it would consider using it?

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 ( 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 (

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.

What does the future look like for React? What are some future plans and strategies that you have in mind?

Take a look at which documents a lot of the thinking around React's future.

One of the areas I'm really excited about is custom layout, however we need help from browsers to get better APIs for measuring text.

First there was Flux, from which evolved Redux. Now there is MobX which alters the approach to state management completely. What is your opinion of it?

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.

It seems like the ImmutableJS Record type is an underappreciated part of the library. I never see any examples or tutorials mention it but it seems indispensable for defining model classes to get the benefits of immutablejs collections and the ease of plain JS property accessors. Do you or others at FB use it extensively for that purpose? If not, why does it seem like I am the only one? Am I missing something?

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 ( uses them extensively.

What will you suggest a noob who only know basics of html, css and js to learn React.js and React Native?

Definitely understand what these tools are doing for you first. It's pretty difficult to use React (or Angular, or Ember, or Backbone, or...) without having a solid grasp on JavaScript. Taking on too much at once may make it challenging to understand how the pieces fit together.

That said, often the way I learn new things is by trying to build something simple first, then figuring out why it worked. If you're learning React, maybe build something simple but useful first? A simple todo app to help you stay organized? Or maybe something else that would be useful for you and not too hard to build the first version of.

Are there any plans about bringing 'reactive' GraphQL, if yes, when?

This is something we're experimenting with a lot now. Meteor's Apollo project is a great step into this space. I would expect to see more over the next year or so.

  • What are some particular trends that you are seeing in web development?
  • How was GraphQL spec born? Any inside scoops, interesting facts, anecdotes etc.. ? :D
  • What are some challenges that GraphQL is having right now?

What are some particular trends that you are seeing in web development?

In web development in particular, the most exciting trends around around handling dynamicism. Especially since the most common device connecting to the web is a phone, not a laptop, dynamic content on the web on crappy devices with crappier connections lends itself to a lot of new problems to be solved. We're not there yet.

How was GraphQL spec born? Any inside scoops, interesting facts, anecdotes etc.. ? :D

GraphQL itself was born in 2012 while rebuilding News Feed on iOS. News Feed was rapidly growing more complicated, and we didn't have the right foundational technology to help it grow, especially as Facebook was itself growing the most in places with bad network connections.

Last year we decided to write a spec for GraphQL in large part because Relay was excited to open source and Relay without GraphQL doesn't make a lot of sense. We also realized that our GraphQL service was written in Hack, which most people outside Facebook aren't using (unless you're Wikipedia or Wordpress) and so the best way to share GraphQL would be in a language agnostic way.

After we decided to do that, we also realized that 3+ years of development at Facebook had left GraphQL with a lot of patched on additions and inconsistencies, so we also took a solid pass at simplifying it.

What are some challenges that GraphQL is having right now?

Two of the things I'm most excited about are 1) supporting more reactive or live-data servers, and 2) supporting more client-side tools like code generation or compiler integrations. We've relied on a lot of these kinds of tools at Facebook for a long time, but sharing them in their current form would be difficult.

Thanks for your time. I'm setting up my first GraphQL endpoint to pair with Relay, and I'm really loving it. However, I am having a little trouble wrapping my head around mutations. Are you guys planning any updates to mutations in the near future? Also, do you know of any good tutorials or example code for learning more about mutations, specifically Relay-compatible mutations?

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

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.

TypeScript has caught up with a lot of issues, which originally prevented Facebook from utilizing it (file by file opt in, etc) ... It seems it is superior to Flow in so many ways.. why is Facebook still investing in Flow and not jumping on the TypeScript bandwagon?

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.

Hello Lee, I'm developing a GraphQL backend, but i got stuck with ACL implementation. So my question will be quite simple.

How do i implement ACL in GraphQL server?

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.

Howdy Lee. Thanks to you and your team for React, it's made designing modular, reusable code a lot easier for me.

My question is this: One limitation I'm running into is that in order for a user interaction (like a click) on one component (e.g. "Button") to affect the state of another component (e.g. "Lightbulb"),

Parent :-- Button :-- Lightbulb.

I've figured out two options:

1) Have a flux store with a property called "buttBulb" which "Button" dispatches an action to, and which Lightbulb reads from.

2) A) Create Parent.changeLightbulb((this.setState({lightbulb: !this.state.lightbulb}) B) Pass Parent.changeLightbulb to the Button, and Parent.state.lightbulb down to the Lightbulb as props.

I'm wondering if there are other clever ways that FB's React team has approached the "affect sibling's status" problem.

Very often you should be providing functions to children and performing this coordination at the layer above, and you don't necessarily need Flux to do this.

In this case I'd highly recommend for the "state" of the lightbulb being on or off is owned by "Parent". "Lightbulb" has a boolean prop called "isOn" that parent provides via that state, and "Button" has a function prop called "onClick" which is called when it's clicked.

<Lightbulb isOn={this.state.lightbulb} />
<Button onClick={this.toggleLightbulbFn} />

Is web workers wrapper on the roadmap of reactjs?

There have already been a lot of experiments in putting React in a web worker (one example, 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

How to implement GraphQL from a mobile react-native app?

Hi Lee,

You've pulled concepts from Clojure, Scala and Haskell (Haxl) to influence libraries such as immutable-js and dataloader. What are you learning/using today that you think could be useful if done in a similar "javascript-first" approach.

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.

What is your typical day look like?

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.

What are some practical use cases for using immutable.js at Facebook?

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 ( uses it, and commenting on anything in news feed, or writing a new post uses it in the Draft.js project (

What portions of Facebook use GraphQL and Relay? Do you recommend using Flux + Relay + GraphQL together?

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.

Hi, Thanks for React and React Native, here are my questions

  • 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?

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

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 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.

Hi Lee,

Can GraphQl be used without React ?

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 :)

What was the thinking behind the separation between GraphQL's input types and regular types?

Hi Lee, I've got a graphql/relay tutorial I specifically wrote after feeling frustrated by the lack of higher level conceptual stuff in the facebook docs, would love some feedback on what I've made.

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.

Please let us know how node v6 improves Reactjs

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.

React introduced the idea of high performance and a strong push to change the opinions fundamentally of how we should build UIs. Almost all the other libraries are now adopting some of React's concepts.

Where do you see the next big change in terms of how we think about and deal with UIs on the web?

Can you recommend some resources for learning about concepts fundamental to immutable? (trie data structures, for example)

What is the intended pattern for the GraphQL node type resolver/isTypeOf function?

I am currently tacking a type string property onto api responses. Adding another layer of, for example, record objects feels like schema duplication (or maybe good design).

Any thoughts?

loading ...