Engineering decisions

Programming languages

Originally, the project was written in python, and Python isn't necessarily RAM intensive , but gunicorn is. Not really, but in the low-resouce environment that I am, every MB of RAM matters, and that was decisive in my need to rewrite to Rust. The language seemed new, fascinating and hot to me with all that it promises:

Very early in development I could not for the life of me ship it in Python because of gunicorn, and when I shipped the prototype in Rust it worked. Simple as that.

Database

Postgres is the deal when it comes to DBs. It is the default option when it comes to most situations in lower scale projects, it can do the job of other technologies, such as redis. Easiest decision of my life.

Operating system (prod and dev)

I have migrated from Windows to Fedora Linux in dev so long ago, and I have been enjoying it thoroughly ever since. No particular reason, no particular hatred for the WindowsOS but once one puts the hat on, I feel safe to say I don't want to go back.

In prod, initially it was RHEL because I was always curious about it, but after experimenting with it and realising it's just that, a really stable OS, that I changed my EC2 instance to Amazon Linux for cost cutting reasons since the magic behind using RHEL faded. Amazon Linux which... also happens to be RPM-based so it's not like I am that out of my comfort zone, anyway.

Client Side Rendering (subject to change)

This isn't a minor decision because there's a whole story behind it. In the early stages, I remember being electric about this Rust framework which promised to be faster and more efficient than JavaScript itself, at the time I was salivating to making my website as JavaScript-free as possible. The framework I'm talking about is called leptos; it compiles directly into Web Assembly and that was super attractive to me.

The problem was when I faced reality, I realised the thing (at least when I tried it) wasn't minifying, fingerprinting, merging the static assets, and that was such a huge turn off for me that I left CSR entirely.

I have been dabbling with TypeScript and React because my understanding is that it is an industry standard and the difference felt night and day: cache busting, filer merging, minification, everything and I didn't even have to whine. My main problem with CSR as it currently stands is that

SQLx or SeaORM

As of now, the application is small enough that it just doesn't justify an ORM. There aren't enough entities, there isn't enough complexity to justify it. The overhead doesn't bother me

Continuous Integration, Continuous Deployment (CI/CD)

My original choice of CI/CD was Woodpecker CI coming from my obsession to have it as lean and mean as possible. In order to do that madness, not wanting to pay for another server instance, I was using my laptop with a woodpecker-agent and woodpecker-server, using Cloudfare to tunnel it to my laptop, but for some reason the both daemons weren't working. They needed babysitting that I just ran out of gas and I stopped paying attention. I have been meaning to experiment with GH Actions, but to be very honest with you, this project doesn't need CI/CD. The development is slow, and I can compile it in ARM/x86 and send it to prod, it's not like it's going to be the end of the world. Eventually, I will return and setup GH Actions, but it's a low priority for me.

Minor decisions