Ep.10: Next.js (Basic app for Node Backend Frameworks Comparison)

This article is part of an in-depth comparison series of the top Node frameworks. We'll cover all the important aspects: market share, learning curve, ecosystem, security and more. To compare them properly, we will build the exact same app in all these frameworks (plus Vanilla Node), observe all the steps along the way and then benchmark them as we progressively add more functionalities.

Table of contents

1. Market Share Distribution Analysis: Picking the most used frameworks
2. Planning Phase: Use cases, Minimum Viable Product requirements, Architecture
3. Tools & Setup: Getting started and setting up the tools and environment
4. Scaffolding: Project Settings and Configuration, Common template repo
5. Express: basic app (MVP)
6. Koa: basic app (MVP)
7. Express Flavors: basic app (MVP) in multiple variants: OOP, FP, TypeScript, single-file etc
8. Nest.js: basic app (MVP)
9. Fastify: basic app (MVP)
10. Next.js: basic app (MVP)
11. Vanilla Node: basic app (MVP)
12. Functional testing with Postman + Newman

What's next? Haha, lame joke, I know..., but yeah, Next.js is the last framework from the Whales pod. Not to be confused with Nest.js. Or Nuxt.js. I do believe the whole naming shenanigans is a conspiracy to get us very confused, more so as the three back-end frameworks, Nest, Next and Nuxt, are usually paired with the 3 titans of the frontend: Angular, React, Vue.

The thing is, Next is not actually a back-end framework. It calls itself a full-stack framework, but it's mostly focused on Server Side Rendering, either static, dynamic or incremental. It has a router and can do light backend logic, but that's not its main focus. It might be difficult to test it along with the others. but we'll see.

Anywho, what does Next bring to the table? According to its own website, quite a few goodies:

• Built-in Optimizations for images, fonts, and scripts, enhancing user experience Core Web Vitals;
• Data Fetching, both server-side and client-side;
• Server Actions - execute server-side code directly, bypassing APIs, to revalidate cached data and update UI with reduced network trips;
• Advanced Routing & Nested Layouts using file systems or implementing complex routing patterns and UI layouts.
• Dynamic HTML Streaming of UI from the server - instantly, integrated with App Router and React Suspense for improved performance;
• CSS Support using CSS Modules, Tailwind CSS, etc;
• Secure Route Handlers for interacting with third-party services (authentication and webhooks);
• Middleware, similar to other frameworks
• React Server Components: Integrate components without extra client-side JavaScript, leveraging the latest React features for enhanced performance[4].
• Client and Server Rendering - flexible rendering and caching options, including per-page level Incremental Static Regeneration (ISR).

That's quite neat, and together with the massive popularity of React, it explains why Next is second only to Express.

Analysis (Next.js)

Next.js is a versatile framework primarily used for building web applications, providing an intuitive and efficient environment for developers.

• DEPENDENCIES: Despite its robust features, Next.js doesn't impose an overwhelming number of dependencies, just 14 in total, which is very light. More than half are sole-maintainer modules, and some have missing dependencies. It is backed by a strong company, Vercel, so that should not be a real issue.
• VULNERABILITIES: npm audit: 0 vulnerabilities, Snyk: healthy 95/100 score with no known security issues, Socket does find some issues though, giving it a score of 70 in supply chain and license, mainly due to telemetry that tracks how you use it, shell and network access. Well, you can actually disable telemetry, so that's not really an issue.
• SIZE: We have an outlier, it has a massive 226MB for its 21 packages! We have to find out why. The largest module (131mb) is @next/swc-linux-x64-gnu, which has no description on its npm page, so what the hell is that? It serves as a part of the SWC (Super-fast Web Compiler) toolchain, and it's optimized for Linux x64 systems, providing efficient compilation of JavaScript and TypeScript code. All right, so they weren't happy with the usual compilers. The second largest part, at 86mb, is the next framework itself, followed by a 4,5mb React DOM and smaller bits. Now, the actual minified bundle size is 15mb (3.6 mb gzipped), so, it's not that scary in the end.
• COMMUNITY: massive. Development is highly active in 2024-Q1: 5 releases, 36 Contributors, 1662 Commits. So, constant releases, a large maintainer team, and enterprise backing - all great signs.

• ECOSYSTEM: Next has 83 official packages, the largest so far. I cannot tell you how many third-party plugins or libraries exist out there because of the name commonality, but I bet it's also a huge number.
• INTEREST & USAGE: TechRadar survey shows that it moved from the Assessment to the Trial phase for a lot of companies in 2019-2021. In general, interest and usage seem to be only going up:

Show me the code

First, we need to initiate a new Next project, and it comes with its own CLI. Or you can simply do this:

npx create-next-app@latest todo-next        

I left everything on default, including the TypeScript preference, except for src directory, which I do want to use.

It seems we'll need to follow the Next.js way of structuring APIs and pages. In Next.js, you create API routes under the pages/api directory, and inside that folder, there should be a folder structure that mimics the route structure:

my-next-app/
├── pages/
│   ├── api/
│   │   ├── users/
│   │   │   ├── register.ts
│   │   │   ├── user/[id].ts
│   │   ├── tasks/
│   │   │   ├── create.ts
│   │   │   ├── task/[id].ts
│   │   │   ├── task/[id]/complete.ts
│   │   ├── lists/
│   │   │   ├── create.ts
│   │   │   ├── list/[id].ts
└── ...        

Now, that's a lot of clicking to create all those folders and files, so a faster way is with some shell commands:

#!/bin/bash
mkdir -p src/pages/api/users/user
mkdir -p src/pages/api/tasks/task/[id]
mkdir -p src/pages/api/lists/list
touch src/pages/api/users/register.ts
touch src/pages/api/users/user/[id].ts
touch src/pages/api/tasks/create.ts
touch src/pages/api/tasks/task/[id].ts
touch src/pages/api/tasks/task/[id]/complete.ts
touch src/pages/api/lists/create.ts
touch src/pages/api/lists/list/[id].ts        

Routing and Controllers

There's no router per se and no controllers like we had in the other frameworks, only a handler function for each route. The routing is done automatically, based on the folder structure. For example, this file:

├── pages/
│   ├── api/
│   │   ├── users/
│   │   │   ├── register.ts        

... would be routed to /api/users/register.ts. Catch all parameters, like :id, would be represented in square brackets, like so:

├── pages/
│   ├── api/
│   │   ├── users/
│   │   │   ├── user/[id].ts        

The handler functions look very similar to our usual controllers. For example, the register route would look like this:

This is the typical handling in Next. It has some extra error handling that we did not implement yet in the other frameworks, for "Method not allowed". The extra conditional might have a minimal performance impact compared, so I might remove that, to make sure we're comparing the exact same basic app.

The other routes are pretty much identical, so no point going through all of them here, just have a look at the repo.

Services

No changes are necessary to the services compared to our baseline, Express, except for the fact that Next is TypeScript native. I will address that later, as I want to also create a TS version for Express as well.

Front-end

We don't need it, but Next is a full-stack framework, so it comes with front-end included. Actually, it can do way more on the front-end than it can do in the back-end, but that's another story.

Well, that's all folks, our app is up and running, and we're ready to move on.