In this article, we’ll build an Angular application which lists movies which arrive from a nested API response. We’ll learn how to store and update our data more efficiently using Akita.

This post assumes that you at least have some working knowledge of Akita. If not, please start with the basics.

Let’s say our server response is:

A movie could have many actors and also many genres. By examining this type of response, we can observe its disadvantages.

Duplicate objects (actors or genres) will increase memory consumption and make the server payload larger. Updates will be harder and can become very ugly very fast (due to the nature of nested spreads) . For example, if we want to update an actor’s name we’ll need to loop over each movie.actors , check if it exists and update. (the same goes for deletion).

Because of the above reasons, the recommended approach to managing relational or nested data in Akita is to treat your data as if it were in a database and keep that data in a normalized form.

Designing a Normalized State

In Akita, normalizing data means that each entity gets its own “table,” i.e., Akita EntityStore and any references to individual entities should be done by storing the entities’ ID.

An example of a normalized state structure for the movies example above might look like this:

This state structure is much flatter overall. This is an improvement upon the original nested format for several reasons:

We get rid of the duplicate objects, which means our memory consumption decreases and the server payload will be smaller. We have a single source of truth for each entity which makes updating or removing an entity easier. Retrieving an entity is just a matter of a simple lookup. We can query only the data we need. For example, if we have a view that shows only the actors, we can query the ActorsStore and get only the actors without any redundant data.

The recommend option is to perform the normalization on the server-side, so you can also benefit from a smaller payload. I’ve worked in several companies which have developed a generic solution on the server-side. If that’s not possible, you can always do it yourself or leverage a tool like normalizr as we are going to do on the client-side.

Build the Stores

First, let’s create the building blocks for each entity — store and query.

We store each entity in a separate table, i.e. store, and use query to get it.

Now, let’s create the movies component which will be responsible for displaying the movies:

The movies component is relatively straightforward. It queries the movies from MoviesQuery and calls getMovies() to fetch movies from the server.

Let’s examine the getMovies() method:

As I mentioned before, in our example, we’ll use normalizr to flatten the server response. I’m not going to focus on normalizr , but here is the code for our case:

Providing the unflattened response that we saw in the beginning, the above code will return the following structure:

We get the flattened response and update each store with the corresponding data. With actors and movies, we don’t worry about the order, so we call set() with the entities alone, letting Akita resolves the ids.

After initialized our stores, it’s time to create the final query:

That’s what I like to call a reactive join. We are querying the data from each query, mapping each id to its corresponding entity.