Recent dev notes

This stretch was spent creating my own CMS. That's not how I intended the last 10 days to go, but here we are.

I started out just having a little fun while learning something new for the sake of learning something new. Most technical decisions were made not for their ability to solve a problem, but for their cool factor. I was making the choices that felt fun.

In a professional setting, that'd be a sin. But I'm here for the vibes.

Let's recap how I got here.

Move to a CMS for the funsies.

I've mentioned before that I was intending to move this blog to a proper CMS so I could be a true blogging grown up. The main reason was to have something that would force me to dive deeper into Astro's content API, which I've been impressed with. On your side projects it's totally fine to choose technologies solely because they'd be cool to build with.

But I did have some real problems to solve, even though they were small. It felt amateur to mix my regular git commits with commits that were just to publish a post. I also frequently rewrite this site to use a vastly different tech stack. (I'm usually testing a new technology and want a real app to use it with.) Every time, I have to move all my markdown files to the right spot for whatever new framework I'm using and then tweak them to match whatever format the new framework is expecting.

None of these are game changers that justify moving to a CMS, but they weren't nothing.

Ultimately though, I wanted to move to a CMS because I've never used one as an author. I'm usually building things on top of an existing CMS to display the content in various applications. So this was mainly to have fun with a CMS.

Move to Strapi for the community vibes.

After deciding on using a CMS, I then had to figure out which CMS to use.

Since I was doing this for the sake of learning, I originally thought I should be using Wordpress. It's the most popular CMS and the one I'm most likely to encounter in the wild, so my fun-time learning would translate to professional learning. But Wordpress just felt so overkill for my simple little blog. I'm just writing markdown and that's it. All those plugins and themes aren't particularly appealing for my boring use case.

This sparked a rabbit hole of other CMS alternatives.

• Sanity: I've encountered this in the wild. A company was effectively using it for everything, including their de facto database. It was an interesting choice¹. Despite my first real introduction to it being an example of how not to use Sanity, I can still see the benefits of having that much control of your schema.
• Ghost: I've actually used the "head" version ² of this during a short stint where I was creating a jseverywhere.dev newsletter. I wasn't a fan of the writer experience since it was more focused on blocks than markdown by default. But the idea of getting a newsletter again for free was appealing.
• TinaCMS: This one piqued my interest since it gives an UI to what was effectively my previous workflow - committing markdown files to a git repository.
• Decap CMS: This was another markdown-in-a-repository option, with an admin UI that's not as preview-focused as Tina.
• Strapi: Breaks away from the git-focused options and built a little more around schemas (a la Sanity).

Since I was making technical decision based on funsies, I ended up with Strapi solely because I thought Paul Bratslavsky's strapi-community-astro-loader was cool. I've met Paul at various local Austin meetups and I liked the idea of contributing to a project he was maintaining. (I'm going to continue contributing, because I still think it's a cool project.) All the CMS options seemed marginally different so I just chose the one that peaked my open-source contributor mindset.

Not the way to make decisions on real projects, but that's not what I was going for.

Reality check

I used Strapi for a bit and had a whole branch dedicated to it that I was ready to push, but the real world hit me fairly quick. I was using nearly nothing Strapi-specific. There's a lot you can do with custom blocks and fields in Strapi, and I was just using a standard rich-text field since it was effectively markdown. It felt like I had built a Swiss Army knife but only ever used the bottle opener. The writing experience also felt a bit off simply because I was writing markdown in a rich-text widget in the browser. It was fine, but it became obvious that a markdown-first tool is what I wanted deep down.

After a while, I had to stop chasing vibes and ask myself the classic Principal Engineer question: What problem are you solving again?

The answer:

Based on my love of markdown, I need a markdown editor that saves my content to the cloud so I can easily pull it down later in a SSG.

With the problem stated more directly, I could therotically improve on my previous workflow with a CMS, but it's not giving the proper weight to main part of the problem statement: the markdown editor. If I was approaching this with a little less just-give-me-vibes gusto, I likely would've started with the editor.

But now that I was here, what are the options?

• HackMD: This is Google Docs but with markdown and a heavy emphasis on collaborating on documentation.
• Obsidian: A slick local markdown editor that I've used in the past. You can get the cloud sync either by paying for it or via plugins.
• Inkdrop: A slick cloud-synced markdown editor with an emphasis on note taking, and thus a heavy emphasis on the markdown writing experience.

Each one of these instantly felt better to use. Each one had their quirks, but each of them just felt right because they were markdown-first experiences. It's obvious in hindsight³, but I don't even think I realized how big of a difference it would make. WebStorm was getting the job done, but it's built more for codebases that happen to have a README.md in it.

Inkdrop became the obvious choice for me. I do think it's markdown editing experience is marginally better than those others, but the seemless cloud-syncing was the real gem.⁴

Turn Inkdrop into a CMS, for the funsies.

Admittedly, I was feeling a little disappointed because I didn't embark on this journey to solve a tangible problem with my workflow, but to do something fun. I'll add a CMS to this bad boy. That'll keep me occupied for a week or two and I'll learn something. Not sure what, but I'll learn something.

But then some dots started connecting that led me to my do-something-fun-not-productive goal. Let's revisit my restated problem.

Based on my love of markdown, I need a markdown editor that saves my content to the cloud so I can easily pull it down later in a SSG.**

That last bit became the next question to answer. Can I pull my content out of Inkdrop easily? The answer became yes and no.

Inkdrop does have a HTTP API, but it's not really for this kind of job. It's meant more for plugins to the editor itself. It achieves its syncing features by provides a sync server. However, you can bring your own since it's just a CouchDB instance. Give Inkdrop the URL to your own CouchDB instance and it'll sync to that instead. Then you'll have complete control of your content. Easy peasy.

Here is a summary of the resulting inner monologue upon reading about Inkdrop's sync server.

• If it's my CouchDB instance, I could pull the content out of it as part of my Astro build.
• But, I know very little about CouchDB other than its NoSQL. How do you deploy one of these things? How do you even query this thing?
• Rolling my own instance of a new database technology seems overkill. I'd effectively be building my own little CouchDB-backed CMS.
• Build my own CMS? Wait ... that sounds kind of fun. A little dumb ... but fun.⁵

And that was the eureka moment. Instead of using an existing CMS, I would shoehorn my own by building an Astro loader on top of Inkdrop's existing syncing logic. Is that a productive decision? Absolutely not.

But sometimes you've got to shed all those productivity instincts that have been honed by decades of being a good little worker bee at Corporate Software, Inc. and build something as simple as a blog on top of some technology you've never used that's filled with someone else's schema that is in no way architected to promote your crazy little use case just so you can feel alive.⁶

Conclusion

All-in-all, I'm actually quite pleased with my Silly Little CMS™ and I learned quite a bit in the process.

CouchDB's views are pretty cool because they aren't really views, at least not in the standard relational-database since. They're JavaScript mapping functions that you build based on whatever logic you want/need. Inkdrop's views are obviously built for their own use cases and I didn't want to make changes to the DB itself and accidentally break Inkdrop's syncing.

But CouchDB's \_changes API is also cool. It makes using your database in an event-driven architecture simple and the way Astro's content layer caches, it actually behooves you to think in terms of events (i.e. tell Astro about all the content that's changed since the last build).

So I now have an Astro loader that reads the changes from my own CouchDB instance and updates the build cache with the latest edition of my posts. And you're totally jealous.

I'm writing this in Inkdrop right now and it's been a pleasant authoring experience, even though this post has become super long.⁷ Using the Inkdrop editor as a CMS is clearly not the intention⁸, but I can round any rough edges by building my own plugin.

Is building custom plugins into my blog editor when I blog maybe once every other week a bit much? For sure. But it'll be fun.