How I rebuilt this website

December 26th, 2021

I wrote a pretty solid tl;dr for this post in my last post, so going to paste it here:

The previous iteration of this website required me to make code changes (and subsequently deploy) every time I wanted to add content to the website. This took forever, and often the inspiration to jot down a thought would dissipate before I got the chance to log in to my computer, open VS code, write down my thought + surrounding JSX, and push to Github (crazy right?) But with this new website rewrite, I don't require any code changes at all. My website is backed by Notion (spoilers!) so now I can write in my preferred editor and my content is updated and published automatically. I already find myself writing more now with this new functionality, but time will tell.

Problem

As I mentioned above, the primary problem with v1 of my website was that every edit required a code change. Code changes have a lot of friction, so I never ended up writing on this website as often as I wanted to. Or honestly, at all. I decided that I wanted a seamless way to edit my blog content, so I built it.

Solution

When I decided to rebuild this website, I knew a few things:

1. I love Notion

2. Notion recently released an API

3. Storing my blog content in a SQL database was going to be tedious

4. Storing it an S3 bucket would be equally as tedious

5. My website was built with Next.JS

Around this time, I had also learned about headless CMS while I was investigating ways to help us edit internal data for momo (all the CMS models’ type systems weren’t powerful enough - if you know any good solutions, please let me know!). Not sure what the formal definition of a headless CMS is honestly, but I view it as a nice wrapper to structure, store, and manage data (like SQL but with a pretty and simple UI + intuitive APIs).

Despite not using a headless CMS for momo, I realized it would be a great solution for this website. And after reading through Notion’s API docs, it was clear that Notion could be the solution I needed. Bless you, Notion devs.

So now I had a place for storing my content, but how was I supposed to serve it effectively? In a client-side rendering world, we would have the client send requests to our server (which in turn, would communicate with Notion) based on the data we need to render a page. This is inefficient, since we fetch data every time despite the underlying content changing very infrequently. This is where Next.JS’s incremental static generation comes into play.

Incremental static generation takes a different approach, basically:

1. Build the website’s static HTML

2. Serve those static files to users on request, utilizing CDN caching

3. When a page is viewed, check if the content backing the page has been updated

4. If so, rebuild the HTML for the page using the new data, invalidate the cache and serve the newly built page for future requests

With this approach, we only need to build + deploy the website once, and it updates on its own from there! If you’re interested in the details of how this is configured, you can check out the docs here.

This new workflow to publish my content is inspiring me to create more of it. I don’t use social media much, but this experience has made me realize all the more that seamless creation/publishing is key for any platform fueled by user-generated content. I guess it all circles back to reducing the required effort for a user to take the desired action. A topic for another post, perhaps.