Chapter 7. Reactive architectures

Fundamentals of reactive architectures

You’ve seen how it’s possible to make reactive chains to refine data from observables. But before you go further, let’s look at how reactive applications can be structured in a scalable way on a higher level.

Data change, process data, render

All modern reactive applications work roughly in the same way. You have some kind of storage for data, or a database, and you react to changes in it.

On the other hand, you have mechanisms for updating the database. These include incoming data from the network, user input, or something read from the disk.

Notice that in this picture, the database is the only place where the data is stored. The reactive chain is processing only the data that originates in the database. This may sound restrictive, but you’ll see later the benefits and compromises that you’ll end up with.

Model-View-View model

If you go back to the picture from the preceding page, you can see that your state is contained in the store.

What you have in the middle, then, is the reactive code. So far, you’ve just put that code inside a container, such as Activity, but now you’ll name it and see how to define it as a separate part of the architecture.

Reactive model

Retrieving data from the model

Coffee break

Revising the file browser

Constructing the model for the file browser

Using the model

Rules of the model and its consumers

Single source of truth

Coffee break

Persisting app state

BehaviorSubjects and stores

Simple SharedPreferencesStore