For session management in a Next.js project using Auth.js or Clerk, middleware is almost essential. However, until now, I have simply copied and pasted the code provided in the documentation into my middleware.ts file without giving much thought to what middleware actually is, why it is used, or what its benefits are.

So today, I am taking the time to deep dive into middleware and explore its purpose and advantages!

1. What is Middleware in Next.js?

Let's start with the official Next.js documentation:

Middleware allows you to run code before a request is completed. Then, based on the incoming request, you can modify the response by rewriting, redirecting, modifying the request or response headers, or responding directly.

In simple terms, middleware intercepts every request, allowing us to add various logic or directly manipulate the request/response.

But what does "request" mean in Next.js?

2. What is Considered a Request in Next.js?

(1) Page Requests

A page request occurs when:

• A user directly visits /dashboard
• A user navigates to /dashboard using <Link>
• A user refreshes the page while on /dashboard

(2) Fetching Data

Requests also occur when fetching data, such as:

• Calling an API route (app/api/* or pages/api/*)
• Using Server Actions to fetch data

(3) Does Middleware Run on Re-renders?

Some people mistakenly believe that middleware runs when a component re-renders. However, middleware is NOT triggered by component re-renders.

According to the official Next.js documentation:

Middleware execution is NOT directly triggered by a component re-render. Middleware runs only on incoming HTTP requests from the browser or API calls.

In short, middleware does NOT run when a component re-renders on the client side.

3. When Should You Use Middleware?

Integrating Middleware into your Next.js application can significantly improve performance, security, and user experience. Below are some common use cases:

(1) Authentication and Authorization

• Middleware can check session cookies in request headers to verify whether the user is authenticated before allowing access to a protected route.

(2) Redirects and Path Rewriting

• If a user is not logged in, middleware can redirect them to the login page before they reach a protected route.

(3) Logging and Analytics

• Middleware can capture and analyze request data before processing it in an API or page.

4. Applying Middleware in a Next.js Project

To apply middleware correctly, you must follow two key conventions:

1. The middleware.ts file must be in the root directory of your project.
2. The filename must be exactly middleware.ts or middleware.js.

If your middleware is not working, check these two points first!

Example Middleware Implementation

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

// This function can be marked `async` if using `await` inside
export function middleware(request: NextRequest) {
  return NextResponse.redirect(new URL('/home', request.url));
}

In the example above:

• Middleware intercepts all requests before they reach the actual page or API route.
• The function takes a request parameter of type NextRequest.

5. Understanding NextRequest

The NextRequest object extends the Web API Request and provides additional convenience methods.

Analysis of NextRequest

// request.ts
export declare class NextRequest extends Request {
    [INTERNALS]: {
        cookies: RequestCookies;
        url: string;
        nextUrl: NextURL;
    };
    constructor(input: URL | RequestInfo, init?: RequestInit);
    get cookies(): RequestCookies;
    get nextUrl(): NextURL;
    get url(): string;
}

NextRequest is a subclass of Request. It inherits all the standard request properties (headers, body).

export declare class NextRequest extends Request {
  // extends means to inherit all the properties.

But it stores internal metadata related to the Next.js-specific features, such as

• cookies (to store request cookies)
  • nextUrl (for easier URL handling)

[INTERNALS]: { //Internal is unique key for object properties
        cookies: RequestCookies;
        url: string;
        nextUrl: NextURL;
};

In the next post, we will explore case studies on how middleware is used in each scenario.

a structure that determines the way your product and business will operate, perform and scale.

2. web app architecture types

1. MPA : consist of multiple HTML pages, sends requests to server for different HTML in every change.
2. SPA : consists of single page, sends requests to server for data that needs to be changed.

3. CSR vs SSR

The difference between CSR and SSR is that wich side(client or server) is responsible for rendering the web page.

what is rendering?

the process of converting application code into interactive web pages

📍 CSR : it’s the browser that generates the entire app, including the UI, data, and functionality.

The client recieves empty HTML(Shell), CSS and Javascript bundle from front server. And sends request to back server for data while the web page is loading.

👍 pros :

• better user interactivity

→ no need to reload pages

• caching

👎 cons :

• initial loading may take too long

→ The browser needs to download and run the whole JS includes frameworks and library

• Low SEO

→ Bots will only see empty HTML

💡 solutions:

• code splitting
• tree-shake
• SSR

📍 SSR : it’s the server that generates static HTML. The client receives fully rendered HTML page.

👍 pros :

• better SEO
• Faster initial page loads

👎 cons :

• blinking issue, non-rich site interaction
• server side overhead
• need to wait before interaction

→ TTV < TTI

🪜 SSR Steps

1. Client’s HTTP request – When the user enters the URL into the browser’s address bar, it establishes an HTTP connection with the server, then sends the server a request for the HTML document.
2. Data fetching – The server fetches any required data from the database or third-party APIs.
3. Server-side pre-rendering – The server compiles the JavaScript components into static HTML.
4. Server’s HTTP response – The server sends this HTML document to the client.
5. Page load and rendering– The client downloads the HTML file and displays the static components on the page.
6. Hydration – The client downloads the JavaScript file embedded into the HTML, processes the code, and attaches event listeners to the components. This process is called hydration.

4. CSR vs SSR in point of TTV & TTI

TTV(Time To View) refers to how much time it takes for users to see the rendered web page.

TTI(Time To Interact) refers to how much time it takes the JS file to be loaded so users can interact with web page.

In CSR, users can’t see or interact with web page until all JS files are loaded. Therefore, TTI and TTV is same. Otherwise, in SSR, users are able to see the web page but it takes some time for users to interact with the page. Thus TTV is longer than TTI.

5. Is CSR and SPA same?

The answer is NO. The difference between MPA / SPA is how many pages the web app uses. Otherwise, the difference between CSR / SSR is where the web page is rendered. Therefore, the relationship is not an equal sign.

SSR supports MPA for showing multiple pages to users, and SPA is based on CSR for intracting with users on a sigle page.

6. What to choose then?

CRS is suited for the web page which requires high interactivity with users and the contents changes frequently.

SSR can be implemented in web app that is static and contains heavy contents. Moreover, SSR is better choice when SEO is important element for web app

React components accept arbitrary inputs (called “props”) and return React elements describing what should appear on the screen.

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

So props able parent components to deliver data to child components.

function Parent() {
  return (
      <Child data="this is props for child!"/>
  )
}

function Child(props) {
  return <h1>{props.data}</h1>
}

Props have 2 major characteristics.

1. Immutable

props must be read-only they should not be modified when passed to other components.

// 1st example
function Child(props) { // props is 1
  const modified = props.number + 1 ❌

  return <h1>{modified}</h1>
}

It is more easy to understand why props must be immutable according to the fact that props are more likely a reference from parent component. Therefore it is the parent components who owns the data.

// 2nd example
function Child(props) {
  props.data = "I want to change this" ❌

  return <h1>{props.data}</h1>
}

2. Unidirectional

Props must be one-way data flow, which means props need to be passed only from parent components to child components.

Props-drilling occurs when a parent component passes data down to its children and then those children pass the same data down to their own children.

If the depth gets too deep, props-drilling could make React app difficult to manage and maintain.

What are the benefits?

Immutability and unidirection have benefits.

1. comprehend the logic more quickly
2. simplify the data flow

Props is one of the most important concept in React. Those two characteristics keep the React app consistent and reliable in controlling the flow of data between components.

Good bye "var"

Today, I assume most of programmers don't use the "var" variable type anymore. Replacing it by "let" and "const". But why? Just because of "var" is just from old version? This post is to make everybody clear what is difference between them and why "var" is depreciated.

before we start

For those who is new to javascript. There are 3 terminologies we should know when creating a variable.

• Declaration : define variables using const, let, and var.

  var name;
  let age;
  const address;

• Initialization : value is added through the assign operator (=) after the variable is declared.

  var name;
  name = 'minjae'
  

let age; age = 30

- **Assigning** : means declaring a variable and assigning a value at the same time.
```javascript
var name = 'minjae';
let age = 30;
const married = false;

1. Redeclaring variables

var can be declared again with same variable name. let and const can not be declared again with same name.

//example
var name = 'Santa';
var name = 'Pikachu'; // OK

let age = 20;
let age = 30; //SyntaxError: Identifier 'age' has already been declared

const character = 'Mario';
const character = 'Bumble Bee'; //SyntaxError: Identifier 'character' has already been declared

2. Unassigning variables

"var" and "let" can be unassigned during declaration. "const" must be assigned during declaration.

//example
var cat //OK
let squirrel //OK

const spider //SyntaxError: Missing initializer in const declaration

3. Reassigning

"var" and "let" can be reassigned. "const" can not be reassigned.

//example
var name = "Elgol"
let country = "Germany"
const age = 5

//Reassign
name = "minjae" //OK
country = "Korea" //OK

age = 30 //TypeError: Assignment to constant variable.

4. Accessing variables before declaring

what is so bizzare about javascript is that you can access variables before declaring it.

"var" can be accessed before declaring variables. "let" and "const" can not be accessed before declaring variables.

//example
console.log(cat)
console.log(dog)
//console.log(bird)

var cat //OK
let dog 

//result
undefined
console.log(dog)
            ^
ReferenceError: Cannot access 'dog' before initialization

Hoisting

The phenomenon above is called Hoisting. It works as if the variables have been lifted to the top.

Hoisting is JavaScript's default behavior of moving all declarations to the top of the current scope.

Variables declared by var are subject to the declaration and initialization stages at once. That is, the variable is declared in the very first line of code (Actually, space for the variable is secured in the memory) and then initialized to undefined.

// var hoisting example
console.log(movie); //undefined 
var movie = 'Forest Gump';

The let and const variables are also hosted, but they are not initialized to undefined. Therefore it emits error when accessed before them.

// let const hoisting example
console.log(music); 
console.log(music2); 

let music = 'Wonderwall';
const music2 = 'Summer';

//ERROR!!
//ReferenceError: Cannot access 'music' before initialization

Conclusion

As we saw on previous example how each variable type is working, var has high chance of causing errors.

It is recommened using let and const to prevent hoisting and redeclaring problems that you can run application more reliable and safe.