Rendering React components/pages on the server-side is not a new topic, there are a lot of frameworks / libraries built specificly for this purpose. In fact, too many that it makes me very confused, what I want is a really simple way to just render the React page and also re-use the same routes. So, after looking into several popular solutions, I decided to just roll my custom setup with vitejs which is something I have been using at work for several months.

Yeah, it’s a new year and it’s time for a new setup! I have been using docker swarm as my personal cluster for the past year. As I’m exposed to kubernetes more and more in my job, I just thought that maybe it’s time for me to actually do something with kubernetes in my free time to learn more about it. Besides, having knowledge about kubernetes benefits me in many ways considering how popular kubernetes has become.

In this blog post, I’m going to describe how I set up my personal cluster using k3s (a Lightweight kubernetes distribution) and rewrite the CI/CD pipeline to deploy to the new cluster instead of the old docker swarm cluster.

What the heck is a dev proxy? To clarify, it’s a term that I’m not sure if I use it correctly, but to my understanding, a dev proxy is simply… a reverse proxy used solely for development purposes.

But why do we need one? As microservices become more and more common (I wanted to say popular but it’s highly opinionated), the need to run multiple services locally while developing a project is more necessary than before. And one of the problems is port conflict, a common convention I usually see with microservices is to use almost identical setup. This means that the port they are using is likely the same port. And microservices usually come hand in hand with docker and obviously you can’t bind the same port twice (even if you don’t use docker I don’t think you can run 2 processes listening in the same ip:port)

A dev proxy is a simple solution to mitigate this problem and makes it more enjoyable to work with microservices. In this blog post, I’m gonna describe my process of setting up a local dev proxy so that I can run multiple services without worrying about their port.

Just few days ago, I accidentally messed up my Ubuntu workstation, it was a silly mistake. It’s lucky that I have a setup script to install everything. But it was messy, hard to maintain, and full of litte tricks to check if file exists or if the file has a particular line of text so that I don’t append the same configuration value twice. Since I’m learning Ansible, I decided to “rewrite” that horrible bash script as an Ansible’s playbook so that the next time when I mess up (and I will), I can have something more reliable to use.

In the previous part, I’ve shown how to set up a simple swarm cluster with 1 master and 2 worker nodes. In this part, I’m gonna continue with how to configure it to work with gitlab and also achieve zero downtime deployment.

Being able to develop an application of any kind and automatically deploy it is the norm nowadays. I have been using dokku in my personal deployment stack for several years now. And at work, we are using Kubernetes. I love the idea of Kubernetes but wanted to try something else, and came across docker swarm mode. In this blog post series, I’m gonna describe the process of setting up a docker swarm cluster, putting traefik in front as a reverse proxy and automatically deploying via gitlab without downtime.

As a total beginner to Golang I find struct tags a very interesting idea. With tags, I can separate the data structure from the meta data used by other parties. It’s similar to how HTML and CSS are separated by class names. While doing my side project, I implemented a package to parse HTML content similar to how the native XML parser works. This blog post summarizes the process. I will assume that if you read this you probably have used struct tags before, and have a basic understanding about them.

I stumbled upon a weird bug few days ago when I needed to implement a function that will gracefully fail instead of throwing an error. I thought it was as simple as try the function and catch the error, then return something else. Apparently, with async, things got a bit confusing.

We have recently updated to React 16.8 after more than 1 year stuck with the old version. The process was surprisingly pleasant, in fact, I accidentally updated our React version to 16.8 and we didn’t notice it for 1 week, nothing broken as we have gradually got rid of all the legacy stuff. Now that we have updated to 16.8, the fun officially begins. I have been a regular guest in the refactory hotel recently and I decided to write down some interesting cases I have encountered during my journey.

Last week, I was lucky to be able to give a talk at HelsinkiJS. The presentation was rather long compared to other because it introduces the type system as well as Flow. In this blog post I’m gonna summarize my presentation.