Introduction

Since late 2024, I started to learn NextJS and I wanted to document this journey for archival reasons but also share my experience of getting to know this framework in greater detail. Foreword

A bit about me

Before I get started, I wanted to provide some context for this piece.

I have been working for London fintech startups since 2015, primarily holding non-technical roles like operations, customer support, and data management. At each of my roles, I had significant exposure to software engineers and understood full well what this species was all about.

In 2022, I decided to transition to become a web developer – starting with learning Python, then completing a 3 month bootcamp and after, landing a junior software engineering role. Since then, I have worked on two major production projects that used React on the frontend:

• One project was a freelance gig, where I was a solo dev that created a React SPA (as well as backend in Django and DRF, plus deploying both apps) for a startup that deals in landlord loans and generates five figures in loan originations every month.

• My current role involves working as part of a frontend team and contributing to building a React SPA for intraday liquidity for banks

While I have extensive experience of specifically using React and TS, I wouldn’t call myself a master in these and probably label myself somewhere between a junior and a mid-level engineer at the moment.

Why NextJS?

In 2024, I was experimenting with personal projects that used React and ExpressJS. This is a solid tech stack but I wanted to have a go at SSR that was still utilised my React knowledge.

There are a number of motivations why I picked up NextJS.

First, I did some research into the most popular React meta-frameworks and it was clear that Next is the leader here. Judging by the amount of downloads, GitHub activity, official documentation and the community around it, it was clear that it was widely used by many developers.

Second, I wanted to check if I was to learn NextJS, that this skill could be transferred into other roles. I had a quick look on LinkedIn jobs and every 2nd frontend job ad mentioned Next one way or another (anything from “nice to have” to a “must have”) – this was a green flag in my eyes since not many NextJS competing frameworks were mentioned e.g. Astro or Remix.

Third, I looked into the educational resources behind Next. The official documentation seemed top-notch, I saw plenty of YouTube tutorials as well as paid courses and written guides in this framework. This is another green tick.

Why not NextJS?

During the initial stages of my research, it was not all roses and daises. I noticed some valid criticisms of Next. The major sticking point that many developers had was the relationship between Next and Vercel.

Vercel is the for-profit company behind Next. They make it super easy to deploy Next applications on their platform and Next apps are specifically optimised to work there.

I am a fan of self-hosting movement and also intended to deploy my Next project not on Vercel. There is OpenNext that could ease some of these concerns but I will see how useful it is when I actually deploy it.

Another perceived drawback of NextJS is the lack of backend functionalities that most mature and established frameworks (Django, Laravel, etc) have. More on that later.

I I appreciate that every framework has a fair amount of naysayers and also cheerleaders, but as a wise man once said - "Nothing ventured, nothing gained", so I went down the rabbithole.

Tech stack I am using

• NextJS (v15 and app router)
• TypeScript
• CSS modules
• Drizzle ORM
• Supabase
• Stripe
• Zod

Impressions so far

As I mentioned earlier, I used React and Express for most of my web dev side projects – this combination is simple to use, doesn’t have the bloat that MVC frameworks like Django come with, and you can get started in minutes after the initial boilerplate has been set up (I created templates after a few projects).

If I was building a REST API with Express, I would have to define a route, then connect it to a function, validate the request, then type it correctly and often than not, connect it to the database.

Then on the React side, I would have to create a function for the HTTP method, type the payload correctly and validate it before sending it to the server.

I wasn’t using tRPC at the time so a lot of the steps were duplicated and this is what I loved about Next.

Consider the below server rendered page

import { getAllPets } from "@/db/queries"

const page = async () => {
  const pets = await getAllPets()
  return (
    <div>
      {pets.map((pet) => (
        <p key={pet.id}>{pet.name}</p>
      ))}
    </div>
  )
}
export default page

Where getAllPets is defined as

export const getAllPets = async () => {
  return await db.query.pets.findMany()
}

Server actions is one of the biggest selling points of Next in my opinion. Being able to seamlessly jump between frontend and backend makes me feel more productive and the lack of duplicated code (for validation, types, routes, etc) makes the application more maintainable.

I liked reusing the same Zod validators and type definitions on both sides of the project, so that there is a single source of truth. Since previously, if I modified the Pet type, I would have to change the Drizzle schema, then the type, then the validation in the backend, and later, do the same thing on the frontend – being able to remember all these steps is a sure way to introduce bugs and screams technical debt.

The gotchas so far

So one of the pitfalls in my view of Next is the middleware. In Express, the middleware is super flexible, you can do whatever you want it and there are no realistic limits to the kind of stuff you want to do with each request.

When I was trying to implement authentication (more on that below), my first attempt included modifying Next’s middleware, which consisted of checking the authentication token of each request in the database for some set routes.

The problem is that Next’s middleware runs on the Edge runtime, meaning that it can run super fast and efficient for the end user, but the downside of that is that this runtime does not support the core packages of Node runtime.

So being able to run database queries through the middleware is essentially impossible (unless you want to hack the heck out of it). I appreciate that Next’s documentation marks middleware authentication as optional here. But this voids the first, usual filter for authenticating requests through the middleware that we’d normally have in traditional frameworks.

There are some discussions about Next middleware here but so far, it doesn't look like the runtime has been changed.

The second biggest gotcha is authentication

This criticism is not specific for NextJS but of the overall ecosystem.

Yes, I can create my own way of authentication and authorisation but why would I do this if I have the option of using a library, especially if I am building out a quick MVP or a prototype? If I don’t use a library or a framework, I will be creating one of my own, which is not the direction I like to go down.

So there is NextAuth (AuthJS), which I spent two days trying to configure and work with my project (probably skill issue). The problem is that I wanted to use email and password as credentials and NextAuth doesn’t make it super easy due to their philosophy of using this antiquated authentication method.

There are a bunch of other auth as a service providers but I typically like to avoid these platforms and opt for open source/free methods instead.

I ended up using Lucia auth and implementing my own logic for authenticating and authorising requests. It isn’t a big deal that I had to do this as I like to know the inner workings of such a critical system but in the future, I would definitely be interested in using an AuthJS alternative that doesn’t charge me on amount of daily users.

Perhaps this is a general criticism of JS ecosystem as a whole – while MVC frameworks have figured out the basics of building applications (authentication, ORMs, CMS, admin view, etc), JS world has so many options that picking one library for a particular use case is super tricky, and the catch here is that not all of these libraries are even good or are overwhelmingly opinionated.