How this blog is built technically, and the future of blogs

The thinking process, why not WordPress, and why strapi

I was thinking a lot about building this blog and what technologies to use. But unfortunately, being a developer only made me neurotic about this choice.

WordPress has been a de-facto blogging platform since early 2004. It has its power mainly because it allowed the development of a new website with very little professional knowledge.


Google trends for "wordpress" between 2004 and the start of 2022

However, that same developer-friendliness that brought all the glory acts as a two-edged sword. Why? Because oday we have more experienced developers, more available knowledge, and more experience with software as a community. Thus we need:

Systems for smart developers over smart systems.

Experienced developers usually stay away from platforms where everyone can "stitch a paster" instead of writing a solid solution. We avoid such platforms (WordPress included) because, first, we're not as needed. And second, the platform, since of it's over extensible nature, is more exposed to bugs when non developers plug and play with extensions.

That's why experienced developers find themselves not working with marketing teams. It's all just to avoid the hustle of working with WordPress!

But still, WordPress is the dominant power today. About tomorrow I'm not so sure. How will WordPress disappear? Today we can combine any CMS with any front-end framework to make a fun developer experience and a maintainable code base. Gradually, more and more developers will propose to their clients to use better front ends. As a result, WordPress will slowly decouple the front end, but how about the CMS? We have other alternatives developer-friendly such as strapi.

And strapi is just what I've chosen to work with; Strapi and next.js. The rest of this article describes my choices along the way and a few implementation details.

How I chose technologies for this blog, and why them

I make my development decisions data-driven. So to share my choices, I'll mostly just share links and images of data.

Choosing Strapi as a CMS was pretty easy, I started with based on a recommendation I saw on fireship, but it was not mature enough. So after searching google a bit I came to see this:

headless cms.png

In this result, sanity is only in ~10th place based on hithub start count.

I know that Ghost serves as both the front and back end, and I want to control the front end so I can make the best experience if I chose to. And I know that netlify is a closed system. So I'm left with Strapi!

Setting up strapi was painful, took a lot more effort than what I've expected.

Basic and functional strapi and next.js setup

Here's a short summary of my setup:

  1. Heroku - an easy (and free) store for both the node and Postgres.
  2. SendGrid - easily integrated with my strapi app in less than 5 minutes.
  3. Cloudinary - since Heroku doesn't have a consistent media asset store, we need to use another service. You can set it up with Heroku or with strapi. Connecting strapi with Cloudinary is also a five-minute setup, so this was my go-to solution.
  4. Cloudflare for dns routing
  5. AWS RDS for a simple database (you might as well use heroku...)

For the front end, I used next.js and hosted it on vercel. Vercel is a funded comapny and gives an excellent service focused on next.js, so it's the obvious choice. Why not gatsby? Gatsby is excellent, and I do use it in other projects. However, this one might be more dynamic with time, so next.js could be more useful someday.


My next steps and things I'm considering to change in this setup:

  1. Using filesystem markdown files for keeping the blog posts. Strapi feels like a bit too much sometimes.
  2. If staying with strapi however, then use EC2 instead of heroku

Thanks for reading; if you're looking to upgrade your marketing tech stack, get in touch, I give consulting and services for large marketing teams.

Posted 3 months ago by Adam Genshaft at 10:56 on 15/03/2022