The Stack
I love choosing tech stacks. Ever since I watched that Fireship video on creating tech stacks, I've always wanted to make my own and try building an actual project with that stack. This took a lot more time than I was hoping for. I expected this to just be a quick hour, maybe two type of thing, but it ended up turning into a much larger project. I first started learning React, and then I didn't like React, so I checked out things like Vue. Then Fireship released a video where he liked Svelte, so I went and checked that out and fell in love with it. I've loved Svelte for a long time now, and that's the main technology I decided to build my stack around. But Svelte alone is not enough - as much as I would have loved to roll out a site with just Svelte, I needed a bit more than that, and what better to bring in than something like Astro. Having a preprocessor here for a site is wonderful, especially for a content-driven site like mine. It gives me a lot of flexibility to create something beautiful. I'm not bound to the shackles of one specific framework - if I want to go check out Vue in the future, I can go make some Vue components, or if I want to check out something like Solid or Qwik, I can check that out too without any repercussions on how I would fit that into my site since they're all interoperable with something called Nano stores, I believe. So without further ado, let's get started with revealing my stack.
Requirements
The stack has some pretty simple requirements. One, it needs to be really easy to use. I do not want to have some kind of massive complex thing that has hundreds of files, so that cuts out things like Angular and pretty much cuts out any kind of non-JavaScript framework like Rails or anything along those lines. Next, this is mostly a content-driven site, so I do not want anything bulky or heavy. Its only purpose is to serve blogs and kind of just be a representation of what my current interests are and more of like a journal for what my life is at certain points of my tech journey. Oh, and I also need this to be flexible. I do not want to be locked in to a certain framework or technology, I want to be able to explore and be able to use different kinds of things in my future. And lastly, I want to be blazingly fast. I need to see almost 100s on the performance thing for Google Lighthouse because big numbers make me happy, so I gotta see greens all the way. So with that out of the way, let me introduce what I've picked.
The bits
The stack consists of 3 sections:
- The Frontend
- The Backend
- CI/CD
Each one of these is integral to the functioning of this site, and ill go over my decisions and what led me there.
The Frontend
For the front end framework, I decided to choose Svelte. Svelte has a lot of flexibility in its reactive systems. I like the signals approach and Svelte 5 recently dropped, so that's very interesting to say the least. And along with that, I decided to choose the meta-framework of AstroJS. Astro checks a lot of boxes. Their personal website has hundreds on Google Lighthouse. They are super flexible, so I don't have to stick to one framework - if I don't like Svelte, I can jump over to the Vue world or the Solidjs world or the React world if I wanted to. So it doesn't lock me into a certain kind of technology. Next, it's all JavaScript, so Astro is a language that's built on top of HTML. It's a superset of JavaScript, and Svelte is also a superset of HTML and just regular code. I like the idea of having JavaScript in my HTML. I do not want HTML in my JavaScript, to me that just feels a little weird. I don't really want to have that kind of system where I'm like exporting a string of HTML in a function or however React does it. I just don't feel right doing that. So that's why I decided to choose Svelte - maybe in the future I'll change my mind and actually check out React, but for now we're sticking with AstroJS plus Svelte.
So that's the main big decision out of the way. Time to talk about a little bit of the smaller decisions. I'm not going with any one UI library. I do like the way that Shadcn is doing things, so I want to kind of veer towards those types of libraries - you can just copy paste code into your folders and then just modify it to however you need. And also Tailwind because Tailwind is a no-brainer these days and you should be using Tailwind because it's very nice. But that's all for a future article.
The Backend
The backend is where this stack shines. I chose Pocketbase as my backend. Pocketbase has so many features that I need just for this site specifically. Fireship mentioned something about a SPOCK stack, which I decided to promptly yoink. It was a wonderful decision. Pocketbase is a single container that I can deploy and have up and running immediately. It has an amazing web frontend, it's written in Golang, so it's blazingly fast, and has a really nice JavaScript SDK that isn't too heavy and kind of looks like Prisma. I have loved working with it, even though it uses SQLite and technically SQLite does not scale, but I'm working on a blog so it literally does not matter.
Not only that, it offers some features that I could use in the future. Back to the chess thing - I might be able to hook in some real-time functionality using Pocketbase + Svelte. I'll be able to store the games in my database and then have both clients subscribe to Pocketbase using their realtime features so they can play against my bots. I think that could work, though I haven't tried implementing it yet so it could completely fall apart.
That's half the backend! Pocketbase handles most of the stuff for me. Originally, when I made this site a couple months ago, I was using Astro in SSG mode. I was turning all of my Astro pages into static HTML and serving them out with Nginx. I recently changed that to Node.js + Express.js due to a school project where I'm using Astro, but this time we had to use server-side rendering to expose our own APIs and build something more interactive. Was it the right choice for that school project? Time will tell, I'm not entirely sure.
I'm liking the SSR experience a lot, so I enabled it for this site. It was a bit of work, especially since Svelte 5 came out, so I decided to go ahead and switch over. I ran the Svelte migration tool, which worked pretty well - it only resulted in about two errors which I fixed quickly. Pocketbase stayed the same, but now we're running on Node.js + Express.js as the backend and I can write some fancy Express.js APIs now.
CI/CD
I had never deployed a web site until now, which is a little embarrassing since I've had a homelab for a long time. I don't quite consider the CI/CD part a piece of my tech stack, but I'm going to talk about it here anyway. I have a blog post (which I'll probably link somewhere) that goes more in-depth about the annoyances of trying to set up my own CI/CD pipeline on my own machines.
In the end, we have GitHub Actions to build the Docker image and get it into the GitHub Container Registry so I can pull them down on my own machines. Cloudflare provides their generous tunneling service that lets me expose this application from my home, even without a static IP address. Cloudflare also gives me DDoS protection, so you can't nuke my website. And I guess my Dell PowerEdge R440 is part of the stack too, since it's the machine actually running the website. It's a tank with 64GB of RAM and 16 cores worth of CPU. I got it from eBay for about $200, which I consider an absolute steal. Technically Ubuntu and Proxmox are parts of my stack too, even though most of my stuff runs on top of Docker. But that's just me trying to pad this paragraph out, lol.
This was mostly an excuse to try setting up my own CI/CD pipeline, something I could call my own, because I thought it would make a good learning experience. And it sure did - I learned a lot.
The Most Important Part!
So, coming up with the acronym (the most important part), we have the SPACE tech stack:
- S => Svelte
- P => Pocketbase
- A => Astro
- C => Cloudflare
- E => Express.js
Having all of those together has been wonderful. Did I switch from Nginx to Express just so I can have the E in the SPACE tech stack... Absolutely! BUT!!! I think it was the right choice for what I want to do in the future!