Create a Basic Node.js Server: HTTP Module vs Express

You can build a working Node.js server with zero dependencies. Node ships with an HTTP module and about six lines gets you a running server.

So why does almost every real project use Express?

The honest answer is not "Express is better." It is that the built-in module leaves you to write routing, body parsing, and error handling yourself, and that code is tedious to get right. This guide builds the same server both ways so you can see exactly what Express is doing for you.

The Server with No Dependencies

Create server.js:

1
2
3
4
5
6
7
8
const http = require('http');
const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello from Node');
});
server.listen(3000, () => {
  console.log('Running on http://localhost:3000');
});

Run it:

node server.js

Open http://localhost:3000 and you have a working server. No npm install, no packages, nothing downloaded.

createServer takes a callback that fires on every request. req holds the incoming request, res is what you write back. res.end() sends the response and closes the connection — forget it and the browser hangs waiting.

Where the Built-In Module Starts Hurting

Add a second route and the problem appears:

1
2
3
4
5
6
7
8
9
10
11
12
const server = http.createServer((req, res) => {
  if (req.url === '/' && req.method === 'GET') {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('Home');
  } else if (req.url === '/about' && req.method === 'GET') {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('About');
  } else {
    res.writeHead(404, { 'Content-Type': 'text/plain' });
    res.end('Not found');
  }
});

Two routes, and it is already an if-else chain. Ten routes is unreadable.

It gets worse with URL parameters. There is no built-in way to match /users/42 and extract the 42 — you write string parsing or a regex yourself, for every route.

Reading a POST body is worse still. req is a stream, so you collect it manually:

1
2
3
4
5
6
let body = '';
req.on('data', chunk => { body += chunk; });
req.on('end', () => {
  const data = JSON.parse(body);
  // handle it
});

That is the code you write for every single route that accepts data. And it has no size limit, so a large enough request will exhaust your memory.

None of this is difficult. It is just repetitive, easy to get subtly wrong, and entirely solved already.

The Same Server in Express

npm init -y
npm install express

Then:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
const express = require('express');
const app = express();
app.use(express.json());
app.get('/', (req, res) => {
  res.send('Home');
});
app.get('/about', (req, res) => {
  res.send('About');
});
app.get('/users/:id', (req, res) => {
  res.json({ id: req.params.id });
});
app.post('/users', (req, res) => {
  res.status(201).json({ received: req.body });
});
app.listen(3000, () => {
  console.log('Running on http://localhost:3000');
});

Compare that to the version above. Routing is declarative. :id gives you req.params.id with no parsing. express.json() handles body parsing for every route at once, with a size limit by default. res.json() sets the content type for you.

Express is not doing anything magic. It is a layer over the same http module — you could write all of this yourself. It is that you would be writing it again on every project.

Auto-Reload Without nodemon

Most tutorials tell you to install nodemon. You do not need it any more.

Node has a built-in watch flag:

node --watch server.js

Save a file and the server restarts. No dependency, no config.

nodemon still has its uses for more complex watch setups, but for a basic server the built-in flag covers it. Add it to package.json:

1
2
3
4
"scripts": {
  "dev": "node --watch server.js",
  "start": "node server.js"
}

Then npm run dev in development, npm start in production. Never run --watch in production.

Express 5 vs Express 4

Worth knowing, because it explains why tutorial code sometimes fails.

npm install express now gives you Express 5. Most Express 4 code works unchanged, but a few things differ.

Async errors are handled automatically. In Express 4, a rejected promise inside a route handler would hang the request unless you wrapped it in a try/catch or a helper. Express 5 forwards it to your error handler. This is the biggest practical improvement.

Some methods were removed — res.send(status) and app.del() among them. Use res.sendStatus() and app.delete().

Wildcard route patterns changed. Bare * is no longer valid; named wildcards like /*splat are required.

If you are following an older tutorial and hitting unexpected errors, check which major version you are on with npm list express.

Error Handling

Express error middleware takes four arguments. The fourth is what identifies it as an error handler, so it must be there even if unused:

1
2
3
4
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: 'Something went wrong' });
});

Register this after all your routes. Order matters in Express — middleware runs in the order you declare it.

Add a 404 handler just before it, since a request that matches no route falls through:

1
2
3
app.use((req, res) => {
  res.status(404).json({ error: 'Not found' });
});

When to Skip Express

Express is the default for good reason, but it is not the only answer.

Use the built-in http module when you are writing a health check endpoint, a tiny webhook receiver, or anything where a dependency-free binary matters. Also use it when you are learning — understanding what Express abstracts makes you better at using it.

Consider Fastify when throughput is the constraint. It is meaningfully faster on JSON-heavy workloads and has schema validation built in.

Consider Hono if you are targeting edge runtimes such as Cloudflare Workers, where Express does not run.

And if you are building a full application with a frontend, a framework like Next.js may replace the need for a separate server entirely.

For a standard REST API on a normal Node deployment, Express remains the sensible default. The ecosystem is enormous and every problem you hit has been solved publicly.

Before You Call It Production-Ready

A basic server is not a deployable one. The gap includes, at minimum:

Environment-based configuration, so the port and any URLs come from environment variables rather than being hardcoded.

Graceful shutdown, so in-flight requests finish when the process receives a termination signal instead of being cut off.

Security headers and rate limiting, usually via helmet and express-rate-limit.

Structured logging that produces machine-readable output rather than console.log.

A process manager or container runtime that restarts the server when it crashes.

Each of those is small on its own. Skipping all of them is how a working prototype becomes a 3am incident.

Where This Fits in a Real Project

The server is the easy part. What takes the time is everything around it — database connections and pooling, authentication, request validation, observability, and a deployment story that lets you ship without holding your breath.

Our team builds and ships production Node.js and TypeScript backends for client software, along with the infrastructure they run on. You can see the stack we work across on our technologies page and browse shipped work in our projects portfolio.

If you are setting up your environment, the NVM on Windows tutorial covers Node version management. Once you have something to deploy, the SSL certificate guide handles TLS on Nginx in front of it.

More walkthroughs are on the tutorials hub, and longer technical writing lives on the blog.