I find myself scratching my head everytime I need to explain the inner workings of my blog. It is not because it is special or complex. For me, it is because the automation does not need me to remember the details - it just works. The automation is not unique. I suspect it would be common. I am just writing it down so that I don't have to stare at my source code and try and remember how everything is hooked up.

Markup over WYSIWYG

I have always been more comfortable with markup languages or schemas over WYSIWYG editors when the content has code or Math. For markup languages, a simple editor such as the forever trustworthy vim or more recently Microsoft Visual Studio Code, is my choice.

Websites for Static Content

When a website needs to show static content, using a general purpose language to store and extract the content from a database seems somewhat of an overkill. An alternate strategy would be to serve the static assets, and it is adequate for most purposes. However, it is no fun editing a collection of HTML files. I worry about tags and angle brackets which distracts me from the writing. This is where a markup scheme such as Markdown comes in. A processor can convert Markdown text to HTML very fast. This also has the nice effect of separating content from the engine that converts and renders the content.

Components to the rescue

Using a different markup schema does not solve the problem of editing a collection of files. The front end programming community seems to have come full circle with content rendering. It started out on the server as pages, went to the browser as components, and then went back to the server as components. Modern front end frameworks such as React, Angular and Vue support rendering (or building) pages on the server from components; this is called Server Side Rendering (SSR). This is where Gatsby comes to the picture - it is a site generator using React. Gatsby pulls in all the configuration for SSR to work out of the box. It also has a host of plugins to cut down on development time.

One more thing...

We have the content in Markdown, and a site generator with Gatsby. We need a way to query for the content, and plug it in the components. This is where GraphQL comes in. GraphQL lets me query the content to build ordered lists, extract tags and more.

Oh, one more thing!

We need something to serve the site. A Content Delivery Network (CDN) is meant to do exactly that. An added benefit is CDNs are edge optimized which is a fancy way of saying that the content is replicated to multiple geographies, so that a reader receives the content from their nearest node (server), and not the server your cousin set up in New Delhi in her basement. The other benefit is redudancy, which means in case of a node failure, another node (or it's backing source) will take over to serve the content, unlike your cousin's set up where server failure would make your site unavailable. While there are many CDNs to choose from, I chose Netlify because they also provided the simplest (and for me sufficient) way to build and publish my site. They also take care of my domain, but that's another thing.

Continuous Deployment

The site and the content is in version control on GitLab. Netlify has an amazing integration with GitLab that just works. Netlify acts a build server that builds the site whenever a branch is pushed or merged with the production branch. In addition, it deploys the site when a branch is merged with the production branch. It also sends notifications back to GitLab when the build operation starts, succeeds or fails. This has the nice effect that GitLab is able to perform clean up operations such as automatically deleting the merged branch on remote, once the build succeeds in Netlify.

Future Improvements

All this works pretty well for me. One improvement I would like to make from an Architecture point of view is to separate the content and site generator into two different repositories. This would promote a cleaner separation of concerns, though at the moment I can't fathom any benefit from such a separation, which is why I will not embark on it.