How I rebuilt my (OLD) Portfolio+Blog website.

I recently revamped my portfolio website from a bare-bones static site to a robust new architecture and this explains my journey of this project

I had a plain HTML+CSS based website as my portfolio until a few months ago, when I realized how non-scalable it was. For every new project, I had to manually duplicate an existing project’s html page and replace the existing content with the new content and push it to the server. I also planned on using my website as a blog which I could not with the existing bare-bones architecture.

The Objective

To revamp my portfolio website to be easily scalable and maintainable and also double it as a blog.

The Approach

The problems that my old website faced apart from scalability and maintainability were that it was not SEO friendly and there was no room for code reusability. It was as rigid as it gets. And when I ran the Lighthouse utility that generates scores for Accessibility, SEO and Performance, it had moderate and sometimes even poor scores. And I also didn’t want to spend a hefty amount to maintain my own server to host my website.

All the mentioned issues above would be addressed if I build my website with a Jamstack architecture. Jamstack architecture involves a static site generator that takes in your maintainable and scalable code and generates plain html, css and js which can be hosted on any hosting services without having to worry about maintaining servers.

To make the code maintainable, scalable and reusable, the static site generators support various templating languages. The static site generator also takes care of accessibility up to a basic level. After researching various SSGs, I chose 11ty as my static site generator and Nunjucks as my templating language due to the former's commitment to accessibility and the developer friendly community.

Thus, Jamstack became my ideal choice of architecture. But, I still had a few unresolved problems. I needed a CMS with a frontend to make it easy for me to publish projects and blog posts. I chose Forestry as my CMS since it is a Git based CMS, meaning the content is tied to a git repository and moreover forestry generated markdown files which 11ty natively supported to be processed into html based on the template defined. The added bonus was that forestry has a great markdown editor which has the ability to define alt texts to images and figures which helped with accessibility.

This resulted in the following techstack:

I decided to host my website using Vercel since 11ty works in conjunction with NPM to generate static files and vercel has an easy way to execute production build commands for NPM and integrates readily with GitHub where I maintain the git repository for this project. And, it is free!

Once the architecture was decided, I made quick mockups of the design of the website on Figma and started the implementation alongside design. For the CSS layouts I have used a mix of both flexbox and grids.

After a few days spent on implementing the design, the website was ready for deployment and was deployed seamlessly (until I decided to add the push notifications feature).

At this point I had 2 workflows for adding/modifying data to the website and deploying.

The Content Workflow

Add/Edit projects or blog posts on Forestry CMS -> All saves are commits to the git repository -> Each commit triggers the vercel integration connected to the repository and this cues the rebuild and redeployment of the entire website.

The Code Workflow

Add/Modify the existing codebase -> Commit and Push changes to Github -> Each commit triggers the vercel integration connected to the repository and this cues the rebuild and redeployment of the website.

The Challenges

The Light and Dark Theme support

During the design phase, I had planned on supporting both light and dark themes. But during the implementation I had initially started the theming using plain CSS. This turned out to be a bad decision since it became hard to implement the theme toggle. Thus later I switched this to SASS and JS which although took some time to set up, it became very beneficial later on in terms of maintenance.

The Push Notification Journey

After the basic version of the website was ready, for the next iteration, I planned on adding a way to notify users who subscribe to my blog posts by using push notification on the browser. This enhancement was the biggest challenge.

Since I had no need for maintaining a server due to the Jamstack architecture, which decouples the website hosting from the server, I had only opted for static site hosting service with Vercel. But to implement push notifications, there was a need for a server and Vercel doesn’t provide servers.

My exploration led me to try a few solutions:

Using serverless functions on Vercel

This was not ideal for a few reasons.

• Serverless functions have a cold start, meaning that if there are no HTTP requests to the endpoint for some time it is internally shut down and when a new request does come, it takes a significant amount of time to do the task of subscribing. This leads to a bad user experience, since the user expects a simple subscribe button to work instantly.
• Serverless functions don’t readily come with persistent storage options. So to store the subscription list, I have to build another connection with an external database.

Using a small server that can be run freely and reliably

There was a reason why I was trying to avoid a server to deploy my website. I didn’t want to spend a hefty amount of money for the server, which will be used to only host my website and nothing else functionally. So my exploration of which services provide me free plans for a server resulted in me finding Google Cloud Platform's Free Tier, which had all the features I needed and just enough hardware for my server to handle some amount of load. (which is not a lot currently, since it will be used just to subscribe the users and maintain a list)

After deciding on building a server on GCP Free Tier, I created a small ExpressJS server on a Compute Engine Instance and tested it with Postman to move to the next part of this feature.

Adding the subscribe action to the website.

For this, I had to add a service worker that talks with the browser to get an endpoint and a unique identifier which gets relayed to my server’s endpoint. On my server, I use a filesystem based database called nedb that maintains a list of subscribers.

On another endpoint on my server, I have set up the broadcast functionality. I make a POST request to that endpoint with credentials and data to be broadcasted to the subscribers and that results in subscribers receiving notifications.

The overall architecture of the project:

The Results

• The code is scalable and easy to maintain.
• The performance, accessibility and SEO have improved significantly.
• The website doubled as a blog with better a content management system.
• Additionally, added theme toggle for dark and light themes.