¿Qué es MERN?

Definición

MERN es una pila (stack) de cuatro tecnologías de código abierto para construir aplicaciones web completas con un solo lenguaje, JavaScript:

Una aplicación full stack abarca las tres capas: lo que el usuario ve, el servidor que aplica las reglas del negocio y el lugar donde se guardan los datos. MERN cubre las tres sin cambiar de lenguaje, y los datos viajan entre ellas en el mismo formato: JSON.

Arquitectura de tres capas

MERN sigue el modelo cliente-servidor en tres capas (three-tier architecture). Cada capa tiene una responsabilidad y solo habla con la vecina:

Dos consecuencias prácticas:

• El navegador nunca habla con la base de datos. Todo pasa por la API de Express, que es la única que conoce las credenciales de MongoDB. Si React se conectara directo, cualquiera podría leer la contraseña desde el navegador.
• Cada capa se puede reemplazar o escalar por separado. El frontend se publica como archivos estáticos (Vercel), la API como un servicio (Render) y la base como un clúster administrado (Atlas). Es exactamente como publicaremos el proyecto en el módulo 7.

El recorrido de un pedido

Así viaja un pedido de la taquería, de la pantalla a la base de datos y de regreso:

1. React arma el pedido con lo que el cliente eligió y lo envía con fetch: método POST, ruta /api/pedidos, cuerpo en JSON.
2. La petición HTTP viaja por internet hasta el servidor.
3. Node.js recibe la conexión y Express la dirige a la función que atiende POST /api/pedidos. Antes pasan los middleware: leer el JSON, comprobar la sesión, validar los datos.
4. La función guarda el pedido en MongoDB (con Mongoose, desde el módulo 5) y la base le devuelve el documento con su identificador.
5. Express responde 201 Created con el pedido guardado en JSON.
6. React recibe la respuesta, actualiza su estado y la pantalla muestra «Pedido recibido» sin recargar la página.

En el código, los pasos 1, 5 y 6 se ven así (la práctica del final los ejecuta completos):

// React (paso 1): enviar el pedido
const respuesta = await fetch("/api/pedidos", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ platillo: "Tacos al pastor", cantidad: 3 }),
});
// paso 6: leer la respuesta
console.log(respuesta.status, await respuesta.json());
// 201 { id: 1, platillo: 'Tacos al pastor', cantidad: 3, estado: 'recibido' }

JSON: el idioma común

JSON (JavaScript Object Notation, estándar ECMA-404 y RFC 8259) es un formato de texto para representar datos. Se parece a un objeto de JavaScript, pero no es lo mismo: es lo que viaja por la red, y del otro lado hay que convertirlo de vuelta en objeto.

JSON solo admite seis tipos de valor: cadena, número, booleano, null, arreglo y objeto. Lo demás se transforma o se pierde al convertir:

Esto importa en MERN porque los datos cruzan dos veces la frontera de texto (navegador → API → base de datos). MongoDB guarda internamente BSON, una versión binaria de JSON con más tipos (fechas reales, ObjectId, números decimales), y Mongoose se encarga de convertir en el módulo 5.

Por qué un solo lenguaje

Los límites también existen: JavaScript es de tipado dinámico (los errores de tipo aparecen al ejecutar; por eso el siguiente paso natural es TypeScript), y Node.js corre el código de JavaScript en un solo hilo, así que los cálculos pesados de CPU bloquean el servidor si no se mandan a otro proceso.

MERN frente a otras pilas

La decisión entre MongoDB y una base SQL la explicamos a fondo en Bases de datos: SQL y NoSQL.

Cuándo usar MERN y cuándo no

Conviene cuando:

• La app tiene usuarios, formularios y datos que cambian seguido: pedidos, reservas, catálogos, paneles internos.
• La estructura de los datos todavía se está descubriendo (MongoDB no exige definir tablas antes).
• Quieres que una sola persona o un equipo pequeño cubra frontend y backend.
• Necesitas una interfaz muy interactiva: carritos, filtros en vivo, tableros.

Mejor otra opción cuando:

• Los datos son muy relacionales y la consistencia es crítica (contabilidad, banca): PostgreSQL encaja mejor.
• El sitio es casi todo contenido y vive de Google: un generador estático o Next.js con renderizado en servidor.
• El trabajo pesado es de cálculo o ciencia de datos: Python suele tener mejores herramientas.

El proyecto del curso: Taquería en línea

A lo largo de los 8 módulos construimos un sistema de pedidos real. Requisitos:

API prevista (se construye en los módulos 4 a 6):

El código completo vive en el repositorio público ruta-mern-taqueria, con una carpeta por módulo.

Ruta de módulos

Práctica: prepara tu entorno y recorre un pedido

1. Instala Node.js LTS desde nodejs.org. Incluye npm.
2. Instala un editor: Visual Studio Code.
3. Instala Git (lo usamos a fondo en el módulo 2).
4. Comprueba las versiones en una terminal:

node -v   # v22 o superior (este módulo se probó con v24.14.1)
npm -v
git --version

1. Crea el archivo recorrido.mjs con este contenido. Es un servidor y un cliente en el mismo archivo, sin instalar nada: el servidor hace el papel de Express y MongoDB (por ahora guarda en memoria) y el fetch del final hace el papel de React.

// recorrido.mjs — el viaje completo de un pedido, solo con Node (sin instalar nada).
// El servidor hace de Express + MongoDB; el fetch del final hace de React.
import http from "node:http";

const pedidos = []; // por ahora, la "despensa" vive en memoria

const servidor = http.createServer((req, res) => {
  if (req.method === "POST" && req.url === "/api/pedidos") {
    let cuerpo = "";
    req.on("data", (trozo) => (cuerpo += trozo));
    req.on("end", () => {
      const pedido = { id: pedidos.length + 1, ...JSON.parse(cuerpo), estado: "recibido" };
      pedidos.push(pedido);
      res.writeHead(201, { "Content-Type": "application/json" });
      res.end(JSON.stringify(pedido));
    });
    return;
  }
  res.writeHead(404, { "Content-Type": "application/json" });
  res.end(JSON.stringify({ error: "Ruta no encontrada" }));
});

servidor.listen(3000, async () => {
  console.log("Cocina abierta en http://localhost:3000");
  const respuesta = await fetch("http://localhost:3000/api/pedidos", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ platillo: "Tacos al pastor", cantidad: 3 }),
  });
  console.log(respuesta.status, await respuesta.json());
  servidor.close();
});

1. Ejecútalo:

node recorrido.mjs

Salida esperada:

Cocina abierta en http://localhost:3000
201 { id: 1, platillo: 'Tacos al pastor', cantidad: 3, estado: 'recibido' }

Ya recorriste las tres capas: un cliente que envía JSON, un servidor que lo recibe, lo guarda y responde 201. En los siguientes módulos cada pieza se cambia por la herramienta profesional: React en lugar del fetch suelto, Express en lugar de http y MongoDB en lugar del arreglo en memoria.

Quiz del módulo

¿Qué imprime este código?

const pedido = { taco: "pastor", salsa: undefined, total: 45 };
console.log(JSON.stringify(pedido));

1. {"taco":"pastor","salsa":undefined,"total":45}
2. {"taco":"pastor","salsa":null,"total":45}
3. {"taco":"pastor","total":45}
4. Un error

Respuesta: 3. JSON no tiene undefined. Al convertir un objeto, JSON.stringify omite las propiedades cuyo valor es undefined (también las funciones y los símbolos). Por eso salsa desaparece y el servidor nunca se entera de que existía. Si necesitas mandar «sin salsa», usa null o false: esos valores sí existen en JSON. Pruébalo tú: node -e 'console.log(JSON.stringify({taco:"pastor",salsa:undefined,total:45}))'.

Referencias

• MongoDB: documentación oficial
• Express: guía oficial
• React: documentación oficial
• Node.js: documentación oficial
• MDN: JSON.stringify()
• RFC 8259: The JSON Data Interchange Format
• MDN: visión general del protocolo HTTP