Alex Edwards

Having a full-time job and a good work/life balance is hard, add personal projects into the mix and it comes harder still. For too long my website was on a ‘coffee break’, where I redirected all traffic to a static /brb page.

This page was originally meant to be temporary, but it lasted for over a year and I never seemed to have the time to do what I wanted to with the site.

Starting Fresh

Taking an ‘MVP’ (Minimal Viable Product) approach, I wanted to hit the ground running and get something, anything, out there ASAP. This meant going with what I knew, React + Next.js, rather than using something I was interesting in experimenting with, i.e. SvelteKit.

Next was the toolchain, I simply went with my de facto linter and formatter, as well as Jest for unit and integration tests.

However, I immediately forgot about the previous statement about going with what I know and chose Playwright for end to ends, as from initial testing I found the execution “super fast”, and quickly spinning up multiple browsers, light/dark mode, I could run critical journeys as well as automated A11y tests.

CI/CD Pipelines

This is where a lot of automation plays off, taking my usual git-based workflow and running tasks / jobs against the event. Github Actions was a no-brainer as the set up was already available, I just had to tell it what to do.

With both pull requests (PRs) and main pushes, it’s always a good practice to check everything installs, builds, passes both linting and testing (iBLT). Additionally, I wanted any PR that I created to stand up new infrastructure to a staging environment, creating a live “preview” of the PRv that I could manually check, as well as run End to End tests against.

This also meant I had to create a workflow for when PRs are closed to ensure that the everything was taken down and I didn’t have un-wanted infrastructure left deployed.

The next step was where it got interesting…

Deployment

I knew I could have gone with providers such as Vercel, Netlify or the like, but having worked with AWS infrastructure, I’m more familiar with that than the aforementioned.

SST

SST is a recent spiritual successor to serverless which sped up my infrastructure requirements considerably. It took out all the pain from configuring stacks and lambdas to get Next.js working on independent infrastructure. I greatly appreciated that it was already set up with name-spacing in mind. I’m able to spin up the same stack multiple times by changing a single parameter, standing up or destroying infrastructure based on my git workflow.

Under the hood, SST is simply a collection of pre-configured CDK Constructs, so in the future, if I wanted to migrate away from SST I would simply re-create the same stack as what’s already deployed.

A Caveat of Next.js and Lambdas

When I chose Next.js and React for it’s familiarity, what I didn’t realise at the time was Next.js isn’t so kind to serverless, and so part of SST’s remit is transforming the output of Next.js to something that lambdas can understand by using OpenNext. This leaves to dependent on continued support and contribution of the open-source community to keep up to date with Next.js releases, Next.js 14 was just released, and so there’s always a risk of dropped support.

In the future, migration might be required to another framework that support an “adapter” approach, where Sveltekit and Astro both have first-party support for different deployment run-times.

Conclusion

Everything considered, with modern tooling and infrastructure available, it’s amazing how far we’ve come to enable projects being deployed readily and with best-practices in mind.

I’m going to continue with this stack, and this pipeline for the foreseeable future. It’s been a breeze to set up and it’s something I’ve missed for so long is being able to write detailed case-studies and write ups on small projects and prototypes.

As I use it more and more (I’m back… finally!) I’ll likely iterate on it’s functionality and refine it further.