G'day mates,
While building side projects can make us a bit busy after work, I still think that any software engineer should build something at home because we can learn from what we build, we're free to try new technologies, and we can get some real experience while we're getting our hands dirty. Two years ago, I've built a side project, it's a temporary/disposable email service, something similar to "temp-mail", "mailinator", or "10 Minute Mail", which allows you to receive and read emails directly from the website without bombarding your inbox with spam. It's been running persistently for the last nearly 2 years and serving countless users every day.
Recently, the side project gets more users, and it motivates me to spend some time during my public holiday developing it to fix some bugs and add new features. It's been a while since the last update. Let's check out something I've recently done below.
Zero-downtime deployment and load-balancing with PM2 cluster mode
In fact, the web app doesn't have a steady amount of CCU that can be much varied depending on time. And since it's a side project, I don't need to overcomplicate it with containerization and orchestration. Zero-downtime deployment can deliver a better UX and SEO score, so PM2 (pm2.keymetrics.io) running on a self-managed VPS is still a good choice. I often make new deployments to deliver new changes to the production and I don't expect any interruption on the users' end during the process. PM2 is easy to use, and it has well-maintained docs, but it might have a steep learning curve to go advanced. In the nutshell, PM2 will reload our clusters one by one, so there are always available clusters for users to be routed to during the deployment. PM2 also has a built-in load-balancer that provides networked Node.js applications (http(s)/tcp/udp server) to be scaled across all CPUs available, without any code modifications.
Redis as the single source of truth for Apollo GraphQL PubSub
I've been using Apollo GraphQL PubSub to publish the notifications to subscribed users once there are new emails coming to the inbox that they're on. After switching to PM2 multi-clusters for grateful zero-downtime deployments, I realized that notifications seem broken because the cluster which receives the incoming emails might be different from the cluster which is serving the user who's expecting the emails, they're not synchronizing with each other. Luckily, I found a great article from apollographql.com which mentioned npmjs.com/package/graphql-redis-subscriptions, a node package that uses a Redis instance as a centralized store to keep the messages to be published that all clusters should refer to, and here is the link to the article apollographql.com/blog/backend/subscription..
Auto-scaling in the TODO list
When the project gets more traffic (I hope so 😍) and there is some peak in the CCU, I might need to think about moving the infrastructures to the cloud for better auto-scaling up and out, in this case, it's AWS. I've learned some fundamental stuff and this would be a good opportunity to gain some hands-on AWS experiences.
Conclusion
Finally, I still believe that developing side projects is exciting because it allows us to learn more and do more things that we would not have the opportunity to do in our regular jobs.