PHASE 2 — Topic 6: Why Socket.IO Needs a Persistent Server, and How This Fits Into Next.js

Before we write a single line of Socket.IO code, we need to understand a very important architectural fact. This is the part beginners often skip, and then get stuck later wondering why their Socket.IO code "just doesn't work" once deployed. Let's clear this up properly.

How Next.js Normally Runs

By default, modern Next.js is built around serverless functions and Automatic Static Optimization. When you deploy a Next.js app to a platform like Vercel, most of your code does not run on one continuously running server. Instead:

• Each request spins up a function
• That function handles the request
• Once it responds, it shuts down again

This is great for performance, cost, and scaling, since you only pay for what you use, and idle time costs nothing.

Why This Breaks Socket.IO

Socket.IO, as we learned earlier, needs a connection that stays open continuously, so the server can push data to the client at any time. But serverless functions are the opposite of that. They are designed to start, respond, and terminate as quickly as possible. They are not meant to hold a connection open and wait.

This creates a direct conflict:

• Socket.IO needs: one server, staying alive, holding open connections
• Default Next.js deployment gives you: many short-lived functions, spun up per request

Because of this, a serverless function simply cannot hold a Socket.IO (or any WebSocket) connection open. The function terminates almost immediately after responding, closing any connection along with it.

The Solution: A Custom Server

To make Socket.IO work with Next.js, we need a custom server. This means we do not let Next.js manage its own server internally. Instead, we create our own Node.js server, and tell Next.js to run inside it.

Here is the important part: this custom server does not replace Next.js. It wraps around it. The same server handles two jobs at once:

1. It runs the normal Next.js request handler, for all your pages and routes
2. It also runs the Socket.IO server, attached to the exact same underlying HTTP server

Both share one persistent Node.js process, which stays running continuously instead of spinning up and down per request.

The Trade-off You Must Accept

Using a custom server is not free. It comes with a real trade-off, and you should know this upfront:

• You lose Automatic Static Optimization for parts of your app that rely on it
• You lose the ability to deploy on Vercel using its standard serverless deployment, since Vercel's serverless functions cannot hold WebSocket connections open
• Your app now needs to run on a platform that supports long-running Node.js processes, such as a VPS, Render, Railway, Fly.io, AWS EC2, or a Docker container

Because of this trade-off, some production teams choose a different architecture entirely: keeping Next.js on Vercel as normal, and running the Socket.IO server as a completely separate service (often built with Express), which the Next.js frontend simply connects to as a client. Both approaches are valid. For this course, since our focus is learning Socket.IO itself deeply, we will use the simpler combined custom server approach, where Next.js and Socket.IO share one server.

How the Combined Server Works, Conceptually

Here is the mental model before we see actual code in the next post:

Request comes in
      |
      v
+--------------------+
|   Node.js Server    |
|  (server.ts file)   |
+--------------------+
      |          |
      v          v
  Next.js     Socket.IO
  handles     handles
  pages &     real-time
  routes      events

Both Next.js and Socket.IO listen on the same HTTP server, on the same port. Regular page requests go to Next.js. WebSocket upgrade requests go to Socket.IO. They coexist peacefully on the same process.

Where This File Lives

In the next post, we will create this custom server as a file called server.ts at the root of the project, outside the src/app folder. This file will become the actual entry point of our application from now on, replacing the default next start behavior.

Summary

• Next.js normally runs on short-lived serverless functions, which cannot hold a Socket.IO connection open
• Socket.IO needs one continuously running server, since it depends on persistent, long-lived connections
• The solution is a custom server, a Node.js process that runs Next.js and Socket.IO together on the same HTTP server
• This approach removes automatic serverless deployment on platforms like Vercel, and requires a host that supports long-running processes
• Some production apps instead run Socket.IO as a fully separate service, but this course uses the combined custom server approach for simplicity

In the next post, we will actually build this custom server, step by step, using TypeScript.