It’s been 8 years since my last blog post. In that time we’ve been through a global pandemic, political tomfoolery, the rise of AI and more. Professionally, I’ve gone through the gamut of startups big and small, a layoff at the best job I ever had and continued experience in the world of frontend development.

Which brings me to this blog post! I realized I had been neglecting my blog, and one of the reasons was simply that the technology I had built it on was so old. I still and will always hold nostalgia in my heart for Wordpress and PHP, but it was so far-removed from the more streamlined coding I was and am now doing in my day to day life.

My blog was being hosted on an all-in-one platform that hosted Wordpress and a MySQL database, with a domain name and email service included. It was nice to begin with as it was geared towards less technical users – configuration was all UI-based on their dashboard. To upload files, we were instructed to use FTP via a client like Filezilla. After a while this gets pretty cumbersome though. I wasn’t able to leverage Git and version control my changes. Making any sort of new area of my website required hacking a custom Wordpress page together through PHP and random JS scripts included manually in the HTML document.

I pined for the organization and modern tooling of a React app, and so after 8 years I decided my blog was due for an overhaul. The first step was deciding what platform I was going to host my site on. I knew I wanted something modern that supported Git, automated deployments, and tooling for modern Javascript apps. I didn’t need a fully-fledged hosting solution with email service or even databases. Even more ideal would be a platform that required little to no dev-ops set up and that I could just push my app up to and go. In this relatively mature age of the web and Javascript, there are so many services that fit the bill for this. After considering various services like Netlify, Heroku and others, I ended up choosing Vercel, which is now what I am hosting this site on.

So far, I am LOVING Vercel. It’s free to set up apps on, but also allows you to purchase a domain to hook them up to. I connected my Github account, pointed to a repo, and voila! My personal site app was set up to automatically deploy on commits to my main branch. Some other goodies it provides are build and runtime logs, environmental variable configuration, and support for the latest JS frameworks and tools.

Next I needed to decide on a JS framework for my site. I could’ve gone with a simple React app, but as my site was going to primarily consist of a blog pulling from some database (I wanted more flexibility than a file-based blog), and secondarily with small apps I make that would invariably call APIs. Therefore I wanted some backend capabilities of interacting with APIs securely and perhaps exposing some endpoints of my own for the frontend.

So it sounded like what I was needing was likely a fullstack Javascript app. In my day jobs I haven’t had much experience with these – I’ve worked primarily with SPA React apps that make authenticated API requests, and my last deep fullstack work had been with Ruby on Rails. I hadn’t had experience with server side rendered React, but through the grapevine I was hearing a bunch of hype about frameworks like Next.js, GatsbyJS and Remix. The tech world moves so fast, so my blog overhaul seemed like a great opportunity to delve into one of these.

I ended up going with NextJS, as it provided all the features I needed, easily integrated to Vercel and perhaps most importantly – had a mature community surrounding it with plenty of resources, tutorials and excellent documentation. For me, clear and thorough documentation is so necessary and makes development so much more efficient and fun to do. Even just accessible documentation is key! GatsbyJS was a strong contender but I couldn’t get over their documentation site blanking out on every navigation and requiring a hard refresh.

So far NextJS has been fairly pleasant and straightforward to use. Routing is based on the project file structure, which makes it easy and clear to add pages and nested routes. Server side rendering is the default, meaning your site content and any API requests it may depend on is all done server-side before arriving nearly (if not completely) ready and accessible to the end user. This means faster loading times and faster availability of content, as opposed to traditional SPAs that send all the Javascript to the user first and then begin to construct the page and make requests for content for the user. NextJS also provides some nice caching capabilities out of the box to make this even snappier, and which makes a lot of sense for a blog-based sites where you’re likely not going to need to frequently request fresh data.

Naturally, this preference for server-side rendered React components was a bit of a learning curve for a developer like me who is used to purely client-side React components and functionality. There’s quite a big difference between CSR and SSR React components – namely, there’s no state in SSR React. All the patterns we client developers are used to – hooks, useState, useEffect, handling UI events – have no place in the SSR world. Logically it makes sense as these things don’t exist server side, but while developing it took a little bit to get used to this paradigm and not knowing exactly how I would implement basic things.

For my blog pages, SSR is king and all I really need. I’m able to securely query and await an API for my posts within my component, then render the results. No state management is required – for paging through my posts or displaying posts in a certain category, URL and route params are enough for my components to know what to render.

Things got a little trickier when implementing a little side application for being able to search for adoptable chihuahuas in your area. I needed some client-side interactivity for implementing the zip code input and dropdown filters for the search results. It wasn’t immediately clear to me how I would go about this – would I need to forego SSR for this app altogether and use client side React for everything? Understanding that in NextJS, SSR components can render normal client React components was key. In fact, if you want any client-side interactivity, such as for something as minor as a “back button” to take a user to the previous page, you would need to render a separate component that was specifically a client-side component to do this. On the server side, we don’t have access to the browser history (state) and can’t link to the previous page. A normal client-side React component can though, so the trick is to rendering a SSR component that in its tree renders a CSR component. That CSR component then has access to the usual UI/stateful hooks and patterns and gives us that JS interactivity we know and love.

I’m still wrapping my head around the intricacies of this pattern – even CSR components can render SSR components as children! – but overall the benefits of this really make things clear to me: render as much as you can securely server-side for quicker availability of content, and send along JS for CSR components to maintain state and leverage the interactive powers of dynamic sites. It seems to be a nice blend of both SSR and CSR advantages, all packaged into one Javascript-based framework.

Finally, the last thing I needed to think about was how to store and make my blog posts available. With Wordpress, there’s a nice API layer above a database for storing my blog posts, with relevant metadata such as post categories, attached pictures and so on. I considered and did an early version of this site leveraging the Wordpress API and my existing database of posts, but I didn’t like that I still needed to host Wordpress and its database myself. I wanted a headless solution, where some platform can store my content for me, ideally for free, and I could query it via an API to show as I wanted on my website.

I ended up landing on Sanity.io, which ticked all these boxes PLUS had easy integration into a Next.JS app. Even better was their robust tutorials and docs, which provided a step-by-step guide for migrating Wordpress posts over to Sanity. This is the kind of thought and developer empowerment I am here for. Overall I’m able to do everything I was able to do with Wordpress, including authoring posts via a UI editor that I can customize to my needs. The one thorn I’ve found with Sanity is that they leverage a custom query language called GROQ for interacting with data, which isn’t terribly intuitive and a bit of a pain to work with. Why not just use an existing language like SQL, or better yet, abstract it away with an API layer? There is an option for querying content with GraphQL which may be better, but thus far I have not gone down the route of setting that all up.

Overall I’ve learned a lot in this little endeavor of modernizing the tech stack for my personal site, and I hope to be more active in blogging or developing little apps now that it’s so much easier to do so. If you’re interested, feel free to check out the Github repo for this app. Stay tuned for more!