What's under the hood?

The first thing you probably noticed the first time you came (back) here is that it’s amazingly fast. Going from one page to another is instant, but this is not a single-page application that would behave very badly regarding SEO, it’s a real website. This magic comes from Gatsby, a React-based, GraphQL powered, static site generator.

To understand what a static site generator is, let’s use this definition from Cloudflare’s Learning Center:

A static site generator is a tool that generates a full static HTML website based on raw data and a set of templates. Essentially, a static site generator automates the task of coding individual HTML pages and gets those pages ready to serve to users ahead of time. Because these HTML pages are pre-built, they can load very quickly in users' browsers.

That means that when the website is built, you’ll never actually make calculations on the server or access a database, everything has been generated already, and that’s why it’s so fast.

But Gatsby is a little more than just a static site generator. As explained in “What is GatsbyJS?” Mediacurrent’s article:

It uses powerful preconfiguration to build a website that uses only static files for incredibly fast page loads, service workers, code splitting, server-side rendering, intelligent image loading, asset optimization, and data prefetching. All out of the box.

The result is incredible and I had a hard time believing it the first time I tested it on PageSpeed Insights:

This is what you get with Gatsby out of the box!

I decided to go with Gastby instead of similar technologies like Next.js, Hugo, Jekyll, or Nuxt (full list here) because it's something we (but not me directly) use for the websites of Ludus and madewithlove, and I want to be able to knowingly dive into those if it ever becomes necessary.

Gatsby is one of the most prominent flag bearers of the Jamstack architecture, a handy abbreviation coined by Netlify’s CEO Mathias Biilmann which stands for JavaScript, APIs, and Markup.

Again, instead of attempting a somewhat wobbly definition, let’s learn more about Jamstack thanks to this fantastic explanation on Bejamas’ blog:

Today Jamstack refers to a web development architecture that allows developers to rely on a static website’s advantages, including better web performance and security benefits, while still retaining the dynamic attributes of a database-oriented CMS without the database.

Jamstack approach enables you to create fully dynamic sites while the real assets are pre-rendered static files deployed on CDN. The dynamic side of things is handled with client-side JavaScript, usually run through serverless functions.

At this point, I think you understand the static side of things, but the data still needs to come from somewhere, right? Well, yeah, and for that, you’ll want to use a headless CMS. Let’s see what Storyblok says about that:

A headless CMS is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API or GraphQL API for display on any device.

The term “headless” comes from the concept of chopping the “head” (the front end, i.e. the website) off the “body” (the back end, i.e. the content repository). A headless CMS remains with an interface to manage content and a RESTful or GraphQL API to deliver content wherever you need it. Due to this approach, a headless CMS does not care about how and where your content gets displayed. A headless CMS has only one focus: storing and delivering structured content and allowing content editors to collaborate on new content.

I could have gone with Contentful, Ghost, Sanity or Netlify CMS (full list here) but I decided to go with Strapi because at some point you just need to make a decision and stick to it. The thing I liked with Strapi however is that it's actually open-source, that you can use it with your favorite RDBMS (in my case it's PostgreSQL) and even though you can customize everything without writing a line of code via their admin, it will generate a full Node.js codebase that you can modify afterward if you have specific needs, something that a hosted SaaS tool like Contentful doesn't allow. It was important for me to stay on top of my data, and not be vendor locked. Nevertheless, I didn't have to edit the source code generated by Strapi and probably won't have to anytime soon, but it feels good to know that it's possible if I ever need to do it in the future.

In a few words, Strapi allows you to create your models (via what they call the Content-Types Builder), create relationships between them, and set up permissions (who can read, who can write, etc.). After doing that, you can create entries for all these entities from the admin (with a WYSIWYG interface) or use the automatically generated REST or GraphQL APIs.

This is how you create a model with Strapi.

And this is how you create an entry.

I won’t lie, I didn’t come with all these things all by myself, because I pretty much followed this tutorial from the Strapi blog, customizing it a bit here and there to make it look and behave the way I wanted.

From a hosting point of view, I’m using Netlify for the Gatsby part and Heroku for the Strapi part. For the latter, you won’t need much more than the Hobby plan at $7/month because it will only be put to work when you build your website (even Free could work but I wanted to avoid the sleep after inactivity that would’ve lengthened the build time).

From a pure workflow point of view, I currently write all my articles in Craft. When I’m ready to publish, I export it to Markdown and import it inside Strapi. I then manually trigger a deployment on Netlify to get the latest content on my website. This last step could be automated (via Strapi Webhooks) whenever I hit the save button in Strapi, but I haven't taken the time to do it yet.

All in all, I know exactly what you’re thinking: yeah, this is clearly over-engineered. I could simply have written HTML and CSS files and put them on the cheapest host provider I could find. Still, I think it’s worth it in the end because I learned a lot and the end result is simply amazing in terms of speed, something I would have never reached even with the most basic HTML website. Also, I’m not and I will never be a no-code guy, but this probably deserves a blog article on its own (haters gonna hate, stay tuned).

Before I let you go back to what you were doing before reading this article (thanks for reading thus far by the way), I just want to add an extra few words on the fact that this blog will never have ads (or sponsored articles) again and that I will never try to spy on you in any way. I decided to go against surveillance capitalism tools like Google Analytics and use Plausible instead, a very simple analytics tool that gives basic information about my website's usage (but more than enough for my needs) and, more importantly, that respects your privacy.