Recent dev notes

Astro SSR content collections

The Astro v5 content layer is proving to be awesome. I use it to pull my bookmarks from Raindrop. This is a build-time solution, meaning changes in content require a new build to show up. This is fine for a lot of content, but for the content that updates often, then this isn’t the right tool. (I would consider the fact that this content might actually be data, but that’s a grey area that’s a whole different can of worms.)

For my bookmark use case, I update them pretty infrequently, so the classic strategy of using a web hook to trigger a build when there’s an update would suffice. However, Raindrop doesn’t have a hook. I update bookmarks so infrequently though that I could just brute force having a build run every day and it’ll be fine.

But, driven by cat-killing curiosity, I dove deeper into Astro’s content layer for the sake of learning more.

I started cooking up what I’d want in a SSR-styled content layer, which would get you some more real-time responses. I had a loose idea of the same API as the SSG content loaders so the fetch logic is contained, but with some caching of the results. Astro’s data layer already has build-time caching built in, but this would likely have to leverage SWR in a way that the loader honors.

And then of course, those Barry White drums started kicking and Nas started rapping.

No idea’s original. There’s nothing new under the sun.

~ Nas

Yea, Astro already thought of this.

The combination of the Live Loaders and Route caching proposals on the roadmap effectively gives you that utopia I was thinking.

Awesome.

CMS debates

I’m typing this blog post directly into a markdown file checked into my repo and Astro will render that on the next build. Gets the job done.

I kind of like the writing experience of just opening up a .md file. I don’t think it’s a very popular style of writing though. I couldn’t tell a marketing copywriter “Just push your markdown to the main branch and you’ll be fine.”

I had that thought earlier this week and realized my CMS experience is limited to using its APIs and rendering its content. But I never authored in one since I’m always just pushing markdown files. The one in-depth experience I’ve had in the authoring side of a CMS (Sanity, specifically) was largely focused on trying to help the company understand that a CMS is not a database. Meaning it wasn’t the most productive experience.

So the latest project added to my never-ending project list is to move this blog to a true CMS.

I opted for Strapi, but it feels weird since I genuinely like writing in markdown files. I’m not using any of Strapi’s dynamic zone functionality, which makes me think I shouldn’t be using Strapi at all.

If you just want to write markdown in a file and you’re comfortable with git, is there a benefit to using a CMS? We’ll see.

New ideas and maybe-laters

• Discovered Paul Bratslavsky’s strapi-community-astro-loader, which makes Astro + Strapi a simple exercise in the process of working through the above. Currently working on helping the integration even tighter.
• I’m curious if there’s a simple way for auto-creating Astro + Strapi webhook and preview routes. I remember a while back when I was investigating auth-astro (Astro + Auth.js) that it had a clever pattern for creating all the routes needed. I’m envisioning something similar for these routes.