A look Into The Process Of Building My Blog

The demand and popularity of personal websites and blogging has increased over the years as the Internet became more accessible and important to people around us. There are various reasons why someone might want a website of their own on the Internet. An artist might want to showcase and document their work, professors who want to host course resources and publications, corporate professionals using it as a resume, or if you’re like me you might to just showcase your work along with a bit of blogging occasionally. Given the demand of such websites, it is not hard to foresee there are multiple tools and services that has evolved over the years to help people build their own sites. When I started researching them I was overwhelmed with the sheer number and variety of options, each one taking a slightly different approach and is targeted towards different kinds of use cases. At the end, being a developer myself I decided to custom built by own website since none of the options completely satisfied my needs. In this blog I will try to summarize my learnings about the various options I found and how I went on to build my own personal blogging & documentation website from scratch.

Available options

Just like any other sane person, while taking up any initiative I like to follow a proper procedure: why I need it, define crystal clear objectives, research on available tools and techniques that I can use, build it, plan how to maintain & manage in future. And this is the research part.

CMS

In the world of blogging, you will often hear about a CMS (Content management system).

Wikipedia says:

A content management system is computer software used to manage the creation and modification of digital content.

In more human terms, it’s basically softwares like Wordpress, Drupal, Joomla. Old school but very popular, in-fact over 40% of all websites on the internet is powered by Wordpress apparently. Reasons why I didn’t choose it: requires a dedicated server and database, very little control, not cheap (not computationally at least). Ghost is another CMS new in the game, much better but still running a dedicated server & db is costly and an overkill for my requirements.

Headless-CMS

With CMS out of question, next comes a slightly modified version, Headless-CMS. What’s that? It basically CMS but divided into 2 parts, an API server and a separate frontend. This provides much better flexibility. Some examples are Strapi and Sanity (even ghost can be used as one). I liked this idea and it’s also very popular in use-cases like e-commerce websites, news websites etc. But this wont work for me because in here your API server becomes the single source of truth but in my case, my sources are diverse, often from various github repos. Plus running those API servers will cost me.

Static Site Generators

I define a static website as one that does not require any special computation at the request time, that means every user gets to see the same thing, always. All the contents are processed at the build time and produces a final html, js, css bundle that can be hosted anywhere you want. Cool thing about that is you can host the whole site on CDNs achieving super fast load times. There are many available free options to host such websites like Github Pages, Netlify, Vercel, Clouflare Pages. Since it does not require any extra computation at request time, make hosting them actually cheap. The main disadvantage is your content is not always current and up to date, will require you to rebuild and deploy the whole site to make a change. Which works for me! I don’t have any such data that keeps changing that frequently.

Given I’m sold on SSGs there are quite a few of different types out there, one category is Hugo and Jekyll. They just read your local markdown files and pukes out html and css files. Basically a md to html convertor.

React enters the chat

Well, React is a frontend framework that is amazing and people love it, so why not utilise that? You definitely can. But then loading the content is a bit of a challenge there, you will have to fetch and parse the markdown files all on the browser on the go, while your user is waiting which is not very optimal. What if we could combine the power of react (specially SPAs and reusability) with parsing and generating the html files from markdown at build time itself? This is exactly what frameworks like Next.js (SSG) and Gatsby offers. They let you generate populated html files at build time (or runtime) at the same time you can use all the great react features you need in the browser. This offers best of the both worlds, very fast page load time, code reusability and composability as well as no more “data loading…” screens. Not to mention a very scalable solution.

I decided to go forward with Next.Js’s SSG feature. Also using TailwindCSS, the hot new CSS framework in town everyone is talking about.

Docusaurus was another really good candidate that uses react and provides an opinionated framework, specially designed for documentation. I didn’t choose it because I needed more control. Next.Js is much less opinionated.

I used blog-starter template from nextJs as the starting point.

Next comes Content Management

I love using Notion. I use it all the time for keeping my stuff organized, from my movies watchlist to taking notes and keeping bookmarks. It would be great if I could use it as my content database too. So that’s what I did. All the blog posts are extracted from my Notion pages, all I have to do is click a checkbox on a notion page and it will be available on my website from subsequent builds. Even I’m currently writing this blog post on Notion. This greatly improves the whole writing and updating experience.

For project docs I fetch the markdown files directly from github using github’s APIs. It helps me keep the project documentation into their respective repos itself without having to manage them separately. Images are served directly from github’s CDNs.