What Is the MERN Stack? How a Web Request Travels

The MERN stack is a popular way to build a complete web application using one language, JavaScript, from the screen the visitor sees to the database that keeps the data. The four letters are four tools: MongoDB, Express, React and Node.js. In this course you will use all four to build a real application, a job tracker where a person signs in, adds the jobs they applied for, searches and filters them, attaches the resume they sent, and sees simple numbers about their search. At the end you will put it on a server on the internet.

You do not need to know any of the four tools yet. You do need to be able to read basic JavaScript: variables, functions and objects. The next three lessons refresh the parts of modern JavaScript that every MERN app uses, so if you are rusty, you are in the right place. Every lesson comes with the exact source code for that point in the project, as a zip you can download from the top of the lesson, so you can always compare your work with a working copy.

The four parts and what each one is for

• React runs in the visitor's browser. It draws the screens: lists, forms, buttons. It does not store anything permanently, because everything in the browser can be closed, cleared or changed by the visitor.
• Node.js is JavaScript running on a server, outside the browser. It is the engine that runs your back end code.
• Express is a small library that sits on top of Node.js. It receives requests such as “give me my jobs” and lets you write the code that answers them. A group of such answers is called an API.
• MongoDB is the database. It keeps the information safely on disk: people, jobs, notes. The server asks it for data and tells it what to save.

People often call React the front end and Node.js with Express the back end. The database is a third layer behind the back end. The important rule is this: the browser never talks to the database directly. It talks to your API, and your API talks to the database. That gap is where you check who the person is, what they are allowed to do, and whether the data they sent makes sense.

The journey of one request

Suppose a signed-in person opens the “My jobs” page. Here is what happens, step by step.

1. The browser loads the React app, which is just JavaScript, HTML and CSS files. React draws the page frame and shows “Loading…”.
2. React calls fetch('/api/jobs'). This is an HTTP request: a message with a method (GET), a path (/api/jobs) and some headers, one of which says who is asking.
3. The request travels over the internet to your server, where Node.js is listening. Express looks at the method and path and picks the matching route.
4. The route checks the headers, finds the person, and asks MongoDB: “find the jobs that belong to this person”.
5. MongoDB returns the documents. Express turns them into JSON, a text format both sides understand, and sends an HTTP response with a status code such as 200.
6. React receives the JSON, saves it in its state, and draws one card for every job. Loading is gone, jobs are on the screen.

Every feature in this course is a variation on this journey. Adding a job sends data the other way. Signing in sends an email and a password and gets back a token. Uploading a resume sends a file. Once the journey is clear in your head, MERN stops looking like four separate technologies and becomes one idea repeated.

See it run: a request in 40 lines

Before installing anything, run this script. It uses only Node.js. It plays all three roles: a “database” (an array), a “server” (Node's built-in http module) and a “browser” (the built-in fetch). Each one prints what it is doing, so you can read the journey in your terminal.

// Lesson 1: follow one request through a full stack app, using only Node.js (no libraries).
// Run it:  node examples/01-request-flow/trace.js
//
// The three players are the same ones a MERN app has:
//   browser  -> asks for data      (React runs here)
//   server   -> receives the call  (Node.js + Express run here)
//   database -> keeps the data     (MongoDB runs here; we fake it with an array)
import http from 'node:http';

const database = [
  { id: 1, company: 'Acme Logistics', role: 'Dispatcher', status: 'applied' },
  { id: 2, company: 'Northwind Bank', role: 'Teller', status: 'interview' },
];

const log = (who, what) => console.log(`[${who.padEnd(8)}] ${what}`);

const server = http.createServer((req, res) => {
  log('server', `received ${req.method} ${req.url}`);
  if (req.method === 'GET' && req.url === '/api/jobs') {
    log('server', 'asking the database for all jobs');
    const jobs = database; // in a real app this is a MongoDB query
    log('database', `found ${jobs.length} documents`);
    res.setHeader('Content-Type', 'application/json');
    res.end(JSON.stringify(jobs));
    log('server', 'sent the jobs back as JSON');
    return;
  }
  res.statusCode = 404;
  res.end('Not found');
});

server.listen(0, async () => {
  const { port } = server.address();
  log('browser', `calling GET http://localhost:${port}/api/jobs`);
  const response = await fetch(`http://localhost:${port}/api/jobs`);
  const jobs = await response.json();
  log('browser', `got status ${response.status} and ${jobs.length} jobs`);
  for (const job of jobs) log('browser', `draw a card: ${job.role} at ${job.company} (${job.status})`);
  server.close();
});

The output follows the same order as the list above: the browser calls, the server receives, the database answers, the server replies, the browser draws a card for every job. In the real project the “database” becomes MongoDB, the “server” becomes Express (which saves you from writing the routing by hand), and the “browser” part becomes React components. Nothing else about the shape changes.

Why use the same language everywhere?

Using JavaScript on both sides has real, practical benefits for a learner. You learn one language instead of three. You can move code between the two sides, such as a function that checks an email address. The data you send, JSON, is already JavaScript's own format, so there is no translation step. And the huge package ecosystem, npm, serves both sides.

It is also fair to say what MERN is not. It is not the only good choice, and it is not always the best one: large teams often prefer TypeScript, a SQL database, or a framework such as Next.js. The ideas you learn here carry over to all of them: routes, middleware, schemas, tokens, state, effects and deployment are the same ideas with different names.

Your task

1. Download the solution zip for this lesson and unzip it.
2. Open a terminal in the unzipped folder and run node examples/01-request-flow/trace.js.
3. Change the database array: add a third job. Run the script again and check that a third card line appears.
4. Add a new route in the script: GET /api/jobs/count that answers { count: 3 }, and call it with a second fetch. This is your first API route.

How to check it worked

• You see lines tagged [browser], [server] and [database] in the order of the journey.
• The browser line says got status 200 and the right number of jobs.

Summary

• React draws screens in the browser. Express on Node.js answers requests. MongoDB stores data.
• The browser never talks to the database. It talks to your API.
• Every feature is a request and a response with a status code, usually carrying JSON.