So I mentioned in the previous devlog that I would make a detailed architecture post; well that just got a whole lot simpler!

The initial architecture

The initial architecture was created using better-t-stack which is an amazing tool to kickstart a js monorepo. The problem with this approach is that you now have a bunch of dependencies that need to be bundled correctly (which better-t-stack already sets up) and - in my usecase - containerized to have the smallest image size.

Then came the biggest issues: mails & scheduled jobs. Don't get me wrong, there are solutions for both in Javascript ecosystem (React Email, bullmq, pgboss and more come to mind) but I felt it would add another layer of complexity the app could probably do without. So the question now became; should I just move the api layer to something like AdonisJS to have a more batteries included setup and where I could easily

The new architecture

Turns out I know of a framework that has scheduling, mails, queued jobs and more out of the box: Laravel. And I can kind of keep most of my frontend code by using it with Inertia. It's not a 1:1 port by any means, though. I lose out on better-auth and orpc, having to rely on Laravel's auth system and on making the calls typesafe in another way - by using spatie/laravel-data to generate types from my DTOs.

The new deployment strategy

Before, I had multiple docker images that I needed to maintain:

• a helper that ran the migrations if/when there was something new

• the actual server image

Each of these images needed to have different packages copied inside them for the build step and it was kind of messy - though still manageable.

Now this is not yet finalized, but I think I might be able to either have:

• a single image with different start commands in a docker-compose stack

• a single image and container with more services defined inside some s6 services

Anyway I'll keep you updated when all of this is finished :)