The Development of the Monolith Platform: An exploration of Free Tiers | Vivek Raman

The Development of the Monolith Platform: An exploration of Free Tiers

23 July 2024
-- mins to read

A Preface

I set out with a seemingly innocuous goal: host everything for no cost. Achieving this proved to be far from straightforward, unfortunately. This write-up will contain the entire journey I went through, with all of the ups and downs, the abandoned ideas, pains, delays, and more. However, for those of you who reach this place hoping to replicate my setup, head to the project write-up.
There's two parts to this story, the frontend and the backend. Each of these had their own sets of unique challenges and issues, and their integration brought a whole other set of issues. I discovered severe but intentional limitations imposed by many cloud compute / hosting providers, and I'll share everything I learned in the process.

The Frontend

First Iteration

When I first decided to build a portfolio website, I had no knowledge in frontend development. I didn't know what static sites, SPA, SSR, or PWAs meant. I figured that React was popular and is probably going to be worth the effort to learn. And so I created this abomination / masterpiece. Having learnt the hard way what "routing" is, I gave up on React and went on to make some games.
I got another chance to learn web development at my internship, where I got to learn and work with Vue. However, I knew by now that I would need something more than GitHub Pages to host a web app built on a JavaScript framework.

Second Iteration

Around this time, roughly 3 years ago, Fireship.io released this video on Svelte, and I was instantly hooked.
I decided to take the plunge to learn and build something using Svelte, and that was Lineup Lookup. Seeing how easy it was to set up Netlify to deploy seamlessly on every commit, took the stress of deployment and infrastructure away.
I then learnt about SvelteKit, which supported SSR and a more robust developer experience, so I gave that a try. There were a lot of issues during the early days, while the architecture and design of SvelteKit was still formative. Every time I updated the project, the routing paradigm was different and the entire project would require migration.
It's safe to say that things have stabilized now. This website is configured to directly pull the version tagged next, and I haven't faced any breaking changes so far.
Anyway, I picked SvelteKit for this website, and I haven't had a single regret. It's convenient, intuitive, and adequately flexible for my needs. It felt like a no-brainer to deploy the site on Vercel; it had a simple adapter that handled basically everything. At this stage, there was no real requirement for a backend / API as such, so I simply hosted the frontend on Vercel.

Today

The website is still written in SvelteKit, but I've switched from serverless to using a Node server. I've also containerized the server, and the Docker images are stored on GitHub packages. The code is currently private, but I might make it public later. Along with the backend, the site runs via docker-compose, on an Oracle Cloud Infrastructure VM. I've elaborated the current setup below.

The Backend

First Iteration - Heroku

My first requirement for a backend server started with Terrarium. This was a Java 8 - Spring Boot 2 web server that was hosted on Heroku, back when they had an amazing free tier. This, obviously, went down after Heroku stopped offering their free tier. I was too lazy to update the Terrarium application to point to any new host, so I didn't bother bringing the Terrarium backend up.

Second Iteration - Google Compute Engine

Years later, I decided that it would be a good idea to set up a backend server so I can build server logic for any future project. This is where the idea of building a monolith for all backends came up. And so, I set up a multi-module Spring Boot application, where for every new project, a new module could be created, which would have its own config, connectors, controllers, services, and more.
Very quickly, I ran into an issue. Obviously, I needed to host this server somewhere. I looked at options on Google Cloud Platform, as that was the cloud provider that I had experience with, from work. I didn't want to spend a penny on this if I could help it, and so I looked for feasible options in the GCP Always Free Tier. Here, I discovered 2 feasible options: Google App Engine and Google Compute Engine.
After a lot of experimentation, I figured out that if I were to use Google Compute Engine, I'd have to write my own deployment pipeline. Additionally, exposing the server to the web on a static IP wasn't going to be straightforward. I was instructed to use the API Gateway to expose the server on the VM, but there was no provision for usage of API Gateway in the free tier. I felt that this dead-end might have been intentionally crafted to limit the usability of the free tier. Either way, it was a dead-end, for sure.
Gateway is not free, so requests cannot be served

Third Iteration - Google App Engine

The next option was Google App Engine. Here, I ran into a lot of roadblocks trying to bring the server up. It took me a week to understand that App Engine is a serverless platform.