When I built Milk CMS, one of my plans was for it to serve as a backend for SPAs or blogs like this one. Naturally, after I had the CMS in a decent state, I wanted to make my own log so I could have something that used it. So, I built this.

The Design

To begin, I did something I don't usually do but should definitely do more often: made a mock up. Typically I just mess around with the CSS until I find something I like. This time I used a free program called Lunacy. I had a basic idea in mind. I wanted it to be simple, but still visually appealing. I spent an hour or two exploring ideas, and then came back to it the next day to make sure I still liked the mock up, then I converted it to HTML and CSS.

What's this Built with?

This site is a Next.js React app served by my DigitalOcean server. The app makes requests to the Milk CMS API to display my posts.

The Evolution

Originally, I just built a single page React due to having become accustomed to the framework. It loaded nearly instantly and then made a request to Milk once it loaded in the browser. However, I overlooked a somewhat large flaw being that since it loads the content with a javascript request after the initial load, both SEO and "Twitter Cards" are broken. The HTML meta tags aren't filled in with data until the request is made to Milk. I didn't initially think of it being a big deal since I didn't have plans to post my logs anywhere, but the more I thought about it, the more it made me mad that I couldn't if I wanted to.

2nd Iteration - Flask

The obvious solution is server side rendering. Being familiar with the Flask framework, I converted my React SPA to a Flask application. It worked fine, but I didn't like it for a few reasons. One, its written in Python with Jinja templating. While I enjoy Flask for APIs, I've grown to dislike using it for full sites. Two, I already have 2 Flask apps running on my Digitalocean server and they use quite a bit of ram. In my experience, somewhere around 100mb depending how beefy it is and what kind of processing it handles. My server only has 1gb of memory so I wasn't too interested in adding a third.

3rd Iteration - Next.js

Wanting to keep it in React, I decided to research Next.js. It took some trial and error, but I eventually had a Node server with a Server Side Rendered React app that basically turns it a SPA after the initial load. A pro about this version also is less ram usage compared to the Flask version (~40mb).

Next.js bug

A known issue within Next is that when hitting the back button on the browser, the page will jump to the cached scroll position of that page prior to actually changing pages. This causes an annoying visual that made me seriously consider going back to one of the previous builds of my Log. Luckily, I found a somewhat jank solution that involves disabling the browser scroll cache for the site and then manually caching and then restoring the scroll position after the page changes. It isn't perfect, but it's acceptable to me.

Conclusion

While this site took me longer than expected and then I probably would have liked, I learned a lot including Next.js and how to setup deployment for a Node app. I'm glad to have found a way to keep it in React while allowing for better SEO and social media cards.