Developing a Website with Next.js

I finally deployed my website as you, the reader, can now see. As previously stated in the first post on my site, I chose Next.js as the framework since I want to learn how to better assist my coworkers as a Platform Engineer. I can say I definitely have a far better understanding of Next.js and a newfound respect for the incredible work my coworkers did on getting Next.js to function with AWS Lambda without using existing solutions.

Overall, I think Next.js is a fantastic framework, it is easy to develop with, it's performant with my website returning PageSpeed scores of 94 for Mobile and 100 for Desktop, and has solid documentation and community support. With that being said, Vercel makes it a pain to deploy to anywhere but its own SaaS service, especially if you want to use any other serverless offering.

The Good

I was able to spin up a blog and start developing locally with Next.js in roughly 5 minutes. After running through their course, I was able to confidently make changes to that starter blog with the help of their documentation and the Next.js community. Then, when I realized that the blog template I used didn't provide enough of a foundation for me to provide a good UI/UX twice, switching to a new template and migrating my existing blog posts was effortless since they all grabbed data from the same directories.

The exposure to React is also a nice bonus of using Next.js. I've used React for a previous attempt of making this personal website about 3 years ago, but was unsuccessful in moving past the tutorial phase. Now, I feel more comfortable with React than I ever was struggling through those tutorials.

Finally, it's incredible how fast Next.js is, even in inexperienced hands. I wasn't expecting to get the PageSpeed scores I did and I was sure there would be some glaring performance issues, especially since this blog is hosted in AWS and not Vercel.

The Bad

There were very few bad aspects I ran into with Next.js, however those few issues I ran into are truly awful, which you can read more about in the The Ugly section of this post. Anyways there are couple issues that I found strange, one being the difficulty in switching from having all my code in the root directory \ to src. I thought it would be as simple as moving the desired files except for public into src, then updating the various config files and imports to reflect the directory change. I was able to successfully do this without any issues running a development server, but when running yarn build I would get obscure and difficult to debug errors. Eventually I decided it wasn't worth the effort, at least for now. Once I have more experience with Next I'll go back and resolve those issues.

The Ugly

With much anticipation, it is time to talk about the worst aspect of Next.js - all of which aren't related to developing with the language itself, but instead hosting a site built with it. Now, you can use Vercel which handles everything: it enables a developer to focus on just UI/UX which does make sense. However, the problem that I have is how Vercel makes it difficult to host a Next.js solution anywhere else, especially given I want to build my own full stack solution in AWS. I saw many solutions involving hosting the site in an EC2, but this a bad solution to a problem that shouldn't exist. The cost of hosting a website in a traditional server (EC2) versus is a serverless solution is several order of magnitude more effort to maintain AND expensive for a low traffic site.

Anyways, I'll focus on AWS and the details of the infrastructure in another post. Now I want to mention the solutions I researched that do work with AWS and what advantages and disadvantages they had.

1. Vercel: Built for deploying and hosting Next.js by the company that owns Next.js.
   • Advantages
     • Allows a developer to focus on frontend development
     • Supports latest Next.js version
     • Supports all Next.js features
   • Disadvantages
     • Cost for high traffic sites
     • Limited control over underlying infrastructure.
2. EC2: A virtual server hosted in AWS.
   • Advantages
     • Can be more cost-effective for high traffic sites if your website can run on a smaller EC2.
     • More control over the underlying OS.
   • Disadvantages
     • Higher cost for low traffic sites.
     • Need to keep up with maintenance related tasks such as security updates, managing and building a secure VPC.
3. AWS Amplify: Very similar to what Vercel offers, but hosted in AWS.
   • Advantages
     • Allows a developer to focus on frontend development.
     • Similar to Vercel, but with advantage of lower costs for high traffic websites.
   • Disadvantages
     • Limited control over underlying infrastructure.
     • Slow builds times.
     • No support for Next.js 12
     • Additional costs to build application
4. Serverless Next.js Component: A zero configuration Next.js serverless component for AWS Lambda@Edge aiming for full feature parity.
   • Advantages
     • Truly is zero configuration, allowing a developer to focus on frontend development
     • Quick build and deploy times since you can run the commands in a GitHub action or locally
     • No additional cost to build
   • Disadvantages
     • No support for Next.js 12
     • Is not at feature parity with Next 10 or 11
5. Terraform Next.js module for AWS: To be discussed in the AWS and infrastructure post. This is ultimately what I decided to use.

Initially, I tried to build my own solution by adapting a next-serverless package to work with Next.js. Unfortunately, I do not have the understanding of Next to build this solution out completely. Shortly after that, I came to the conclusion that it would be a project in itself to make Next.js work in AWS, this is why there are 4 solutions above which focus only on simplifying the deployment of a Next.js site to it.