I'm primarily a frontend developer. React, Vite, Tailwind etc. that's my world. The backend has always been that thing I knew existed but rarely touched. Today I finally sat down and built my first Express server from scratch, and I want to document everything that actually clicked, including the things that didn't at first.
This isn't exactly a clean tutorial. It's a honest account of what I learned, what troubled me, and what I'd tell myself if I was starting over.
Setting up from zero
First things first:
```in your terminal run
npm init -y
npm install express
Then I created `server.js` and wrote the minimum possible server:
const express = require('express');
const app = express();
app.get('/', (req, res) => {
res.send('Hello world');
});
app.listen(3000, () => {
console.log('Server running on port 3000');
});
```javascript
Run it with `node server.js`, open `http://localhost:3000` in the browser — "Hello world". That's a working HTTP server in about 10 lines.
Let me break down what each part is actually doing.
---
**Breaking down the code**
### `const express = require('express')`
This pulls the Express library from `node_modules` into the current file. `require` is CommonJS — the default module system in Node. You store it in a variable called `express`.
### `const app = express()`
You call `express()` like a function because it is one. It returns an application object — this `app` is your server's control panel. Everything attaches to it.
### The route
app.get('/', (req, res) => {
res.send('Hello world');
});
This registers a route. Let's read it out loud:
"When someone makes a GET request to /, run this function."
req is the request object — everything the client sent you. Their URL, query params, headers, body.
res is the response object — your tools for sending something back.
app.listen(3000, () => { ... })
This starts the server on port 3000. The callback runs once the server is ready — that's why you log there and not outside it.
The req/res naming thing
I assumed req and res were special keywords that Express required. They're not. They're just parameter names.
Express calls your callback with the request object first and the response object second, always. The names are completely up to you:
// All of these work identically
app.get('/', (req, res) => { res.send('ok') });
app.get('/', (request, response) => { response.send('ok') });
app.get('/', (banana, mango) => { mango.send('ok') });
That last one is valid JavaScript. mango holds the response object and .send() works fine on it.
The community standardized on req and res so everyone reading your code immediately knows which is which. Stick with the convention, but knowing it's just a convention makes the whole thing less mysterious.
Reading data from the URL
There are two ways a client can send data in a GET request.
URL parameters
app.get('/user/:id', (req, res) => {
const id = req.params.id;
res.json({ userId: id });
});
The colon before id tells Express that this segment of the URL is a variable. So /user/jeffrey, /user/42, and /user/anything all hit this route. Whatever's in that slot gets stored in req.params.id.
You visit it like: http://localhost:3000/user/jeffrey
For multiple params, it's a slash between them, not a comma:
app.get('/add/:a/:b', (req, res) => {
// correct
});
app.get('/add/:a,:b', (req, res) => {
// wrong — this will not match the way you expect
});
I made the comma mistake. It cost me time.
Query parameters
app.get('/add', (req, res) => {
const a = Number(req.query.a);
const b = Number(req.query.b);
res.json({ sum: a + b });
});
You visit it like: http://localhost:3000/add?a=10&b=5
When to use which:
URL params are for identifying a specific resource — /user/42, /product/air-max. Query params are better for operations, filters, and optional values — /search?q=express, /add?a=10&b=5. For a math operation, query params are the natural fit.
Splitting logic into modules
Instead of writing all my functions inside the server file, I created a separate math.js:
// math.js
function add(a, b) {
return a + b;
}
function mult(a, b) {
return a * b;
}
module.exports = { add, mult };
Then imported it in the server:
js
// server.js
const { add, mult } = require('./math');
This keeps the server file clean. Routes handle HTTP, modules handle logic. Good habit to build early.
---
** CommonJS vs ESModules**
Node has two module systems and I spent time going back and forth between them today.
**CommonJS:**
js
const express = require('express');
module.exports = { add };
**ESModules:**
js
import express from 'express';
export function add(a, b) { return a + b; }
The key differences:
- To use ESM in Node, you need `"type": "module"` in your `package.json`, otherwise Node treats `.js` files as CJS by default
- ESM requires file extensions when importing local files: `./math.js` not `./math`
- You cannot mix them freely. `require` in an ESM file breaks. `import` in a CJS file breaks.
**My recommendation if you're just starting:** stick with CommonJS. No config needed, works out of the box, and the vast majority of Express tutorials and packages are written in it. Switch to ESM when you have a concrete reason to.
---
## Handling POST requests
GET requests carry data in the URL. POST requests carry data in the **body** — like submitting a login form or hitting an API with JSON. You don't want a password showing up in someone's browser history.
js
app.post('/login', (req, res) => {
const { username, password } = req.body;
res.json({ message: Welcome ${username} });
});
But there's a catch. To read `req.body`, you need this line **before** your routes:
js
app.use(express.json());
`app.use()` applies middleware to every incoming request. `express.json()` reads the raw request body and parses it as JSON so you can access it via `req.body`.
I removed this line to see what would happen. Got this:
plaintext
TypeError: Cannot destructure property 'username' of 'req.body' as it is undefined.
Without it, `req.body` is just `undefined`. The middleware is not optional — and it must come before your routes, not after.
To test POST requests, you can't use the browser URL bar. Use **Thunder Client** (VS Code extension) or Postman. Send a POST to `http://localhost:3000/login` with this JSON body:
json
{
"username": "jeffrey",
"password": "velto123"
}
Response:
json
{
"message": "Welcome jeffrey"
}
Small things that made me question my sanity
1. The app.listen callback
// Wrong — logs before the server is ready
app.listen(3000, console.log("Server running on port 3000"));
// Right — logs once the server is actually up
app.listen(3000, () => console.log("Server running on port 3000"));
Without the arrow function, console.log executes immediately when the file loads, not when the server is ready. It's a subtle difference but it matters.
2. res.send() vs res.json()
res.send() is for plain text. res.json() is for objects and structured data. When you're building an API, you almost always want res.json().
3. Not restarting the server
Every time I made a change and wondered why nothing was different — the old server was still running. Fix this once:
node --watch server.js
Built into Node 18+. No install needed. Your server restarts automatically on every file change.
Where I ended up
By the end of the session I had a working Express server with:
- GET routes reading from URL params and query params
- A separate math module with
addandmultfunctions - A POST route reading from
req.body - A solid mental model of how the whole thing fits together
If you're a frontend developer who's been avoiding Express the same way I was — it's genuinely not that far from home. The concepts map to things you already know. A route is just an event listener. Middleware is just a function that runs before your handler. req and res are just objects.
Start with a GET route. Break something. That's how it sticks.
I'm Chinwuba Jeffrey — frontend developer and CEO of Velto, a premium web design agency focused on the African market. I'm documenting my journey going full-stack. Follow along if you're on a similar path.