Express.js Basics for Beginners

Express.js is a small web framework that runs on Node.js. It gives a server an orderly way to match an HTTP request, run middleware, and send a response. That makes it a useful next step after you can run JavaScript with Node and understand basic HTTP ideas. This Express.js tutorial for beginners builds one mental model rather than treating every method as an isolated command.

Picture a request moving through a line of checkpoints. A logger may observe it, a parser may read JSON, a route may validate input, and a final handler may return data. The order of those checkpoints matters. Once you can trace that journey, Express routing basics become much easier to reason about.

Start with the request-response cycle

A browser, mobile app, or API client sends an HTTP request with a method, path, headers, and sometimes a body. Express places useful representations of those values on the request object. Your handler chooses a status, optional headers, and a body for the response. A GET /notes request might return a JSON list; POST /notes might validate a title and return a newly created record.

Do not begin with a database. Keep an in-memory array so every moving part stays visible. Restarting the process will erase the data, which is acceptable for this exercise. The objective is to distinguish transport concerns from persistence concerns before combining them.

Create the smallest useful server

Install a current supported Node.js release, create a project, install Express, and add one entry file. In that file, create an application, register a health route, and listen on a chosen development port. A health response such as {"status":"ok"} gives you a known-good endpoint before more logic is introduced.

Test it from a browser or an HTTP client and inspect the actual status and body. A console message saying “server started” only proves that the process reached that line; it does not prove the route is reachable. Change the route path deliberately and observe the not-found response. That small failure teaches routing more clearly than copying five successful routes.

Routes describe method plus path

GET /notes and POST /notes are different operations even though the path matches. A parameterised route such as /notes/:id places the captured value in req.params. Query strings such as ?tag=node appear separately in req.query. JSON submitted by a client is available in req.body only after the JSON parsing middleware has run.

That separation prevents vague route code. Use path parameters to identify a resource, query parameters to filter or shape a collection, and a request body to submit structured input. These are conventions rather than absolute laws, but following them makes an API easier for another developer to predict.

Middleware is ordered behaviour

Middleware receives the request, response, and a function commonly named next. It may end the response, modify request state, or pass control onward. A request logger should usually run before routes if it must see every request. JSON parsing must run before handlers that read JSON. A not-found handler belongs after known routes because it should run only when none matched.

A common beginner bug is forgetting to return after sending a response or forgetting to call next(). The first can lead to an attempted second response; the second leaves the request waiting. Read middleware from top to bottom and mark every branch as “responds,” “passes,” or “throws.” This simple annotation exposes incomplete paths.

Build a three-route notes API

1. Add GET /notes to return the current list.
2. Add GET /notes/:id and return 404 when no note matches.
3. Add POST /notes, reject a missing or blank title with 400, and return the created note with 201.

Try valid input, malformed JSON, a blank title, and an unknown identifier. Record what each case returns. Status codes are part of the API contract: 200 indicates a successful read, 201 a created resource, 400 invalid client input, and 404 an absent route or resource. Avoid returning 200 for every result and hiding meaning inside a message string.

Handle errors without hiding them

Operational failures and invalid user input are not the same. Validation belongs close to the boundary so bad input never reaches deeper logic. Unexpected failures should reach error-handling middleware, where the server can log useful internal context and send a limited response. Do not expose stack traces, secrets, or database details to clients.

Asynchronous code deserves deliberate testing. Follow the current Express documentation for the version installed in your project, because error behaviour can differ across major versions. Trigger a controlled failure, confirm the process stays alive, and verify that exactly one response is sent.

Know when your foundation is ready

You have a sound beginner foundation when you can trace one request through every middleware and handler, explain where params, query values, and bodies come from, and predict the result of an unmatched path. You should also be able to add a route without copying an entire tutorial and diagnose a stalled request by checking control flow.

Only then add persistence, authentication, modular routers, or a frontend. Those additions are valuable, but they multiply failure points. For structured study, review SKLI’s Node.js training course, compare the wider course catalogue, or ask about prerequisites.

FAQ

Express becomes approachable when you stop seeing it as a bag of methods and start seeing one ordered request journey. Build a narrow API, test unhappy paths, and add complexity only when you can explain where each request goes.