
## 1. Copy your keys from previous machine to same folder on next

Copy your keys from previous machine to same folder on next

On your previous mac
```bash
cd .ssh

open .
```

Copy following files to same destinations on new mac

```bash
id_rsa	- private key
id_rsa.pub - public key
```

## 2. Add keys to ssh agent on new mac

### Create configuration file

```bash
touch ~/.ssh/config
```

with content

```bash
Host github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_rsa
```

### Add your SSH private hay to ssh-agent
```bash
ssh-add --apple-use-keychain ~/.ssh/id_rsa
```


## See more

Read more how to connect to github with ssh on [official documentation](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent)


How to copy SSH keys to new Mac

Have you ever implemented **simple logic** that, though it looked very trivial at first glance, was actually **buggy**?

Omitted parenthesis, wrong operator or simply not all edge cases covered?
Then, have been running an application, again and again, only to discover yet another fault?
Or even worse, have to wait a while for CD have been completed, follow complicated reproduction steps just to notice yet another one?

Is there a better way to play this **game of cat and mouse.**

This article is about solving all those issues. It will significantly increase trust in a logic you've created!

We gonna use a **T**est **D**riven **D**evelopment with jest `Tagged Template Literal` approach.

`jest` is a widely known testing solution.
It offers `string template approach`, rather merely recognized but definitely underprices.

## Tagged Template Literal

Shortly speaking, it allows you to create one test to handle many different testing cases.
It makes a test more condensed but more readable and easy to change at one time.
This also makes it easy to add a new edge case or edit an existing one.

See more [here](https://jestjs.io/docs/api#2-testeachtablename-fn-timeout)

## Test Driven Development

We will be using TDD along the `table jest testing` because those both approaches fits together incredibly well.

Let's warm up first with a very trivial example in the TDD way, which stands for:

1. create a test with only one case (test will fail)
2. create a function with simply implementation (to fulfill the test)
3. add more test cases and modify the function to satisfy it if needed
4. refactor function to increase performance or readability if needed
5. run the test to check whether new changes didn't break anything

## Example 1: warming up

Let's add some numbers.
Who don't like to add numbers?

All source code you can find [here](https://github.com/WojciechCendrzak/tagged-emplate-iteral-jest-tests).

### Stage 1. create a test first

As the `TDD` approach stands, we will create a test that fails.
As we don't have the function implemented yet, let's use the mocked function.

```ts
const add = jest.fn();

describe(add.name, () =>
  test.each`
    a    | b    | expected
    ${2} | ${2} | ${4}
  `('$a + $b -> $expected', ({ a, b, expected }) => {
    expect(add(a, b)).toBe(expected);
  })
);
```

Test failed as expected due to mock function returns just nothing.

```bash
 FAIL  src/add/stage1/add.test.ts
  mockConstructor
    ✕ 2 + 2 -> 4 (5 ms)

  ● mockConstructor › 2 + 2 -> 4

    expect(received).toBe(expected) // Object.is equality

    Expected: 4
    Received: undefined

       6 |     ${2} | ${2} | ${4}
       7 |   `('$a + $b -> $expected', ({ a, b, expected }) => {
    >  8 |     expect(add(a, b)).toBe(expected);
         |                       ^
       9 |   })
      10 | );
      11 |
```

### Stage 2. fix failing test

Now there is time to acctually create `add` function:

```ts
export const add = (a: number, b: number) => a + b;
```

That ends with a passing test.

```bash
 PASS  src/add/stage2/add.test.ts
  add
    ✓ 2 + 2 -> 4 (2 ms)
```

### Stage 3. add more tests

Adding more cases is the super trivial as well:

```ts
import { add } from './logic';

describe(add.name, () =>
  test.each`
    a      | b    | expected
    ${2}   | ${2} | ${4}
    ${-2}  | ${2} | ${0}
    ${999} | ${1} | ${1000}
  `('$a + $b -> $expected', ({ a, b, expected }) => {
    expect(add(a, b)).toBe(expected);
  })
);
```

which all passes successfully now

```bash
 PASS  src/add/stage3/add.test.ts
  add
    ✓ 2 + 2 -> 4 (3 ms)
    ✓ -2 + 2 -> 0
    ✓ 999 + 1 -> 1000 (1 ms)
```

The _string template table_ gives you many benefits

- you have only one test for many test cases (no code duplication)
- test cases becomes very clear when case data are presented as a row of table
- first row describes name of the arguments so you have an instant understanding of what test data are
- is very easy to add cases, just copy a line (auto format works like charm there)

But is that really worth it?

## Example 2. Simply example with pitfall

Let's take a look for another, that looks equally simply but contains some common pitfalls that java script developers often falls into.

Let's say we want to calculate percentage of tasks done in our hypothetical todo app.

### Stage 1. create a test

Let's create a test first that falls:

```ts
const getPercent = jest.fn();

describe(getPercent.name, () =>
  test.each`
    done | total | expected
    ${5} | ${10} | ${50}
  `('$done done of total $total should give $expected %', ({ done, total, expected }) => {
    expect(getPercent(done, total)).toBe(expected);
  })
);
```

### Stage 2. simple implementation

Now implement a function to fulfill the test:

```ts
export const getPercent = (doneCount: number, totalCount: number) => (doneCount / totalCount) * 100;
```

### Stage 3. add edge case

Ready to deploy once can say.
But the other will point dividing by 0 bug when our list is empty.

Let's test it by adding one liner change:

```ts
describe(getPercent.name, () =>
  test.each`
    done | total | expected
    ${5} | ${10} | ${50}
    ${0} | ${0}  | ${'???'}
  `('$done done of total $total should give $expected %', ({ done, total, expected }) => {
    expect(getPercent(done, total)).toBe(expected);
  })
);
```

But wait. What we should return? 0%, 100% or undefined? As you can see we need to make a decision here.
I've chosen undefined for now.

```ts
describe(getPercent.name, () =>
  test.each`
    done | total | expected
    ${5} | ${10} | ${50}
    ${0} | ${0}  | ${undefined}
  `('$done done of total $total should give $expected %', ({ done, total, expected }) => {
    expect(getPercent(done, total)).toBe(expected);
  })
);
```

By doing that we have just made a piece of **documentation** to our function.

So let's fix a falling test now.

```ts
export const getPercent = (doneCount: number, totalCount: number) => {
  if (!totalCount) return undefined;

  return (doneCount / totalCount) * 100;
};
```

Are we ready for deployment now?

TDD encourages us to add more tests so let's check it out:



### Stage 4. one more test

```ts
describe(getPercent.name, () =>
  test.each`
    done | total | expected
    ${5} | ${10} | ${50}
    ${0} | ${0}  | ${undefined}
    ${5} | ${99} | ${5}
  `('$done done of total $total should give $expected %', ({ done, total, expected }) => {
    expect(getPercent(done, total)).toBe(expected);
  })
);
```

Test are failing now, so with different result.

```bash
 FAIL  src/get-percent1/stage4/get-percent.test.ts
  getPercent
    ✓ 5 done of total 10 should give 50 % (3 ms)
    ✓ 0 done of total 0 should give undefined %
    ✕ 5 done of total 99 should give 5 % (3 ms)

  ● getPercent › 5 done of total 99 should give 5 %

    expect(received).toBe(expected) // Object.is equality

    Expected: 5
    Received: 5.05050505050505

      10 |     '$done done of total $total should give $expected %',
      11 |     ({ done, total, expected }) => {
    > 12 |       expect(getPercent(done, total)).toBe(expected);
         |                                       ^
      13 |     }
      14 |   )
      15 | );
```

Looks we have additional decimal that we don't.

Let's fix it:

```ts
export const getPercent = (doneCount: number, totalCount: number) => {
  if (!totalCount) return undefined;

  return Math.round((doneCount / totalCount) * 100);
};
```

Not bad, we've just fixed a potential bug with strange numbers on the screen.
Let's explore more. Appetite grows with eating.

### Stage 6. refactor

Let's say we want to present percentage with some decimal numbers this time.

So refactor our test first:

```ts
describe(getPercent.name, () =>
  test.each`
    done | total | fractionDigits | expected
    ${5} | ${10} | ${0}           | ${'50'}
    ${0} | ${0}  | ${0}           | ${undefined}
    ${5} | ${99} | ${0}           | ${'5'}
    ${5} | ${10} | ${2}           | ${'50.00'}
    ${3} | ${9}  | ${2}           | ${'33.33'}
  `('$done done of total $total should give $expected %', ({ done, total, fractionDigits, expected }) => {
    expect(getPercent(done, total, fractionDigits)).toBe(expected);
  })
);
```

And our final implementation will looks like:

```ts
export const getPercent = (doneCount: number, totalCount: number, fractionDigits: number) => {
  if (!totalCount) return undefined;

  return ((doneCount / totalCount) * 100).toFixed(fractionDigits);
};
```

By running tests we can make sure all our changes still works like intended.

## Summary

Table testing of jest provides a very clean way to test multiple cases by having a single test. That also provide a nice way of documenting our function.
It could save a lot of our time especially when our manual testing condition require many clicks on app to get into required test conditions.

Jest testing - Tagged Template Literal in table testing


Dockerization is a powerful concept that makes the deployment process easier nowadays.
However, when not carefully implemented, Dockerfile could produce a **large image size** and **time-consuming** build process.

In this article, we'll cover how to optimize the docker image.

Note that this article is part of **Deploy NodeJs app** series about deploying application to the cloud:

- [Part 1 - AWS EC2](/post/deploy-nodejs-app-part-1-aws-ec2)
- [Part 2 - AWS EC2 with docker](/post/deploy-nodejs-app-part-2-aws-ec2-with-docker)
- [Part 3 - Optimising Docker image](/post/deploy-nodejs-app-part-3-optimising-docker-image)


We will use three steps to make our Dockerfile optimized:

1. Use lightweight base image
2. Use multi-stage Dockerfile
3. Investigate image layers for further optimization

## Initial Application

We'll start from an initial NestJs application. You can find it [here](https://github.com/WojciechCendrzak/nestjs-api/tree/docker-optimization-initial). The complete solution is [there](https://github.com/WojciechCendrzak/nestjs-api/tree/docker-optimization-step-3-yarn-clean-cache).

Let's take a look at an initial Docker file.

```dockerfile
FROM node:16

WORKDIR /usr/src/app

COPY package.json yarn.lock ./

RUN yarn

COPY . .

EXPOSE 3000

CMD [ "yarn", "start" ]
```

The built image should produce the following result:

```bash
$ docker build . -t nestjs-api

$ docker images

REPOSITORY  ... IMAGE ID       SIZE
nestjs-api  ... 150a5278252f   1.43GB
```

It is surprising to get **1.43 GB** of image size for NestJs starter app. Isn't it?

## 1. Use a lightweight base image.

Notice the first Dockerfile line:

```dockerfile
FROM node:16
```

We have used a **base image** named _node:16_. This image is a **Full Image of Debian**. It is suitable for general use. It would be a top choice when you are not sure what to chose yet.

However, there are a lot more images that we can choose from. The smallest one is **alpine**. And this will be our choice.

Let's compare other base docker images. For purposes of this comparison, we've produced them with Dockerfile containing only the first layer **FROM** with a specific image name.
So pure base image sizes looks like this:

```bash
node:16-alpine          112 MB
node:16-slim            176 MB
node:16                 907 MB
node:16-stretch         938 MB
```

As we see, **alpine** is the smallest one. Let's update the first layer of our Dockerfile:

```dockerfile
FROM node:16-alpine
```

As a result, we should get this image size:

```bash
REPOSITORY  ... IMAGE ID       SIZE
nestjs-api  ... 27a93957eb10   632MB
```

Not bad, not bad, we cut the output image by half.
Would we cut more? Obviously!

## 2. Use multi-stage builds

The goal of this step is to get rid of all **devDependencies** from the final image.
In production, we don't need any of them. But at the build time, we do. So how to deal with both needs?

_With multi-stage builds, you use multiple FROM statements in your Dockerfile. Each FROM instruction can use a different base, and each of them begins a new stage of the build. You can selectively copy artifacts from one stage to another, leaving behind everything you don’t want in the final image._

The idea of our optimization is simply:

- first stage: build an application
- second stage: copy **production build** from the previous stage without devDepencencies to the final image

Let's check it out:

```dockerfile
FROM node:16-alpine AS build-image

WORKDIR /usr/src/app

COPY package.json yarn.lock ./

RUN yarn

COPY . .

RUN yarn build

FROM node:16-alpine AS final-image

WORKDIR /usr/src/app

COPY package.json yarn.lock ./

RUN yarn --production

COPY --from=build-image /usr/src/app/dist ./dist

EXPOSE 3000

CMD ["node", "dist/main"]

```

Let's break it down:

```dockerfile
FROM node:16-alpine AS build-stage
```

Each stage starts from a **FROM** keyword.
Each stage will create a build stage that we can reuse later.
Note that we have a new keyword **AS**.
We will use it to give a name to a specific stage. Later on, we can use it as a reference. It's up to us how we name it.

```dockerfile
WORKDIR /usr/src/app

COPY package.json yarn.lock ./

RUN yarn

COPY . .
```

The following four lines are just the same as before.

```dockerfile
RUN yarn build
```

Previously we just run a **CMD** _yarn start_. It has triggered a build automatically behind and starts the app. This time, we need to generate a build only.

Time to the second stage.

```dockerfile
FROM node:16-alpine AS final-stage
```

We will use just the same base image, but this time, we will name it differently.

```dockerfile
WORKDIR /usr/src/app

COPY package.json yarn.lock ./
```

Then we set folder and copying packages like in the previous stage.

```dockerfile
RUN yarn --production
```

And here comes our optimization. We don't want to install any **devDependencies**. So we have to set the production flag to **production**

```dockerfile
COPY --from=build-image /usr/src/app/dist ./dist
```

We will use the output from the previous stage. As you can notice, we have used a **--from** parameter. It indicates from which image we will copy.

```dockerfile
EXPOSE 3000

CMD ["node", "dist/main"]
```

We are exposing port like before, and because this is the last stage, we run an app direct from the _dist_ folder containing our build.

Let's see the result:

```bash
REPOSITORY  ... IMAGE ID       SIZE
nestjs-api  ... de9a036cc871   392MB
```

It seems that we get rid of hundreds of MB.
But in comparison to pure alpine base image (112 MB), it looks like an app build takes about 250 MB?
Can we do something with this? Sure.

## 3. Investigate image layers

### Docker history

We can use **docker history** command line to check the sizes of specific layers.

```bash
$ docker history nestjs-api

IMAGE        CREATED BY                      ... SIZE
15d3d9fbf9eb CMD ["node" "dist/main"]        ... 0B
<missing>    EXPOSE map[3000/tcp:{}]         ... 0B
<missing>    COPY /usr/src/app/dist ./dist   ... 60.4kB
<missing>    RUN /bin/sh -c yarn --production... 279MB
<missing>    COPY package.json yarn.lock ./  ... 256kB
<missing>    WORKDIR /usr/src/app            ... 0B
<missing>    /bin/sh -c #(nop)  CMD ["node"] ... 0B
<missing>    /bin/sh -c #(nop)  ENTRYPOINT ["... 0B
<missing>    /bin/sh -c #(nop) COPY file:2387... 116B
<missing>    /bin/sh -c apk add --no-cache --... 7.77MB
<missing>    /bin/sh -c #(nop)  ENV YARN_VERS... 0B
<missing>    /bin/sh -c addgroup -g 1000 node... 98.5MB
<missing>    /bin/sh -c #(nop)  ENV NODE_VERS... 0B
<missing>    /bin/sh -c #(nop)  CMD ["/bin/sh... 0B
<missing>    /bin/sh -c #(nop) ADD file:8ec69... 5.61MB
```

Notice the size at line:

```bash
<missing>    RUN /bin/sh -c yarn --production... 279MB
```

We can expect that production build should take far less space.

Time to deep dive.

### Dive tool

_A tool for exploring a docker image, layer contents, and discovering ways to shrink the size of your Docker image._

Install Dive.

```bash
brew install dive
```

Explore Docker image with dive.

```bash
dive nestjs-api
```

As the result you should see following:

<img src="/images/optimizing-docker/dive.png"
     alt="Inspecting docker image wiht dive" />

This tool allows us to analyze file structure deeply. O the left-hand side, we have Docker **Layers** and the size they occupy on the disk. We can select a layer by arrows.

On the right-hand side, we can see details of the file structure that the selected layer affected.

Finally, we have discovered that yarn has created a **cache** when installing dependencies.

### Rearrange stages

To get rid of yarn cache, we can rearrange Dockerfile into this:

```dockerfile
FROM node:16-alpine AS initial-stage

WORKDIR /usr/src/app

COPY package.json yarn.lock ./

FROM initial-stage AS build-stage

RUN yarn

COPY . .

RUN yarn build

FROM initial-stage AS production-stage

RUN yarn --production

FROM initial-stage AS final-stage

COPY --from=production-stage /usr/src/app/node_modules ./node_modules

COPY --from=build-stage /usr/src/app/dist ./dist

EXPOSE 3000

CMD ["node", "dist/main"]
```

In the file above, we have four stages now. Let's take a closer look at each of them.

#### Stage 1. initial

```dockerfile
FROM node:16-alpine AS initial-stage

WORKDIR /usr/src/app

COPY package.json yarn.lock ./
```

In the first stage, we will create a **initial-stage** build. We will use it for all following three.

#### Stage 2. build

```dockerfile
FROM initial-stage AS build-stage

RUN yarn

COPY . .

RUN yarn build
```

In the second one, **build-stage**, we will make install dependencies and build our app. Notice that we are reusing a stage build from the previous stage.

#### Stage 3. production

```dockerfile
FROM initial-stage AS production-stage

RUN yarn --production
```

The third one, we need only to install production dependencies. Yarn will also create an internal cache.

#### Stage 4. final

```dockerfile
FROM initial-stage AS final-stage

COPY --from=production-stage /usr/src/app/node_modules ./node_modules

COPY --from=build-stage /usr/src/app/dist ./dist

EXPOSE 3000

CMD ["node", "dist/main"]
```

The **final-stage** is also based on **initial-stage**. In this stage, we will do nothing heavy but two things

- copy node-modules from **production-stage**
- copy build files from **build-stage**.

Notice that we won't copy a yarn cache file, so in that way, we will get rid of it.

Let's see the results:

```bash
REPOSITORY  ... IMAGE ID       SIZE
nestjs-api  ... 61de4c904e57   123MB
```

## Sum up

Finally, we have decreased the initial docker image from 1.43 GB to 123 MB in three steps.

```sh
Steps                       Image size   Decrease by

initial image               1.43 GB

1. use alpine base image     632 MB      798 MB  (55 %)
2. remove devDepencencies    392 MB      240 MB  (17 %)
3. remove yarn cache         123 MB      269 MB  (19 %)

Total                                    1.3GB   (91 %)
```

So in total, we have decreased the initial image by 1.3GB (91%).

Quite an impressive result. Isn't it?

Thanks for reading.


Deploy NodeJs app - Part 3 - Optimizing Docker image


In this, we'll cover how to **dockerized** NodeJs application. Finally, we will deploy it on AWS EC2.

Note that this article is part of **Deploy NodeJs app** series about deploying application to the cloud:

- [Part 1 - AWS EC2](/post/deploy-nodejs-app-part-1-aws-ec2)
- [Part 2 - AWS EC2 with docker](/post/deploy-nodejs-app-part-2-aws-ec2-with-docker)
- [Part 3 - Optimising Docker image](/post/deploy-nodejs-app-part-3-optimising-docker-image)


## What Docker is

**Docker** itself is a platform that allows us to manage **containerized** applications. It can run on Linux, Windows, and Mac.
Linux and Windows support it **natively**.

On Mac, Docker is running through a **lightweight Linux Virtual Machine**. So it is a Docker on Linux under the hood.
It also exposes Docker API to your Mac environment. Therefore we can use the Docker commands from the Mac terminal in the same way as on the native Linux.

In this tutorial, we will be using Mac. Make sure you have [**Docker Desktop**](https://www.docker.com/products/docker-desktop) installed.

You can check the installation by typing:

```bash
$ sudo docker version
```

The output should looks like this:

```bash
Client:
 Cloud integration: 1.0.17
 Version:           20.10.7
 API version:       1.41
 Go version:        go1.16.4
 Git commit:        f0df350
 Built:             Wed Jun  2 11:56:22 2021
 OS/Arch:           darwin/amd64
 Context:           desktop-linux
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.7
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       b0f5bc3
  Built:            Wed Jun  2 11:54:58 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
```

## What Container is

**Container** is a piece of software that runs in **isolation** from hosting OS and from other containers.

More precisely, it allows us to **package an application with its environment**, dependencies, and configuration.

Exp, it makes it easy to make development on the local machine. Then deploy it to the cloud without worries that some dependencies will be missing or has a version that our app is not supporting.

It allows us also to run multiple applications that use different versions of a specific library.
E. g two different versions of the same database engine. It wouldn't be easy without containers. We can achieve that by running multiply Virtual Machines on the host OS. With Docker containers, this is far way easy.

## Isn't the Container a VM itself?

This metaphor is accurate from a usage perspective, but not technically.
A container provides isolation just like a virtual machine but in a different way.

When running software on **virtual machine**, we need to install the guest OS on it. VM **shares hardware** from the host machine.

In opposition, the container shares not only hardware but **shares a host OS** too. It utilizes container concepts such as **cgroups** and **namespaces**. Those were implemented directly on the Linux kernel and then ported to Windows. So you don't need to install an additional OS.
It gives an advantage over the virtual machine such as:

- it is very **lightweight**,
- switching containers on/off is significant **faster**
- **no additional license** needed for VM guest OS

Docker Container can be from an **Image**.

## What Image is

In simple words, we can say that Docker Image is a **blueprint** for a container. Or a class, for instance. Or container template for a container. We can create a Docker Image through Dockerfile.

## What Dockerfile is

A Dockerfile is a recipe from which we will build an Image.
It is essentially a **text file** that contains the commands to build an image.
Those commands are read-only layers, each of which represents a Dockerfile instruction.
The layers are stacked, and each one is a delta of the changes from the previous layer.

## Complete flow

1. We will create a NodeJs app
2. We will create a **Dockerfile**
3. From a Dockerfile we will build an **Image**
4. We will run an Image into a new **Container**

## 1. Create a NodeJs project

We can create any NodeJs app or clone this git repo:

```bash
https://github.com/WojciechCendrzak/nestjs-api
```

A complete solution is also available here:

```bash
https://github.com/WojciechCendrzak/nestjs-api/tree/docker
```

## 2. Create a Dockerfile

Create a Dockerfile in main folder:

```dockerfile
# ./Dockerfile

FROM node:14

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD [ "npm", "run", "start" ]
```

Let's take a look at the Dockerfile anatomy and break it down, line by line.
You can check a full specification here [Dockerfile reference](https://docs.docker.com/engine/reference/builder/)

```dockerfile
FROM node:14
```

In the first line, we can define from which **parent Image** we want to start. It is also possible to create an image from scratch. In that case, we can completely omit **FROM**. But, in most cases, we will base a new Image on another existing one. It simplifies stuff a lot. In this case, we will use 'node:14'. This image comes with NodeJS version 14 LTS and npm installed. It will be taken from [Docker Hub](https://hub.docker.com/_/node) during the build process.

```dockerfile
WORKDIR /usr/src/app
```

Next, we set a working directory for any following Docker instructions. Later we will copy our NodeJs application there. It will be created on the container filesystem if not exists.

```dockerfile
COPY package*.json ./

RUN npm install
```

In the two following lines, we will install dependencies. First, we copy a package.json and package-lock.json (notice a wildcard \*). What interesting is we are not going to copy all project files. It is because we want to take benefit of **cached Docker layers**.

```dockerfile
COPY . .
```

After that, we want to copy our application source files to the container filesystem.
The first param stands for source. In this case, a dot means a folder containing Dockerfile.
The second is a destination inside the container filesystem. In this case, a dot means a WORKDIR that we set up before.

```dockerfile
EXPOSE 3000
```

Our NesjJs API is bind to port 3000. The EXPOSE instruction informs Docker that the container listens on that port at runtime.

```dockerfile
CMD [ "npm", "run", "start" ]
```

Finally, we will run API by triggering _npm run start_.
The template for providing this instruction is like that:

```bash
CMD ["executable","param1","param2"]
```

## 3. Buil an Image

Before we build, let create '.dockerignore' file

```bash
# .dockerignore

node_modules
npm-debug.log
```

It will prevent our local modules and debug logs from being copied onto our Docker image.

Let's navigate the directory with our Dockerfile and run the following command to build the Docker image.
The **-t** flag lets us tag our image, so it's easier to find later.

```bash
$ docker build . -t nestjs-api
```

Now we can list our new image:

```bash
$ docker images

REPOSITORY          TAG       IMAGE ID       CREATED         SIZE
nestjs-api          latest    cb53842aa908   8 seconds ago   1.17GB
```

## 4. Run the Container

```bash
$ docker run -p 3000:3000 -d nestjs-api
```

The **-p** flag redirects a public port to a private port inside a container.
We can also pass **-d** flag, and it will run the container in detached mode.
We can then close the console leaving the container running in the background.

## Check whether container is running

```bash
$ curl -i localhost:3000

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 12
ETag: W/"c-Lve95gjOVATpfV8EL5X4nxwjKHE"
Date: Fri, 02 Jul 2021 23:20:06 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Hello World!
```

## Other Docker commands

### List containers

```bash
$ docker ps

CONTAINER ID   IMAGE               COMMAND                  CREATED         STATUS         PORTS                                       NAMES
542cd674ae6b   nestjs-api          "docker-entrypoint.s…"   4 minutes ago   Up 4 minutes   0.0.0.0:3000->3000/tcp, :::3000->3000/tcp   suspicious_goldwasser
```

### Prints a logs

```bash
$ docker logs <container id>
```

### Stop the container

```bash
$ docker stop <container id>
```

### Go inside running container

```bash
$ docker exec -it <container id> /bin/sh
```

## Deploying on AWS EC2

Now we will see all the beauty of Docker:
We can run our dockerized NestJs API on AWS EC2 in the same way as locally.

First login to AWS EC2.

If you haven't yet created any EC2 check [this](/post/deploy-nodejs-api-on-aws-ec2) article.

After connected via SSH, let install first a docker:

```bash
$ sudo apt install docker.io
```

Let's double-check installation:

```bash
$ sudo docker version
```

Clone NestJs API from git and change branch 'docker':

```bash
$ git clone https://github.com/WojciechCendrzak/nestjs-api
$ cd nestjs-api
$ git branch -a
$ git checkout remotes/origin/docker
```

Build and run the container:

```bash
$ sudo docker build . -t nestjs-api
$ sudo docker run -p 3000:3000 -d nestjs-api
```

Finally, we can check whether it's alive from a local machine:

```bash
$ curl -i http://ec2-100-24-242-27.compute-1.amazonaws.com:3000
```

Thanks for reading.


Deploy NodeJs app - Part 2 - AWS EC2 with docker


In this article, we'll cover how to deploy a simply NodeJs API on AWS EC2. To ensure everything works fine, we will try to access it from the browser.

Note that this article is part of **Deploy NodeJs app** series about deploying application to the cloud:

- [Part 1 - AWS EC2](/post/deploy-nodejs-app-part-1-aws-ec2)
- [Part 2 - AWS EC2 with docker](/post/deploy-nodejs-app-part-2-aws-ec2-with-docker)
- [Part 3 - Optimising Docker image](/post/deploy-nodejs-app-part-3-optimising-docker-image)


## NodeJS server

We will use this sample repository with
NestJs API.

```sh
https://github.com/WojciechCendrzak/nestjs-api
```

You can also create your server app.

## AWS Free Tier

When creating **AWS** account, you can choose Free Plan, which allows you to access core services for a year. The **Free tier** services include EC2 ( Amazon Elastic Compute Cloud) t2.micro. It can run for a maximum of 750 hours per month for free. 24 hours per 31 days gives us 744 hours, which means we are still 6 hours ahead. So we can continuously use a single machine for an entire year for free.

We assume you have **AWS** account created already.

## Create EC2

1. On the **AWS console**, let's navigate to **Services** and then **EC2** and **Launch instance**.
2. Choose an Amazon Machine Image (AMI) - select **Ubuntu Server 20.04 LTS** (Free tier eligible)
3. Choose an Instance Type - check **t2.micro** (Free tier eligible) and press **Review and Launch**.
4. Review Instance Launch - ignore popup warning and press **Launch**
5. The following popup with **key-pair** allows you to either select or create a new key-pair. Public-private pair will make the connection to our server secure. As AWS will store a public part, we need to have a private one on our local machine. So let give any name (exp 'EC2-tutorial') and create a new one (or select if there any). Then **Download Key Pair**. We will need them later. Then press **Launch Instances**
6. Now, the server is created and started. Press **View Instances**
7. The Last thing, we need to configure **Security groups** to establish public access, exp from browser.
   From **EC2 > instances**, press on **Instance ID** link of instance that we have created. Select **Security** tab and press link at **Security groups**. On tab **Inbound rules** press **Edit inbound rules**.
   As you can see, there is a default rule already configured for **SSH** connection.
   Add another rule that allows access from any IP address to our instance over the internet on port 3000. We need this specific one because our NestJS API will be exposed on that port.
   Select **Custom TCP** type. Set port to **3000** and select source for **Anywhere**. Then press **Save rules** button.

## Connect to EC2 via SSH

Navigate to **EC2 > instances** to see SSH connection instructions and details. Select checkbox to the left of our created instance. Press **Action**, select **Connect** and select **SSH client**.

In the terminal, navigate to the folder with your private key.

Hide private key from public access.

```sh
sudo chmod 400 EC2-tutorial.pem
```

Let's now connect:

```sh
sudo ssh -i "EC2-tutorial.pem" ubuntu@ec2-100-27-3-238.compute-1.amazonaws.com
```

Congratulation. Once we got into the instance, let's make ubuntu packages update first:

```sh
sudo apt-get update
```

## Install NodeJs

Install node version manager (nvm):

```sh
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash
```

Activate nvm:

```sh
. ~/.nvm/nvm.sh
```

Install the latest version of Node.js

```sh
nvm install node
```

Double-check installation:

```sh
node -v
```

You should see the current version. In my case: _v16.4.0_.

## Clone repository from Git

Let's check whether _git_ is installed correctly:

```sh
git --version
```

That has printed me _git version 2.25.1_ this time.

Let's clone the app:

```sh
git clone https://github.com/WojciechCendrzak/nestjs-api
```

It will create a _nestjs-api_ project folder.

## Install API dependencies

Enter the project folder:

```sh
cd nestjs-api
```

Install dependencies:

```sh
npm i
```

## Start API

The following command will build the project into _dist_ folder on behind and start our API.

```sh
npm run start
```

## Access from Browser

As we previously set up **Inbound** with port 3000, we need to call with it.

Type this in the browser address bar:

```sh
http://ec2-100-27-3-238.compute-1.amazonaws.com:3000
```

Done. If everything was fine, we should see _'Hello World!'_

Thanks for reading.


Deploy NodeJs app - Part 1 - AWS EC2


In this article, we’ll cover typical use cases of RxJs in React application.

We will gonna use a tech stack that we have got familiar with in previous articles: RxJs, Redux Toolkit, Redux-Observable

Note that this article is part of RxJs series about the RxJs, Redux Observable, Redux Toolkit:

- [Part 1 - setup](/post/rxjs-redux-observable-redux-toolkit-part-1-setup)
- [Part 2 - boilerplate](/post/rxjs-redux-observable-redux-toolkit-part-2-boilerplate)
- [Part 3 - scenarios](/post/rxjs-redux-observable-redux-toolkit-part-3-scenarios)


So let's get started.

## Typical Frontend Scenarios

RxJs offers a large number of operators and stream creators. However, for a typical React application, you will probably need a small set of them. Those operators would be **filter**, **map**, **throttleTime**, **mergeMap**, **switchMap**, **forkJoin** and **catchError**. As for stream creators, we gonna use: **from**, **of** and **fromEventPattern**. We will try to look at them closely to see how they can be useful for common React app needs.

1. Fetching from API
2. Fetching from API with cancel
3. Calling API sequentially
4. Calling API parallelly
5. Emitting more than one action from epic
6. WebSocket listening
7. Avoiding multiply button click
8. Live search optimizing
9. Simple error handling
10. Bit advanced error handling

The complete source code you can see [here](https://github.com/WojciechCendrzak/react-redux-toolkit-rxjs-scenarios)

## 1. Fetching from API

To start from, we will go with something simple.
We will try to fetch some product from API and store it in the redux store.

```ts
// app.epic.ts

export const fetchProduct$: RootEpic = (actions$, _, { api }) =>
  action$.pipe(
    filter(appSlice.actions.fetchProduct.match),
    map((action) => action.payload.id),
    mergeMap((id) => from(api.fetchProduct(id))),
    map((product) => appSlice.actions.setProduct({ product }))
  );
```

Let's break down this flow:

We have declared **fetchProduct$** epic, which takes redux **actions$** stream, ignores second parameter **\_** as a state stream because we don't need them, and destruct **api** from provided epic dependencies.

Then we are **piping** through every action in order to call operators in sequence for it.

First, we **filter** out actions other than **fetchProduct**. Notice that we have used here a **match** function provided by Redux Toolkit that returns boolean and at the same time **narrow action type** to a specific payload. That is so useful when using Typescript. We will also get propper type check on the following operator's inputs.

And here is the definition of this action:

```ts
// app.slice.ts

export const appSlice = createSlice({
  name: 'app',
  initialState: initialAppState,
  reducers: {
    // ...
    fetchProduct: (_state, _action: PayloadAction<{ id: string }>) => {},
    setProduct: (state, action: PayloadAction<{ product: Product }>) => {
      const { product } = action.payload;
      state.producById[product.id] = product;
    },
    // ...
  },
});
```

Then we get and an **id** from an action payload using **map**

Then, most interestingly, we call **mergeMap** over internal short term observable created by **from** out of
**setProduct**, which was a **Promise**. But what is mergeMap itself?. There are some behaviors worth noticing here.

Based on the name of the operator, it will:

- take a **map** function that takes an outer observable action and returns a new inner observable
- **merge** all inner observables values into outer observable.

Speaking more precisely, it creates and subscribes to new internal observable.
Then it passes down all emitted values from all inner to outer observable.
In our case, we are creating an inner observable by using **from**.

How does it work in our real example?

Let's assume that we have a list of product cards with the basic information. And as a user, we want to expand each card to see more details by clicking on "see more" button. Users can click on multiply products in order to reveal all of them. So mergeMap will handle all the api calls and merge the results down to the outer observable.

The last one is **map** again. This time we take a result which is a product and return an action that will set it in store.

## 2. Fetching from API with cancel

This time let's say we have the same product list as before. But now there would be one separate place to show details of the selected product. The user can click on several product cards one after the other. However, we want to see only the last selected.

There is typically no guarantee that API will respond with the same order as was requested.
It could cause a subtle error. We could see a product that we did not choose last.

To solve this, we will use the **switchMap** operator this time.

Let's look at the code:

```ts
// app.epic.ts

export const fetchSelectedProduct$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.fetchSelectedProduct.match),
    map((action) => action.payload.id),
    switchMap((id) => from(api.fetchProduct(id))),
    map((product) => appSlice.actions.setSelectedProduct({ product }))
  );
```

Apart from different action names, the only difference with the previous code is that we have used **switchMap** instead of **mergeMap**.
And we have obtained **cancelation** just like this! Isn't awesome?

But how **switchMap** is working then?

Based on the name of the operator, it will:

- take a **map** function that takes an outer observable action and returns a new inner observable
- **switch** from the previous inner observable to this new, and propagate all its values to the outer observable.

Speaking more precisely, it creates and subscribes to new internal observable.
But compared to **mergeMap**, it unsubscribes from previous subscribed inner observable first. So all values emitted by all previous inner observables are just forgotten. Which means, **canceled**.

## 3. Calling API sequentially

Let's take a look into a scenario where we want to fetch data one after the other. But, to make a second fetch, we need data from the previous one.

A real example could be like this: we try to log in a user into the server with its credentials.
After success, we will then take a user id from the response and fetch user details.

Code would be like that:

```ts
// app.epic.ts

export const login$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.login.match),
    switchMap((action) => from(api.login(action.payload))),
    switchMap((response) => from(api.fetchUser(response.id))),
    map((user) => appSlice.actions.setUser({ user }))
  );
```

And our action are defined like this:

```ts
// app.slice.ts

export const appSlice = createSlice({
  // ...
  reducers: {
    login: (_state, _action: PayloadAction<{ login: string; password: string }>) => {},
    fetchUser: (_state, _action: PayloadAction<{ id: string }>) => {},
    setUser: (state, action: PayloadAction<{ user: User }>) => {
      state.user = action.payload.user;
    },
  },
});
```

As you can see, we have used **switchMap** twice.
Does it mean fetching in sequence? Yes.
Till the first fetching is unfinished, the first **switchMap** will emit nothing. And it causes the second one to wait.

Marvelous.

Ones first one emits result, in this case, data containing user **id**, the second will notice this and play its role. Finally, user details are placed in the store by emitted action **setUser**

## 4. Calling API parallelly

Now we will try to call endpoint multiply times parallelly and collect all results at once.

A real example could be like that: upload multiple images to the server parallelly. Once all files have been uploaded put their urls in the store.

Here is the epic code:

```ts
// app.epic.ts

export const uploadPhotos$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.uploadPhotos.match),
    map((action) => action.payload.files),
    switchMap((files) => forkJoin(files.map((file) => from(api.uploadPhoto(file))))),
    map((responses) =>
      appSlice.actions.setPhotos({
        photoUrls: responses.map((result) => result.url),
      })
    )
  );
```

And reducer cases:

```ts
// app.slice.ts

export const appSlice = createSlice({
  // ...
  reducers: {
    uploadPhotos: (_state, _action: PayloadAction<{ files: File[] }>) => {},
    setPhotos: (state, action: PayloadAction<{ photoUrls: string[] }>) => {
      state.photoUrls = action.payload.photoUrls;
    },
  },
});
```

As we can see, we used a **forkJoin**.

_"In parallel computing, the **fork–join model** is a way of setting up and executing parallel programs, such that execution branches off in parallel at designated points in the program, to **join** at a subsequent point and resume sequential execution"_

Let's break down the code line with **forkJoin**:

- first, we call a **map** through files and convert each file to observable.
- each observable is created by use **from** fed with API call (Promise).
- each observable is a short-lived stream that can return only one value and complete or throw an error.
- **forkJoin** is then fed with the observable list.
- **forkJoin** is waiting till all **observables** completes
- when all observables complete, emit the last emitted value from each.
- emitted result is an array of each call response with the same order as the initial files array

Finally, all responses array is mapped to urls array that **setPhotos** action require.

## 5. Emitting more than one action

Up to now, all our epic emits one action as a result of one action incoming.
But what if we want to emit more than one action?

A real example could be that:

- user press logout button
- logout endpoint is called
- all the user data are removed from the store
- the user is navigated to the home page

Let's take a look at the solution:

```ts
// app.epic.ts

export const logout$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.logout.match),
    switchMap(() => from(api.logout())),
    switchMap(() => of(appSlice.actions.reset(), appSlice.actions.navigateHome()))
  );
```

Again we used switchMap and fed it with observables of two redux actions created by **of** observable creator.

This time, whenever **logout** action is dispatched, two other actions: **reset** and **navigateHome** are emitted as epic output.

## 6. WebSocket listening

Now let's take a look at another scenario which is a **live chat**.
We want to show all incoming messages to our app through **WebSocket** and append it to a messages list.

Here is how code could be:

```ts
// app.epic.ts

export const startListeningFromWebSocket$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.startListeningFromWebSocket.match),
    map(() => api.startWebSocketClient()),
    switchMap((webSocketClient) =>
      fromEventPattern<MessageEvent<string>>(
        (handler) => webSocketClient.addEventListener('message', handler),
        (handler) => webSocketClient.removeEventListener('message', handler)
      )
    ),
    map((event) => event.data),
    map((message) => appSlice.actions.appendMessage({ message }))
  );

// app.api.ts
export const api = {
  startWebSocketClient: () => new WebSocket(WEB_SOCKET_URL),
};
```

Let's break down:

- **startListeningFromWebSocket** action is dispatched and filtered here
- in **map** line, WebSocket client is created and pass down to the **switchMap**.
- **fromEventPattern** takes two parameters **addHandler** and **removeHandler**. Those are provided with WebSocket handlers accordingly.
- ones **fromEventPattern** is triggered, **addEventListener** is called and **fromEventPattern** starts emitting values down to outer observable as they comes from WebSocket client
- when **switchMap** inner observable is unsubscribed, **removeEventListener** is triggered
- last two maps gets a message from incoming WebSocket event and emits **appendMessage** action

## 7. Avoiding multiply button click

In lots of cases, we want to prevent **accidental multi-click**.

What's really cool about RxJs we can get this behavior in **one line only**!.

Let's add this line to the code we have before:

```ts
// app.epics.ts

export const loginThrottle$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.login.match),
    throttleTime(250), // <---
    switchMap((action) => from(api.login(action.payload))),
    switchMap((response) => from(api.fetchUser(response.id))),
    map((user) => appSlice.actions.setUser({ user }))
  );
```

**throttleTime** emit first value then ignore for a specified duration. In our case, 250 milliseconds.

From now every accidental **multi-click** will become a **single click**.

## 8. Live search optimizing

Let's imagine input where a user can type a **search phrase**. While typing, results are adjusted **on the fly**. So far, so good. But when we use API endpoint to get results, we will generate a **lot of traffic**.

Here is a solution:

```ts
// app.epic.ts

export const searchProduct$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.searchProduct.match),
    throttleTime(250, asyncScheduler, {
      leading: true,
      trailing: true,
    }),
    mergeMap((action) => from(api.searchProducts(action.payload.searchPhrase))),
    map((response) => appSlice.actions.setProducts({ products: response }))
  );
```

We used **throttleTime** again but now have some extra parameters: **leading** and **trailing** set to true. It means that:

- for the very first **searchProduct** action, API will be called (leading)
- after 250 milliseconds from the last **searchProduct** action, API will be called again (trailing). In that case, a **searchPhrase** will be taken from the last action payload.
- all actions in between will be skipped

## 9. Simple error handling

What's if an error occurs in our epic.
Let's say we tied to fetch a product from API, but we failed.

**catchError** operator comes to rescue.

```ts
// app.epic.ts

export const fetchProductWithSimpleErrorHandler$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.fetchProduct.match),
    mergeMap((action) =>
      from(api.fetchProduct(action.payload.id)).pipe(
        // Placement 1. this will end only internal observable
        catchError((error: Error) => {
          console.log(`Error message: ${error.message}`);
          return EMPTY;
        })
      )
    ),
    map((product) => appSlice.actions.setProduct({ product })),
    // Placement 2. this will end outer observable (epic)
    catchError((error: Error) => {
      console.log(`Error message: ${error.message}`);
      return EMPTY;
    })
  );
```

### Placement in epic

Placement of **catchError** operator in epic is crucial.
Not matter whether the error was caught or not, it will **end the observable lifecycle** inside which it happened.

The second placement will then disable our epic for handling any further **fetchProduct** action.

So that is why we need to catch potential error inside the inner observable (first placement). When we call **fetchProduct** again, a new observable will be just created and live again.

### Alternative observable

**catchError** operator must return alternative observable that could be anything. For example, actions for navigating to Not Found page, etc. In our case, we return EMPTY observable, which emits nothing, and completes immediately.

## 10. Bit advanced error handling

In this scenario, we will create a new operator named **managed** to handle errors.
Here are assumptions:

- it will take one parameter, which is an operator we want to manage
- it will handle an error inside this new operator

In that assumptions, we have a couple of benefits:

- have a **central place** of catching errors
- **delegates** error handling to this new operator
- have main logic more **readable**.
- **reuse code**

Here is the code with managed operator:

```ts
// app.epic.ts

export const fetchProductManaged$: RootEpic = (actions$, _, { api }) =>
  actions$.pipe(
    filter(appSlice.actions.fetchProduct.match),
    managed(mergeMap((action) => from(api.fetchProduct(action.payload.id)))),
    map((product) => appSlice.actions.setProduct({ product }))
  );
```

And here is managed operator code itself:

```ts
export type Managed = <T, A>(operator: OperatorFunction<T, A>) => OperatorFunction<T, A>;

export const managed: Managed = (operator) =>
  mergeMap((action) =>
    of(action).pipe(
      operator,
      catchError((error: Error) => {
        console.log(error);
        return EMPTY;
      })
    )
  );
```

As you can see our new operator takes an operator we want to manage.
Then create an inner observable that could be safely ended when an error occurs.
Then we composed **managed operator** and **catchError** operators in pipe sequence.

Thanks for reading.


RxJs, Redux Observable, Redux Toolkit. Part 3 - scenarios


Wanna try more **RxJs** in your React application to deal with asynchronous code **effectively**? If yes, then you have come to the right place.

In this article, I will try to cover how to bootstrap a lean, robust boilerplate.

Note that this article is part of RxJs series about the RxJs, Redux Observable, Redux Toolkit:

- [Part 1 - setup](/post/rxjs-redux-observable-redux-toolkit-part-1-setup)
- [Part 2 - boilerplate](/post/rxjs-redux-observable-redux-toolkit-part-2-boilerplate)
- [Part 3 - scenarios](/post/rxjs-redux-observable-redux-toolkit-part-3-scenarios)


## For who is this article?

I assumed that you have some knowledge about React, Redux, and TypeScript

## Goal

To begin with, let's define the goal we want to achieve:

- take advantage of **functional programming** to solve the complexity
- **decrease** the large **boilerplate**, that usual redux solution brings
- **keep refactoring easy** as the code base grows
- **trust in** yours code more,
- and most importantly, **keep fun** :)

## Working example

For this article, we will be creating a search for IT books. It will be a simple application with two pages. One with search bar and books result and second with books more details.
If you are more source code readers, you can find a complete solution [here](https://github.com/WojciechCendrzak/react-redux-toolkit-rxjs)

## Problem we gonna solve

**Redux** is one of the so well know and widely used libraries. However, among the many advantages, it has one significant drawback. A pretty **large boilerplate**. With all those _action types, action creators, mapStateToProps, high order components_, the **code loses its readability** and the possibility of **efficient refactoring**.

The solution in this article is more convenient.

So let start.

## Solution

Here are a main building block:

- [@reduxjs/toolkit](https://redux-toolkit.js.org/) - The official, toolset for Redux
- [RxJs](https://rxjs.dev/) - Reactive Extensions For JavaScript
- [redux-observable](https://redux-observable.js.org/) - RxJs-based middleware for Redux

These three libraries work well together. We will try to show it below.

## Redux Toolkit

If you have not used the redux toolkit yet, it is time to get started.
More than sure that if you try once, you will not want to come back.
It is [officialy recomemed](https://redux.js.org/), immutable by design, and uses redux behind anyway.
Combined with React hooks, it is a part that will significantly decrease a boilerplate.

### Slice

The easiest way to create redux actions is through Slice.

But what is a **slice**?

_"... automatically generates action creators and action types that correspond to the reducers and state."_[check here](https://redux-toolkit.js.org/api/createSlice)

Isn't that cool?

Let's take a closer look at how our **Slice** is defined:

```ts
// book.slice.ts

export const bookSlice = createSlice({
  name: 'book',
  initialState,
  reducers: {
    setSearchPhrase: (state, action: PayloadAction<{ searchPhrase: string }>) => {
      state.searchPhrase = action.payload.searchPhrase;
    },
    fetchBooks: () => undefined,
    setBooks: (state, action: PayloadAction<{ books: Book[] }>) => {
      state.books = action.payload.books;
    },
    // ...
  },
});

// reducer state definition
export interface BookState {
  searchPhrase?: string;
  books?: Book[];
}

const initialState: BookState = {};
```

As we can see **createSlice** contains some configuration:

- we have a **name**, used in generated action types
- the **initialState** for the reducer
- **reducers** object of _case reducers_ and redux action at the same time!
- action could take parameters like **setSearchPhrase** and have a case reducer body. What interesting Redux Toolkit uses [immer](https://www.npmjs.com/package/immer) internally automatically. So, you don't need to create a new state but only _mutate_ it
- some actions could be parameterless and bodiless like **fetchBooks**. We gonna use it only to trigger async logic in **Epic**

## RxJs

_“compose asynchronous and event-based programs by using observable sequence”_

**Functional programming** is becoming more and more popular nowadays.
It is much more different from imperative language.
Therefore, the **learning curve is a bit steep**.
However, if you cross a certain threshold, you will not want to come back.

**RxJs** It is sometimes called **lodash for stream**.

## Redux Observable

It is a middleware for handling asynchronous operations from a sent action.

There are a couple of things it does:

- emits dispatched redux action into action stream
- introduce **Epic** as a piece of RxJs
- feed Epic with redux action stream and take action stream
- subscribe to all Epics,

### Epic

As the documentation says:

_"It is a function that takes a stream of actions and returns a stream of actions."_

With a **pipe** function, you can process single action through any number of operators.

Especially we will use Epic for:

- keep **business logic** / **user story** in one declarative flow,
- decouple logic from view by **call and forget** approach
- keep trust our code by **function composition** and great **type flow**

Here is an example:

```ts
// book.epic.ts

const fetchBooks$: RootEpic = (action$, state$) =>
  action$.pipe(
    filter(bookSlice.actions.fetchBooks.match),
    throttleTime(250),
    map(() => getSearchPhrase(state$.value)),
    switchMap((searchPhrase) => from(bookApi.fetchBooks(searchPhrase))),
    map((result) => bookSlice.actions.setBooks({ books: result.books }))
  );
```

Let's go through it step by step

**fetchBooks$** epic is a function that takes **action$** as actions stream.
"$" at the end is just a naming convention to indicate we are dealing with streams).

It also takes **state$** as a stream from which we can select some value later on.

Then we have a **pipe** that lets us **compose** operators in a sequence.

**Operators** work on a single value emitted to the stream.
The output of one operator is fed into the next operator as input.
The first operator in epic always takes a redux action. The last must return redux action.

Then we have a couple of operators:

### filter operator

When action is dispatched, all epis are called.

All epics will be triggered after dispatching an action.
Typically we want to call specific logic for single action only.
Redux Toolkit provides a **match** function for all actions. Moreover, it implements **type guard** of TypeScript. So the following operator will get action with a specific payload as was defined in Slice. So we can take benefit of a **one-time cost** action definition. That could help us at refactoring time.

Isn't it awesome?

### throttleTime operator

We want to trigger a search as we type a search phrase. However, it will produce too many API calls.
This **one-liner** will skip all but one action every 250 milliseconds.

What a great declarative approach!

### map operator

It's pretty straightforward.
We take a search phrase from the selector **getSearchPhrase**.

Here is how it is defined:

```ts
export const getSearchPhrase = (store: StoreState) => store.book.searchPhrase || '';
```

### switchMap operator

Here is the part that calls API.

The function **from** creates an internal stream out of **Promise**.
On success, it will emit a response data of API call to that stream.

What switchMap does is to take that stream and flatten it into an upper stream.

### map operator again

Finally, the last map will take a response object and return an action (as required by Epic) to set books in the reducer.

Then, an Epic will dispatch this action.

## Close the Redux cycle

In a search form, we can trigger a book fetching by dispatching a **fetchBooks** action.
It's helped us to decouple logic from view by **call and forget** approach.

```ts
// search-form.tsx

export const SearchForm: React.FC = () => {
  const dispatch = useDispatch();

  const handleSearch = useCallback(() => {
    dispatch(bookSlice.actions.fetchBooks());
  }, [dispatch]);

  // ...
```

Then we can show the search results in the list just by selecting them from the store state.

```ts
// book-cards.tsx

export const BookCards: React.FC = () => {
  const bookCards = useSelector(getBookCards);

  return (
    <>
      <Title>{translate(translationKeys.common.searchForm.title)}</Title>
      {bookCards?.map((bookCard, index) => (
        <BookCard key={index} book={bookCard} />
      ))}
    </>
  );
};
```

```ts
// book.selector.ts

export const getBookCards = (store: StoreState) => store.book.books;
```

```ts
// app.reducers.ts

export interface StoreState {
  book: BookState;
}

export const reducers = {
  book: bookSlice.reducer,
};
```

See complete solution code [here](https://github.com/WojciechCendrzak/react-redux-toolkit-rxjs)

## Sum up

- we took benefits of **functional programming**. Especially a composition as a great concept for solving the **complexity** grows.
- we have **decreased** the large **boilerplate**, that usual redux solution brings
- with TypeScript, ReduxToolkit and lose coupling **keep refactoring easy** as the code base grows
- with great type flow in Epics we obtain more code **quality** and more **trust** in our code,
- we keep **business logic** in one place,
- we express business logic in a declarative way so we can reflect better a **user story**

- and most importantly **have fun** hopefully, :)

Thanks for reading.


RxJs, Redux Observable, Redux Toolkit. Part 2 - boilerplate


In this article, we will put together a simple React, ping pong application to show the idea of ​​reactivity.

Note that this article is part of RxJs series about the RxJs, Redux Observable, Redux Toolkit:

- [Part 1 - setup](/post/rxjs-redux-observable-redux-toolkit-part-1-setup)
- [Part 2 - boilerplate](/post/rxjs-redux-observable-redux-toolkit-part-2-boilerplate)
- [Part 3 - scenarios](/post/rxjs-redux-observable-redux-toolkit-part-3-scenarios)


So let's start:

## Bootstrap

First, we will initialize CRA application with TypeScript

```shell
yarn create react-app react-redux-toolkit-rxjs-setup --template typescript
```

Then we will add libraries

```shell
yarn add @reduxjs/toolkit react-redux rxjs redux-observable@2.0.0-rc.2
```

## Building block

Create a redux Toolkit slice

```ts
// app.slice.ts

import { createSlice } from '@reduxjs/toolkit';

export interface AppState {}

const initialState: AppState = {};

export const appSlice = createSlice({
  name: 'app',
  initialState,
  reducers: {
    ping: () => {},
    pong: () => {},
    endGame: () => {},
  },
});
```

Then we will create an Epic

```ts
// app.epic.ts

import { Action } from '@reduxjs/toolkit';
import { combineEpics, Epic } from 'redux-observable';
import { filter, map, tap } from 'rxjs/operators';
import { appSlice } from './app.slice';

export type RootEpic = Epic<Action, Action>;

const ping$: RootEpic = (action$) =>
  action$.pipe(
    filter(appSlice.actions.ping.match),
    tap(() => console.log('ping')),
    map(() => appSlice.actions.pong())
  );

const pong$: RootEpic = (action$) =>
  action$.pipe(
    filter(appSlice.actions.pong.match),
    tap(() => console.log('pong')),
    map(() => appSlice.actions.endGame())
  );

export const appEpic$ = combineEpics(ping$, pong$);
```

## Put it together

Create a store

```ts
// app.store.ts

import { Action } from '@reduxjs/toolkit';
import { createEpicMiddleware } from 'redux-observable';
import { configureStore } from '@reduxjs/toolkit';
import { appSlice } from './app.slice';
import { appEpic$ } from './app.epic';

const epicMiddleware = createEpicMiddleware<Action, Action>();

export const store = configureStore({
  reducer: {
    app: appSlice.reducer,
  },
  middleware: [epicMiddleware],
});

epicMiddleware.run(appEpic$);
```

Provide a store

```ts
// index.tsx

import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import { App } from './app/app';
import { store } from './app/app.store';

ReactDOM.render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>,
  document.getElementById('root')
);
```

## Fire action

Finally, let's dispatch a ping action

```ts
// app.tsx

import { useEffect } from 'react';
import { useDispatch } from 'react-redux';
import { appSlice } from './app.slice';

export const App = () => {
  const dispatch = useDispatch();

  useEffect(() => {
    dispatch(appSlice.actions.ping());
  }, [dispatch]);

  return <div>Ping pong setup</div>;
};
```

In the console log you should see:

```shall
ping
pong
```

See complete code [here](https://github.com/WojciechCendrzak/react-redux-toolkit-rxjs-setup)

Thanks for reading.


RxJs, Redux Observable, Redux Toolkit. Part 1 - setup


**TypeScript** is awesome. Like **i18next** too. It works with TypeScript great but has one drawback. We need to provide a translation key as a plain string. It doesn't matter for small apps, but it does indeed for complex one when your translation file start to have hundreds of lines.

In this article, I want to show the way to solve that. It will leverage our localization experience to the next level.

## Goal

When using TypeScript we expect that tools will behave in some beneficial way like:

- we can use IDE **IntelliSense** to pick a specific key from object structure instead of the path as a string,
- we can **easily refactor** translations structure and still trust our code,
- we want to be **able to navigate** to a specific key location in the translation object structure,

So let's look at the solution.

What i18next offers as an out of the box looks like this:

```ts
// translation.ts

import en from './en.json';
import i18next from 'i18next';

i18next.init({
  lng: 'en',
  resources: {
    en: {
      translation: en,
    },
  },
});
```

When having translation file like:

```json
{
  // en.json

  "homePage": {
    "title": "Home page",
    "homaPage": {
      "header": {
        "buttons": {
          "signIn": { "title": "Sign In" },
          "signUp": { "title": "Sign Up" }
        }
      }
    }
  }
}
```

We can access specific translated value by typing key as a string path:

```ts
i18next.t('homePage.header.buttons.signIn.title');
```

As you can see, by having the **translation key as a string**, we are losing all benefits described above.

## Solution

What we want to achieve is something that looks like this:

```ts
i18next.t(keys.homePage.header.buttons.signIn.title);
```

What fun is, the typescript already allows us to load JSON files into the code and enjoy the benefits of IntelliSense already running there.

Now we need a new object named keys with the same structure as our JSON file. But instead of translated values at every leaf, we need to have **that key as a path**. Because i18next.t function still needs that path.

So by accessing:

```ts
keys.homePage.header.buttons.signIn.title;
```

We want to recievie:

```ts
'homePage.header.buttons.signIn.title';
```

To achieve this, we need to transform the JSON file into another one like this:

```ts
import { reduce } from 'lodash';

const getTranslationKeys = <T>(translations: T, path = ''): T =>
  reduce(
    translations,
    (accumulator, value, key) => {
      const newPath = `${path}${path ? '.' : ''}${key}`;
      return {
        ...accumulator,
        [key]: isObject(value) ? getTranslationKeys(value, newPath) : newPath,
      };
    },
    {}
  );
```

This code will **recursively** enumerate all the key/value pairs. When a value is an object it will call himself with path collected so far. Otherwise, it reaches the leaf and returns the path. Finally, all the leaves will contains paths as expected.

Now we can create keys object and get our translation:

```ts
import en from './en.json';
import i18next from 'i18next';

i18next.init({
  lng: 'en',
  resources: {
    en: {
      translation: en,
    },
  },
});

const translationKeys = getTranslationKeys(en);

const value = i18next.t(translationKeys.homePage.header.buttons.signIn.title);
```

## End note

Finally, we've reached the goal.
Now the TypeScript and IDE tools are active when we reference the translation keys. And we can trust our code more.

See also [i18n-keys](https://github.com/WojciechCendrzak/i18n-keys) library that fully implements this concept.

Thanks for reading.


Last Article