Building vs-battle

Vs-battle is the first side project that I actually ended up releasing. That is if you don't count my Chrome extension InstaSource, which I don't because it was a project that barely took a couple of hours to complete. Vs-battle on the other hand took me a few weekends of coding in my free time and required much more effort in terms of planning.

The idea behind vs-battle

Vs-battle is a simple "battle" game where a user can create said battle with as many "contestants" (options) as they want. When another user plays this battle, the contestants get pitted randomly against one another. When a contestant gets picked, they "win" that round and move on to the next one, while the opponent gets knocked out and does not reappear. This continues until there's only one contestant remaining, and that contestant is crowned the "winner". After the battle is over you get taken to the result screen where you can compare your results against the global average.

A simple concept, really. Just a bit of fun whenever you want your friends or community to rank certain things, with the twist of having to make hard choices instead of making the "perfect" list.

I had played something similar once before on a site a friend had linked in our group chat a year or so ago. Recently I tried to find it because I wanted to make a battle myself, but I could not find it after scrolling for ages, and he didn't remember what the website was either. That is when I decided to just make my own version!

NextJs

If you asked me before vs-battle if I had experience using Next I would've said yes. However, you would have had to take my word for it because I would have had nothing to show for it. Like many other developers, I've started and abandoned an array of side projects. Most of these were developed using Next. It felt great to finally be able to show my experience with Next, which is becoming a more and more desirable skill.

Cloudy day

From the start, I had one goal in mind. I wanted to learn more about CI/CD and the cloud. This is an area I've long seen as one of my weak points. I have had to set up a pipeline or two on Azure previously but did so mostly by following a guide and with some assistance from my colleagues. I'd struggle just as much if I had to do it all over again.

With that goal in mind, I decided to focus on AWS. Here in Norway Azure is the main cloud provider, and .Net is everywhere. That is exactly why I chose AWS. At my current company, we have plenty of consultants who are quite knowledgeable when it comes to Azure and its services. However, the same cannot be said about AWS. So instead of becoming yet another person who can do the same things as just about every backend developer in Norway, I decided to go down the road less traveled. I thought it would be nice to stand out and have a somewhat more niche skillset pertaining to the cloud, especially since I am not primarily a backend or cloud developer.

One of the reasons I had been so confident about choosing AWS is because I had recently heard of the tool sst.dev. In short, SST is a tool that makes it easy to deploy modern full-stack applications on AWS and has a bunch of templates for frameworks such as NextJs, SvelteKit, Astro, SolidJs, and so on.

Using SST was a great experience from a developer's perspective. It abstracts most of the AWS console away from you and lets you set up your stack through code.

The most I had to interact with the AWS console was creating an account and setting up an IAM user.

Too easy

The problem with sst from a learning perspective is the fact that it works too well! I learned how to set up a NextJs site with a custom domain and S3 bucket using sst, but I have no real clue about how I would do this using the AWS console. And while I did get some basic understanding of the AWS console due to my own curiosity and attempts at monitoring costs and trying to figure out what sst had done behind the scenes, I definitely would not consider myself any kind of authority on AWS.

I will definitely use sst on future personal projects as it is a great tool, but I still have the desire to learn more about AWS and its capabilities, and whenever I decide to dive into that topic again, I will be going in without sst.

Shoutout to Railway

I chose not to host my database on AWS. The options didn't seem that great, and the closest to what I wanted was RDS, which after reading up on it seemed to be quite pricey. Surprising considering how reasonable all of these other services such as S3 seem to be.

I ended up hosting my database on railway. Their interface is super easy to understand and get started with. It barely took a few minutes to set up and connect to the database. Since then, vs-battle has had several dozens of battles created and hundreds of battles played, and I've yet to spend a full dollar of the $5 credit that you get when signing up.

Conclusion

While I did not feel like I achieved one of my main goals, which was becoming somewhat proficient in AWS, I did learn a lot by developing this project. Most projects get dropped at the final stretch, when there's only the "boring" stuff left. But there's still a lot to learn here, like for example how to set up a proper CI/CD pipeline. While I have launched several products before through my job, I still feel like I learned a lot just by pushing myself to finish this project and use services that I was unfamiliar with.

If you found this article interesting, do consider giving vs-battle a try! It's always great to see new battles pop up from time to time! 😁