The IT market where I live is currently pretty bad for juniors and early mid developers. 
To get an interesting position you first need to be the lucky one that gets to technical interview. And when you get the chance you want to be ready.

So I keep myself busy by learning a lot of theory required for many of these positions like microservices and cloud architecture, design patterns and so on. 

I recently went through a challenging technical interview. After an hour and a half of all the usual “how js and node works” and a lot of serverless architecture questions I got to the live coding part. The task was rather simple but I think I could do a better job in finishing it faster. So I decided to practice solving these code puzzles on a more regular basis.

In this post I want to show you my approach to solving “Valid braces” kata from [Codewars](https://www.codewars.com). The task was actually sent to me by a  dear friend of mine and the message following the link read “This will b**w your mind”.

### The Problem
The Puzzle is called "Valid Braces".

You are given a string of different types of braces “{[(“.

Your task is  to write a function that validates if each brace has a corresponding pair similar to how your IDE would suggest a missing brace closing.

Example outputs would look like this: 
```
// "(){}[]"   =>  True
// "([{}])"   =>  True
// "(}"       =>  False
// "[(])"     =>  False
// "[({})](]" =>  False
```
The solution requires making use of a stack - a data structure that takes an element that was added last if condition is met. Similarly to a list of orders are put to a stack of cards.

We will also need a map of braces. We can either use Javascript Map class or a plain Object. 

```
function validBraces(braces){
  const bracesMap = {"(":")", "{":"}", "[":"]"}  
```

Then we will declare a stack in the body of function. It will be an array and we will use push and pop to add and remove elements from top. This way we can track our progress as we progress with our iteration.

```
 const stack = []
 
  for (let brace of braces) {
```

First we check if the brace is in the keys of our map. If it is an opening brace - we push it to array. Notice that closing brackets will not satisfy this condition.

```
  if (bracesMap[brace]){
    stack.push(bracesMap[brace])
```

Then if our stack Is not empty and the last element is equal to the current brace we remove it from the stack. If the brace is not in our braces map, or if the stack is empty we return false.

```
  } else if (stack.length > 0 && stack[stack.length - 1] === brace){
    stack.pop()
} else {
    return false
  }
}

```
After iteration is over we check the length of our stack. If it’s empty it means each brace has a corresponding brace. Otherwise we return false

```
  return stack.length === 0
}
```

This approach has a time complexity of [O(n)](https://en.wikipedia.org/wiki/Big_O_notation) which is good. It only requires iterating over string elements array once. 

What is a trace of running this test string of braces "[{[]}]" ?


```
[]
[ ']' ]
[ ']', '}' ]
[ ']', '}', ']' ]
[ ']', '}' ]
[ ']' ]
[]
```

### Summary

This way our code is quite easy to read. I think it's clever and unintuitive to use stack. At first glance I feel like I should write set of complex rules and conditions to check if braces are closed properly. But here we iterate through our string array once and just track if any braces are left open in the end. How cool is that?





large_valid_braces.jpeg

medium_valid_braces.jpeg

small_valid_braces.jpeg

thumbnail_valid_braces.jpeg

valid_braces.jpeg

Brace yourself - code kata solution


GithubActions is CI/CD platform that allows automating processes going on in our repositories. What can be automated? Anything that we would require us logging to a server and running bunch of commands in ssh terminal. From pulling new code, building the app, running tests to restarting app on server.

My blog is hosted on [MIKR.US](https://mikr.us), an amazing and really cheap VPS platform great for side projects. Everytime I push new code to repo I need to connect to my server via SSH, navigate to app directory and run several commands. In this post I will show you how to automate these steps.

To start we need to create a directory in the root of our project. 
```
.github/workflows
```
We then will create a [yaml file](https://www.redhat.com/en/topics/automation/what-is-yaml) named after workflow we are developing, since I want to automate deployment it will be: 
```
.github/workflows/staging-deploy.yaml
```

There are 2 keywords that require explanation here 💡
- **workflow** is this configurable automated process that can run one or more jobs when triggered. It's customised in the yaml file. One repository can have multiple workflows with different tasks triggered on different events each. You can have one workflow run build and tests when PR is created, another one can deploy app when release is created, and another workflow can be adding labels to issues when new ones are opened.  
- **triggers** cause workflows to run. Workflows can be triggered manually from github platform, on schedule, or by [events](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) in repository (for example creating a PR) or outside of GitHub

This is my workflow [code]():
![Screenshot 2023-05-09 at 11.10.06.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1683623423/Screenshot_2023_05_09_at_11_10_06_98467142fc.png)

**On** key defines which action casuses workflow to run. Event triggering my workflow is **workflow_dispatch** which means manual running the workflow from repos github page. Which still is a huge time saver. It will allow me to go to my repo, click Actions tab and just run it.

![Screenshot 2023-05-09 at 11.13.50.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1683623682/Screenshot_2023_05_09_at_11_13_50_1c08770b1e.png)

Each workflow is made up of one or more **jobs**. Each of them runs in a runner environment that is specified in **runs-on** key. Job contains a sequence of tasks called **steps**.  

## Reusable actions ♻️

Sometimes we might want to use a ready made action, reusable unit of code in our workflow. For that we have keyword **uses** that points to action defined in same repository, in public repository or in a published Docker container image. We are using a public action for [connecting to server with ssh](https://github.com/appleboy/ssh-action): 

```
#{owner}/{repo}@{ref}

appleboy/ssh-action@master
```

Public actions will have documentation on how to incorporate them into you workflow. Here we are using **with** keyword to create a set of environment variables required for action. We wil need to then provide them in our repo settings like this:

![Screenshot 2023-05-09 at 11.35.20.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1683624952/Screenshot_2023_05_09_at_11_35_20_350d3de172.png)

⚠️ When you start a repo you will not see any secrets. You need to create them! Make sure that all the secrets you created are named exactly the same ⚠️ 

After setting environment variables we need to add a list of commands that we would otherwise type in manually on the server. What are they? 

1. Navigate to blog frontend directory
2. Pull code from repository
3. Build Next app
4. Restart running pm2* process

If you have successfully added your secrets you should be able to run your action from github. 

## Setting up multiple repos on server 🚥

However I had one problem I could not figure out until I got to this section of [github keyd managing docs](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys).

When workflow got to the step where I needed to pull code from repo I got permission denied error. What I needed to do is set separate keys for my repos (I have more than one repo on my VPS). 

🔑 First generate new keys in your .ssh folder on your server for each of your git repos. I left passphrase empty, otherwise the script would not complete git pull. Read about key generation procedures [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key) In short use this command from github docs:


```
### remember to use your own email
$ ssh-keygen -t ed25519 -C "your_email@example.com"
```


For that you need to create an ~/.ssh/config file and create aliases for your repos like this: 


```
### this files resides here ~/.ssh/config 
Host github.com-go-jo-waystar
        Hostname github.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host github.com-repo-1
        Hostname github.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key
```

Then in each of the repos you added your ssh alias to you will need to change this in remote "origin" url section of your repos .git/config. So on your server in app folder run:


```
nano .git/config
```
and then just substitute your url with your repo alias like this 

```
[remote "origin"]
        ## url = git@{SSH_ALIAS}:{OWNER}/{GITHUB_REPO_NAME}
        url = git@github.com-go-jo-waystar:kendallroy/go-jo-roy.git
```

I found [this discussion](https://stackoverflow.com/questions/5210286/git-setup-for-multiple-repos-on-same-server) on stackoverflow helpful in solving this problem.

Now every time I push to my repo I can run GitHub action without logging to my server and doing all the steps manually. Later on I might want to trigger this workflow on a different event.

## References 📚

- Workflow uploaded to this blog [repo](https://github.com/stasdudzik/strapi-blog-next/blob/main/.github/workflows/staging-deploy.yaml)
- GithubActions [docs](https://docs.github.com/en/actions)
- Managing github deploy keys [docs](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys)
- [pm2](https://pm2.keymetrics.io) is a popular node.js process manager I use for running node.js apps on my server
 

large_manufacturetocat.png

medium_manufacturetocat.png

small_manufacturetocat.png

thumbnail_manufacturetocat.png

manufacturetocat.png

Automating GitHub workflow


WebSockets is a communication protocol built on top of HTTP in 2008. Now it's a standard and all browsers support it for about a decade. What is so specific about it is the fact that unlike request/response communication patterns it allows for creating connection over TCP(ports 443 or 80) that is kept alive, it opens a channel so to speak between client and a server and allows for streaming data between them. Most popular use case? Chat.

### WebSocket connection 🤝
You have probably heard at some point about a handshake in computing. Initialising connection in HTTP protocol starts with a “three way handshake”. Client sends SYN signal to server, server acknowledges the connection with SYN-ACK message and then client replies with acknowledgment (ACK). It’s as meeting a friend you would say “Hi Stas, Can I talk to you?” Stas would reply: “Yes, we can talk”, and then you would say something like : “It’s very nice that you allow me to talk to you”. And only then would conversation start. 

WebSockets handshake is a little bit different. It uses **HTTP UPGRADE** header that signalises initiating web socket connection.** Later on you will see it in dev tools!

### The problem ❓
Since I’ve also been playing around with docker recently - I wondered how to scale this kind of simple chat application if the connection is **stateful**? How can we persist clients' connection to specific server instances and have all chat users receive messages even though they are connected to separate instances that don’t know about each other? 

First of all - I will use dev tools as client to start a connection and send messages. I will use docker-compose to spin up load balancer using haproxy image, several of  node chat apps  and finally redis as a pub/sub broker.

This should work like this:

![Schema.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682683635/Schema_3692a0d9b0.png)


💡: **Redis** is a very popular in memory data store often used for caching costly/slow database queries. **Load balancer** is sort of a gate that divides incoming messages to different server instances. I highly recommend reading [this explainer](https://samwho.dev/load-balancing/ ) that uses animations to illustrate different balancing strategies.

### Docker Compose 🐋

Now I need a way to spin up several instances of my app and other elements of the infrastructure. We will get to the code part later on.

Firstly we need to create a **docker-compose.yaml** file, you give to docker and it sets up everything from this instruction including list of docker images.

![dockercompose.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682685528/dockercompose_40b41a7b69.png)

⚠️ I ran into problems with haproxy.cfg file. It would cause load balancer container to exit on docker compose execution. After short investigation the error turned out to be a missing line at the end of config. 

This is a command I used for testing the config syntax

```
haproxy -c -f haproxy.cfg
```

I added a missing line with:

```
echo ““ >> haproxy.cfg
```
Another thing to remember is that you need all your images ready, so if you created your own Dockerfile to websocket-app you need to build it where Dockerfile resides like this: 
```
docker build -t [your_image_name] .
```
Now to use your instructions from yaml file and start your containers run
```
docker-compose up
```

It should look something like this in your terminal if everything went fine 🥳

![Screenshot 2023-04-28 at 14.55.46.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682686577/Screenshot_2023_04_28_at_14_55_46_0f7a6c97ec.png)


### Implementing webSocket server in Node.js 🚧


In this project we are using **'websocket'** library to create a ws server in node js. To create connection to redis on port 6379 we will use node redis library. We also need **APP_ID** from **process.env**, remember? That’s passed in docker-compose.yaml and will be different for each node app instance! Also we will keep a list of web socket connections  for sending messages.

![Screenshot 2023-04-30 at 22.34.41.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682891955/Screenshot_2023_04_30_at_22_34_41_a7c5f227d2.png)

We will use **publish subscribe** model in redis. In short publisher will be sending a message to a channel and all the channel’s subscribers will receive it. One important thing. We will need 2 instances of redis client : one for subscriber and one for publisher. 

![Screenshot 2023-04-30 at 23.54.02.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682892030/Screenshot_2023_04_30_at_23_54_02_e28d8c5b75.png)

There are many alternatives to using redis for that purpose. RabbitMQ and Kafka are a dedicated software for handling messages in pub/sub pattern.

First let’’s make subscriber listen to “subscribe” event. On subscription publisher will publish a message to a channel we called “livechat”. Then subscriber subscribes to live chat channel, so when we start app instance it already sends a test message and it gets published.

Now. Whenever message is sent to channel, for each connection in connections array -> and this is how all chat clients get message whenever it’s sent by each server instance.

![Screenshot 2023-04-30 at 23.54.19.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682892107/Screenshot_2023_04_30_at_23_54_19_f090228d5a.png)

We need to create a raw http server that we will then pass to WebSocketServer instance. We also need to listen for incoming messages. 

![Screenshot 2023-04-30 at 23.54.28.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682892144/Screenshot_2023_04_30_at_23_54_28_09a113dd8d.png)

On each new web socket connection request we create a **con**(connection) that on each message will publish to the livechat channel. Then we push this connection to array of connections that then will be used to propagate the messages.

![Screenshot 2023-04-30 at 23.54.34.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682892247/Screenshot_2023_04_30_at_23_54_34_988b6a480c.png)

### Testing our app
Now we can start testing our web socket app scaling. To do that we can open several dev tools in browser. So clear the console and let's begin

![Screenshot 2023-04-28 at 14.46.13.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682685989/Screenshot_2023_04_28_at_14_46_13_0f53e47069.png)

First we initiate ws connection. Notice how we are using ws:// instead of http://. For encrypted connection we would use wss://.
If we go to network tab in dev tools we can track websocket connection and its specific UPDATE headers. Look at GET request status code 101 Switching protocol from http to websocket:

![Screenshot 2023-04-28 at 11.26.06.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682686079/Screenshot_2023_04_28_at_11_26_06_ba075d3959.png)

Now localhost:8080 is proxied to instances of app by Haproxy load balancer. Take a look at the haproxy config file : 

![Screenshot 2023-04-28 at 13.36.07.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682686150/Screenshot_2023_04_28_at_13_36_07_059a935c4c.png)


Notice how it proxies traffic from port 8080 to app instances port 8080. Every time we send a message we will see it in messages tab in dev tools: 

![Screenshot 2023-04-28 at 11.26.32.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682686201/Screenshot_2023_04_28_at_11_26_32_90ef8336f7.png)

Remember how we put APP_ID variable to docker-compose? We did that to identify each instance. So when new connection to ws is established we get this APP_ID printed. So we can now know which client is connected to which server. Even if the server is not the same, meaning that different ws connection is used, each subscriber/conversation user gets messages that are sent by each user! It works as we expected!

Code for this post is available on [my github repo here](https://github.com/stasdudzik/ws-server-lb-redis) ♻️

### Read more 🧽

1. More about pub/sub and brokers pattern in ["Node.js design patterns" book](https://www.nodejsdesignpatterns.com)
2. By the way web sockets also work over HTTP/2  and there connection uses method called CONNECT. HTTP2 is a multiplexing protocol so it can put multiple requests into one connection making it way more efficient in the backend [read more in this spec](https://www.rfc-editor.org/rfc/rfc8441)
3. Remember to checkout this [amazing explainer on load balancers](https://samwho.dev/load-balancing/)

large_Schema.png

medium_Schema.png

small_Schema.png

thumbnail_Schema.png

Schema.png

How to scale a web socket app?

If you came here because you liked Moby Dick inspired cover image - spoiler alert. It's not about whales really, it's about contenerization software called Docker using whale as its mascot. 

Docker became de facto standard used in IT industry in the last decade. It encapsulates code into units called **containers** and allows to run it on any environment. Docker makes development way easier. Setting up dev environment takes just a few commands instead of installing several apps locally that might differ across platforms. Same goes for deployment. Scaling your up (adding more instances) and creating CI/CD pipelines become way simpler.

In teams I worked so far, Docker was already set up so I never actually had the need to figure it out. When some CI pipline errors emerged I had to rely on DevOps’s help to navigate project docker files. It’s good for both frontend and backend devs to know at least the fundamentals. This post aims to introduce Docker by a practical example.

There are three fundamental concepts we need to know ahead 💡

- **Dockerfile** it’s an instruction file that describes how your image should be created. It can be pulled from cloud repository like dockerhub or you can create it from scratch. Check out [Dockerfile docs](https://docs.docker.com/engine/reference/builder/)  
- **Image** is based on dockerfile and its a snapshot of your  software with all of your dependencies
- **Container** we use images to spin up multiple instances of your app

### ABC of a Dockerfile

Dockerfile looks like this:
![Screenshot 2023-04-26 at 18.59.39.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682582799/Screenshot_2023_04_26_at_18_59_39_0236eb8d67.png)

It uses a set of **instructions** (keywords listed in Docker's docs) to build an image that then will be used for running our container 📋

- **FROM** - sets a base docker image - here we are using node v12 available on [dockerhub](https://hub.docker.com/_/node/)
- **WORKDIR** - sets working directory for instructions that follows
- **COPY** - copies new files and directories and adds them to the filesystem of the container at the destination path. It will ignore files included in .dockerignore file similarly to how .gitignores work
- **RUN** - this instruction executes passed commands and the resulting image will be used in the next step. Here we are installing packages residing in package.json using npm 
- **CMD** - used to start our app using script from package.json that runs “node index.js” in our case
- **EXPOSE** - informs Docker that container listens on specified network port, you can also change protocol from default TCP to UDP

### Creating an image 🐳
After our Dockerfile is ready we need to build an image. To do that we run command in directory in which Dockerfile was created:  


```
docker build -t simple_node .
```
To list all existing images we can run command: 


```
docker images
```

![docker_images.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682583370/docker_images_b4811bfb8f.png)

⚠️ Important thing to keep in mind is that every time we run an image we will create a new one and as you can see there are pretty heavy on memory! Images can easily go over 1GB. So make sure you get rid of unused images.

🟢 If an image was successfully built we can run it with this command: 

```
docker run --name nodeapp -p 9999:9999 nodeapp
```
Argument **-p** maps container port to actual machine port so it exposes it to the outside world.
You can also run an image in a **detached** mode (so it doesn't block your terminal) by adding **-d** flag.

To see the list of containers and their statuses run:
```
docker ps -a
```
![docker_ps.png](https://res.cloudinary.com/dpwcguq4o/image/upload/v1682583845/docker_ps_37141820ac.png)

 flag **a** shows all containers instead of only the running ones

🛑 To **stop** or **kill** containers by their **name** or **id** you will find in the output of **docker ps**. In this case i am using container named _nodeapp_
```
docker stop nodeapp
```
The difference is that under the hood docker sends a SIGTERM or SIGKILL signal to terminate the process. Stop allows to finish the process gracefully and kill causes immediate exit that might sometime cause troubles. One other way to stop container is to remove it from local storage by running 
```
docker rm nodeapp
```

You can run multiple instances of your app based on your image on multiple machines, on VPS server or Cloud,  literally anywhere you want. In the next post I will try to containerize rudimentary node.js app and put it behind a load balancer based on haproxy image with a little help from docker-compose which is a tool that simplifies spinning multiple containers with one command.


Apply 💡

Hi, I'm Staszek and I sometimes write about stuff I learned (mostly coding)

Blog

Brace yourself - code kata solution

Automating GitHub workflow

How to scale a web socket app?

Docker cheatsheet