A look Into The Process Of Building My Blog

Asrient
Asrient

Hey!

Welcome to my blog. This is a custom built personal blogging & documentation website that I’ve built from scratch (I have reasons to) using next.js and react. This article is meant to provide an overview of the whole process, why I decided to do so instead of a more simplified approach (eg. hugo, jekyll), how I built it and the process of writing & publishing content. If you are also planning to build your own little blogging & personal website, this might be a good read!

So to start off, I needed a personal website that would showcase my works, projects, articles etc essentially like a resume for those time I wanna showoff, umm apply to jobs. Apart from those very _corporat_e-iy reasons I also really needed a place where I could document my projects in a more friendly way. I’ve been working on a lot of personal projects for last few years and very few of them are documented at all. Building a site for each of them are both cumbersome, expensive and not to mention, hard to maintain. I needed a simplified solution that would be very cheap or free and something I can set up once and can forget about it. So I had 2 major objectives: documentation of my projects and occasional blogging.

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.

At the beginning I was very confused while researching, there were so many options available, each one taking a slightly different approach and is targeted towards different kinds of use cases. Let me summarise what I have learnt.

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.

So 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.

Screenshot_2023-06-17_at_2.26.24_AM.png

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.

//TBD