So part of me realized something in setting up a blog.
I've been a web developer professionally for 17 years. I've never written 1 blog article about my profession and at most is a buried live journal account with the cringe poetry of a teenager.
I've never written a blog.
I realized this quickly within the first two posts. I thought "I'm pretty good at stream of conscience writing and when I journal I can belt out 1500 words easy". Except that's just for me. That's my voice, going over personal issues that don't need a necessarily A to B coherent path. It doesn't need a structure or a goal, I'm just writing to write.
So in the last post I ended with the following words:
I got the instance up, it was late. Slept on it.
I got stuck the following day. I had set up Strapi Cloud to pull from my own repo. My intention from the get go of this project was to work through some rust I had because of a concentration of WordPress projects. I wanted to solve SSR dev issues by utilizing localized Strapi to serve data ASAP. However because of the nature of running a local instance vs having a cloud based deployment that was technically live 24/7 (more on this later) I ran into an issue with my headers being sent through fetch() to grab my data.
After what I can only call a frustrating amount of time did I figure out my issue. I was juggling two separate environments and their relative keys. I wanted to utilize Astro's import.meta.env.SECRET_${variable} for security reasons. So in my haste, I was trying to access my localized strapi instance with my cloud API key.
my bad
The following days after that was a lot of rapid UX development motivated by finding a few design concepts by mistake and running with them. I did a lot of iteration on how the components were built. I improved the blog readability page by allowing the text to not be the same color as the background. And that "technically live" dynamic for Strapi Cloud came into play.
As I was improving my UX (cough readability), I started getting a little frustrated at the wait times from free cloud hosting. The $0 tier has a line for "Cold Start/Start from Zero Deployment" of my instance.
For the longest time I always dismissed this as relatively minor. I didn't have a personal need for hosting, as the clients at my previous job were all paying for hosting with cloud providers that we had full access to. And as I said earlier, I've never really written a blog.
Part of my solution was to pick and choose which pieces needed to be Server Rendered vs Client Rendered. I figured if I only had the blog cards/list be statically generated, I could then render individual blog posts on the server and then send them over when the client requested them.
But, cold start means that my Time to First Byte (ttfb) and LCP times were heavily impacted. I spent about a day trying to sus that out for myself. Weighing whether or not I wanted to just start paying a monthly fee for an actual live 24/7 instance.
But then I remembered the whole point of this was for Astro
I immediately started moving everything over to Static Site Generation (SSG). Blog list/cards, article pages. tbh it was a short list of To-Do's but it was fun. I think the content collection framework that Astro pushes forward is a really solid way to handle gathering data from any number of sources. Whether they're locally saved *.md files (which was my original concept last site iteration), or using Astro's implementation of fetch() from a remote source it's nice that I can just set up ./src/content.config.ts and set those collections up manually for full control over the data flow.
Now I have a new problem!
Build time vs runtime! Because of the static nature of the blog, everything must be built prior to access. This has always been a funny concept to me because of the fact that I haven't written a blog. I know thats pretty... far fetched, but hear me out.
Back in my day
Making a website to be hosted on geocities required FTP access. It required an account with a web host and then an FTP client to send files. The first website I wrote was a Dragon Ball Z info/wiki dump where I compiled every bit of information I could find about the anime. I even used two iframes opposing each other to simulate goku and vegeta shooting beams at each other (sadly, I don't have the URL).
This was a SSG deployment.
I'd write text into .html files and then when I uploaded them the site would be updated. There was no way for me to dynamically edit content (I was 13), I hadn't yet gotten into server side languages and dHTML/javascript was "new".
When I finally graduated from college and landed my first job as a developer, WordPress and PHP were already well established. My job was training me in ColdFusion. My knees worked. These sites were/are SSR.
Build time vs runtime
This was a dichotomy I never thought I'd have to dissect as much as I do in 2026. When I made my Dragon Ball Z website, I uploaded saved .html files to geocities and accessing the URL would display those pages. When I worked in the yachting industry I learned how to write modular components for managing authentication while also seeing how load times could impact the display of a dashboard for an end user. To me there was a natural progression from one to the next, PHP was always fast enough to serve most of our clients, while ColdFusion would handle any that needed higher scale performance and feature set.
The interesting part is how since the early 2000's and now, the two use cases are still in lock-step with each other (imo). A personal website that will most likely rarely change does not need the overhead of an all inclusive CMS. A dashboard that allows a user to log in to upload their resume information needs to be planned.
The major difference between then and now has to do with modern architecture. Despite choosing SSG, its not as simple as uploading a .html file and then going to a URL. The site has to be built. I'm an engineer at heart and I built this site with strict type checking in mind. The /dist/ files that get output are compiled in a way that make sense to the browser not human eyes.
Because of that, this blog article has been written and edited multiple times over several days. It's not yet actually hit the home page because I haven't written the automation build hooks for the strapi implementation. It's not something I planned for because I have never written a blog article. The whole point of my career has been more about the engineering and bug fixing. Maintenance and standards. Not content generation and curation.
I guess now I gotta figure out how to write a blog.
I'll sleep on it.