What I Learned Building My First Express Server

A frontend developer documented their experience building a first Express server from scratch, explaining core concepts like route parameters, query strings, and the `req`/`res` naming convention. The article breaks down the minimal server code line-by-line, clarifies that `req` and `res` are just conventional parameter names, and demonstrates how to handle URL parameters versus query parameters for different use cases.

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. 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. There are two ways a client can send data in a GET request. 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. 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" } 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. By the end of the session I had a working Express server with: add and mult functionsreq.body 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.