Image for post
Image for post

So far you’ve seen how:

  1. Relay lets you say what data you need with GraphQL in part 1
  2. Relay fetches data from the server in part 2
  3. Relay syncs changes back up to the server in part 3

Now let’s see how all the different parts work together.

Caveat: this is only an approximation

In the cartoons up until now the scale of the diagrams has been 1:1… each arrow has (pretty much) represented a single function call.

For these diagrams, the scale is closer to 1:100. This is because Relay is doing so much for you.

Flux is a pattern. Relay is a framework. Flux…


Image for post
Image for post

Relay is the same as Flux and Redux in a way. All three of them use objects to represent changes. When a change object comes through to the store, the store will make the change in the state. Then the store will notify the UI to update.

Unlike Flux and Redux, Relay pushes the change up to the server, too.

Sometimes changes aren’t simple, though. They can ripple out and have effects that aren’t so obvious.

For example, take adding new content. It could have impacts on other parts of the graph, too.


Image for post
Image for post

GraphQL gives you a way to say what part of a graph you need, as you saw in part 1.

Relay makes the connection between the graph in the cloud and the graph that the user is interacting with on the page.


Image for post
Image for post

The last two cartoons covered Flux and Redux. Those are data handling patterns to keep your UI in sync. When a user interaction happens, they update the state and trigger rerendering.

But where’s the cloud? How do you get the data that a component needs from a server, and then update the server when the user makes changes?

The Flux docs don’t tell you were to put this. Even at Facebook, different teams add it in different parts of the app. Redux gives you a single place to do it (middleware), but it still requires effort to wire it up.


Image for post
Image for post
Other languages: 한국어, Русский.

One thing that causes even more confusion than Flux is the difference between Flux and Redux, a pattern that was inspired by Flux. In this article I’ll explain the differences between the two.

If you haven’t read the last article about Flux, you should do that first.

Why change Flux?

Redux solves the same problems as Flux, plus some.

Just like Flux, it makes state changes in apps more predictable. If you want to change state, you have to fire off an action. There’s no way to change the state directly because the thing holding the state (the store) only has a getter…


Two of the features that get people excited about Redux are hot reloading and time travel debugging. But what are they?

Hot reloading

When you’re developing an app, you’re usually making one small change after another. The faster you can see the effects of the small changes (and recover from the small mistakes that you make), the faster you will develop.

The neat thing about hot reloading is that your app’s state isn’t reset after every change. Let’s say you’re testing a particular screen. You’ve added a few todo items and crossed a few off. But now you realize you need to…


Image for post
Image for post
Other languages: 日本語, 한국어, Русский.

Flux is both one of the most popular and one of the least understood topics in current web development. This guide is an attempt to explain it in a way everyone can understand.

The problem

First, I should explain the basic problem that Flux solves. Flux is a pattern for handling data in your application. Flux and React grew up together at Facebook. Many people use them together, though you can use them independently. They were developed to address a particular set of problems that Facebook was seeing.

Lin Clark

Stuffing my head with code, then turning it into @codecartoons

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store