Bye Ghost, bye WordPress, hi Strapi, hi Gatsby

My plans for my future changes. Ghost and WordPress will be replaced by Strapi and GatsbyJS. This article is the foreword to a new series. In the upcoming series, I will set up an environment with Strapi, import data from my blog, run GatsbyJS in Azure, maintain and deploy my projects via DevOps. In this article I present this project.

Why bye bye?

I actually find both systems very good for blogging. The way both systems are built, a blog, website, news portal, etc. can be set up pretty quickly with them. I can recommend both systems to anyone, personally I like Ghost better as I find it much less overloaded. Also when blogging with both platforms, I liked Ghost’s simpler structure more. WordPress, on the other hand, offers many more extension options.

I want more… I want more control over the data model, I want more than just Pages and Posts, I want to be more of a developer/maker, I want more frustration but also more sense of achievement. All that I want, all that remains denied to me with these two good products. The initial euphoria about self-hosting has long since passed. I need more action… ok a big portion of “I’m doing this because I can” is of course also involved :)

The Project

The bye bye part reads very stereotypical but is only half the truth. Here follows the other half.

Currently I run two blogs - this one here and then ak8s. Last year I familiarized myself with Kubernetes, so I wrote and published most of the articles first on WordPress - on ak8s. With the first articles, I still manually transferred the content to this blog. Later came the automated “copying” first with Zapier and then later with n8n - both workflow engines, the latter I host myself.

As you can see, I always have the effort to copy from ak8s.de to aytac.kirmizi.online. With new articles the problem is smaller, but if there are changes in the original… yes, then the misery starts.

Now it is so that I want to further split my content and host in different (further) domains. Once ak8s - which I will rename to “another kubernetes blog” - then a new blog, which will practically inherit this one, then another blog/website for Microsoft 365. Oh, then there would still be this domain - that will be my business card on the net including all my projects, that is my CV if you want to call it that.

So that would be 3 websites on which content/articles are published. I will also have to duplicate content here, the effort in this regard in one direction with only 2 websites was already bad, the new scenario is the quadratic exacerbation.

Then there would be the already mentioned projects, meaning the portfolio of what I’ve done. That’s quite a lot - with the current systems I would have to tediously write “text” or maintain somewhere a txt with bullet points for the tasks.

Ok, what now?

I’m diving into the glamorous world of JAMStack, Headless CMS, DevOps, and Static Site Generators. So many buzzwords at once, you first have to digest that.

What is a JamStack?

JavaScript, APIs and Markup - that’s what JAMStack stands for. Actually, there’s much more behind this term than just the acronym. JAMStack actually defines just about everything from content maintenance to the development flow to automated deployment via a workflow, e.g. DevOps.

The Jamstack is not about specific technologies. It’s a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.

Here’s a quote from jamstack.org.

In my case, my future JAMStack will be built on all the other buzzwords - Headless CMS, DevOps, and Static Site Generators - from further up.

My JAMStack should be operated as cheaply as possible with maximum advantages.

Headless CMS

Headless CMS is now an old term and stands for the decoupling of front and back end. Meanwhile, “full CMS” like WordPress and Ghost also write this property on their chest. Theoretically I could use one of my already beloved CMS systems for 3/4 of my project, however the problem with the planned portfolio page would still exist - what do I do with the projects?

Thank goodness there are already several Headless CMS systems that meet my requirements: prismic, squidex, directus, contentful, and strapi. Theoretically I could also have used a SharePoint site - thus I would also have ContentType inheritance, which others don’t offer.

I’ve tested prismic, squidex, and strapi, and decided on Strapi. Prismic is a PaaS, so you’re very limited in terms of backend adjustments. Squidex offers a managed service and also the option for self-hosting, the whole thing is written in .NET Core, should actually suit me better, however I found the interface not very appealing and a different - yes that goes with a Headless CMS - interface for administration and editorial I didn’t want to develop. That’s why the decision fell on Strapi, which is written in Node.js.

I’ll host it as a Docker container, either somewhere at my place or as a container in an Azure App Service (free tier). For the Media Library I’ll use Backblaze (S3 compatible, up to 10 GB free).

Static Site Generator

Static Site Generators are tools that create static HTML pages based on other technologies - e.g. Markdown, JavaScript (React, Angular, Vue), and XHTML - and store them in a specific structure. These pages can then be hosted on normal web space offerings, GitHub Pages, and even CDNs, like in the old days.

Since static pages don’t need databases etc., they are generally more secure. Hosting such a site is also cheaper. There are very many of these SSGs, the most well-known is Jekyll, followed by Hugo, then there are a few more, and finally GatsbyJS. I decided on GatsbyJS - without having tested the other mentioned SSGs. The learning curve seemed easier to me and there are numerous examples for Strapi.

The result will most likely be hosted in an Azure Storage Account with a CDN in front. Netlify Starter could also be an alternative, I’ll definitely take a look at it.

DevOps

The decision fell here pretty quickly - due to habit, OOTB, and availability - on Azure DevOps. What DevOps is isn’t as easy to write down as with the other headings, let’s just say that in my case it stands for source code management, automated builds, and automated deployment.

What’s Coming Next?

Here comes the outlook on the next articles that will follow this one. I’ll proceed step by step - first the data model, then the pages, and finally the automated deployment.

I still have a vision of a Search Center (Azure Search, Elasticsearch, Lucene/Solr - not yet fixed) where content from all 4 pages can be searched. A comment system that always delivers the same content on every article on every page. Then a suggestion system operated with Grakn.ai or Ontobroker. For the latter, I would have to request an Edu license from Semafora, so I believe it will rather be Grakn.