Cómo aprender desarrollo backend en 2026: guía práctica completa

Lo que ocurre detrás de cada clic

Cuando inicias sesión en una aplicación, pagas una compra o recibes una notificación, la parte visible es apenas la superficie. Detrás hay servidores que reciben la petición, validan quién eres, consultan bases de datos, aplican reglas de negocio, llaman a otros servicios y devuelven una respuesta en milisegundos. Ese mundo invisible es el backend, y quienes lo construyen son responsables de que todo funcione de forma rápida, segura y fiable.

Entender qué es el desarrollo backend va más allá de saber programar un servidor HTTP. Incluye diseñar APIs, modelar datos, proteger información sensible, empaquetar aplicaciones, configurar servidores, automatizar despliegues y vigilar que el sistema siga en pie cuando el tráfico se multiplica. Puede parecer mucho, pero se aprende por capas, y cada capa se apoya en la anterior.

Esta guía propone una ruta práctica y actualizada. Verás qué habilidades son imprescindibles y cuáles puedes dejar para más adelante, cómo elegir un lenguaje y construirás paso a paso una API con Node.js 24, Express 5 y PostgreSQL 18, la empaquetarás con Docker, la pondrás detrás de nginx y automatizarás sus pruebas y despliegues con GitHub Actions. Al final encontrarás los errores más habituales, cómo resolverlos y una hoja de ruta para seguir creciendo.

Qué hace el backend y cómo encaja con el frontend

Una aplicación web moderna suele dividirse en dos grandes partes. El frontend es lo que se ejecuta en el navegador o en el móvil: la interfaz, las animaciones, los formularios. El backend se ejecuta en servidores remotos y se encarga de los datos y la lógica que no puede confiarse al cliente.

El recorrido de una petición típica ayuda a entender el reparto de responsabilidades:

Navegador ──HTTPS──> CDN / balanceador ──> nginx (proxy inverso)
                                              │
                                              ▼
                                      API (Node.js, Python, Go...)
                                        │            │
                                        ▼            ▼
                                  PostgreSQL       Redis
                                 (datos durables)  (caché, sesiones)

El navegador envía una petición. Un balanceador o una CDN la recibe, nginx la reenvía a la aplicación, la API valida la entrada, consulta la base de datos o la caché y devuelve una respuesta, normalmente en formato JSON.

No necesitas dominar el frontend para trabajar en backend, aunque conocer lo básico de HTTP, HTML y JavaScript en el navegador facilita mucho la colaboración. Lo que sí necesitas es pensar en términos de rendimiento, consistencia de datos, seguridad y capacidad de respuesta bajo carga, preocupaciones que en el cliente apenas aparecen.

Habilidades mínimas y habilidades recomendadas

Es fácil abrumarse con la cantidad de tecnologías del ecosistema. Conviene separar lo que necesitas para empezar de lo que puedes aprender sobre la marcha.

Las habilidades mínimas para trabajar en un proyecto real son:

• Un lenguaje de servidor y su ecosistema de paquetes.
• HTTP: métodos, códigos de estado, cabeceras, cookies y el modelo de petición y respuesta.
• Bases de datos: SQL como mínimo, con nociones de modelado y transacciones.
• Control de versiones con Git y flujo de trabajo con ramas y pull requests.
• Manejo básico de la terminal de Linux y conexión por SSH.

Las habilidades recomendadas, que marcan la diferencia a medio plazo, incluyen:

• Contenedores con Docker y orquestación local con Docker Compose.
• Servidores web y proxys inversos como nginx.
• Integración y despliegue continuos.
• Caché con Redis y colas de mensajes.
• Seguridad: autenticación, autorización y las vulnerabilidades más comunes.
• Observabilidad: registros estructurados, métricas y trazas.
• Escalado horizontal, balanceo de carga y CDN.

El orden importa menos que la constancia. Una buena estrategia es construir un proyecto pequeño e ir añadiéndole capas: primero una API, después una base de datos, luego autenticación, contenedores, despliegue y monitorización.

Elegir un lenguaje backend

Saber elegir un lenguaje backend depende de tu contexto más que de rankings. Todos los lenguajes populares sirven para construir APIs robustas; lo que cambia es el ecosistema, el rendimiento y el tipo de empresas que los usan.

Si ya conoces JavaScript, Node.js es el camino con menos fricción, y es el que usaremos en los ejemplos. Para producción conviene una versión LTS: Node.js 24 sigue en soporte de mantenimiento y Node.js 26 pasa a ser la nueva LTS a finales de octubre de 2026.

Lo más importante es profundizar en un lenguaje antes de saltar al siguiente. Los conceptos de backend se transfieren entre ecosistemas, y aprender un segundo lenguaje resulta mucho más sencillo cuando dominas el primero.

Tu primera API con Node.js y Express 5

Vas a construir una API para gestionar reservas de salas de reuniones. La estructura del proyecto es la siguiente:

api-reservas/
├── src/
│   ├── app.js
│   ├── servidor.js
│   ├── db.js
│   ├── rutas/
│   │   └── reservas.js
│   └── middleware/
│       └── autenticacion.js
├── migraciones/
│   └── 001_reservas.sql
├── tests/
│   └── reservas.test.js
├── Dockerfile
├── compose.yaml
├── package.json
└── .env.example

Inicializa el proyecto e instala las dependencias:

mkdir api-reservas && cd api-reservas
npm init -y
npm pkg set type=module
npm install express@5 pg jose redis

Separar la definición de la aplicación del arranque del servidor facilita las pruebas automáticas. src/app.js define rutas y middleware:

import express from "express";
import { rutasReservas } from "./rutas/reservas.js";

export function crearApp() {
    const app = express();
    app.disable("x-powered-by");
    app.use(express.json({ limit: "100kb" }));

    app.get("/salud", (req, res) => res.json({ estado: "ok" }));
    app.use("/api/reservas", rutasReservas);

    app.use((req, res) => res.status(404).json({ error: "No encontrado" }));

    app.use((error, req, res, next) => {
        console.error(error);
        res.status(error.status ?? 500).json({
            error: error.expose ? error.message : "Error interno",
        });
    });

    return app;
}

Y src/servidor.js solo se encarga de escuchar en el puerto y de cerrar ordenadamente:

import { crearApp } from "./app.js";
import { pool } from "./db.js";

const puerto = Number(process.env.PORT) || 3000;
const servidor = crearApp().listen(puerto, () => {
    console.log(`API escuchando en el puerto ${puerto}`);
});

process.on("SIGTERM", () => {
    servidor.close(async () => {
        await pool.end();
        process.exit(0);
    });
});

Un detalle útil de Express 5: si una función asíncrona de una ruta lanza un error o devuelve una promesa rechazada, el framework lo envía automáticamente al middleware de errores. En Express 4 había que capturarlo a mano con try/catch o envolver cada ruta.

Diseñar una API REST clara

REST es el estilo más extendido para APIs HTTP. Se basa en recursos identificados por URL y en usar los métodos HTTP según su significado:

Los códigos de error también comunican significado: 400 para datos inválidos, 401 cuando falta autenticación, 403 cuando el usuario no tiene permiso, 404 si el recurso no existe, 409 ante conflictos, como una sala ya reservada, y 500 para fallos inesperados del servidor.

Además de REST, conviene conocer GraphQL, que permite al cliente pedir exactamente los campos que necesita, y gRPC, muy usado para la comunicación eficiente entre microservicios. Para empezar, REST bien diseñado cubre la gran mayoría de casos.

Documenta tu API desde el principio con la especificación OpenAPI. Un archivo de descripción permite generar documentación interactiva, clientes y pruebas de contrato:

openapi: 3.1.0
info:
    title: API de reservas
    version: 1.0.0
paths:
    /api/reservas:
        post:
            summary: Crear una reserva
            responses:
                "201":
                    description: Reserva creada
                "409":
                    description: La sala ya está ocupada en ese horario

Persistir datos con PostgreSQL

Casi todo backend necesita guardar información de forma duradera. PostgreSQL, cuya versión estable actual es la 18, es una de las bases de datos relacionales más completas y una excelente elección por defecto. Define primero el esquema en un archivo de migración:

-- migraciones/001_reservas.sql
CREATE TABLE reservas (
  id          BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  sala        VARCHAR(50)  NOT NULL,
  responsable VARCHAR(100) NOT NULL,
  inicio      TIMESTAMPTZ  NOT NULL,
  fin         TIMESTAMPTZ  NOT NULL,
  creada_en   TIMESTAMPTZ  NOT NULL DEFAULT now(),
  CHECK (fin > inicio)
);

CREATE INDEX idx_reservas_sala_inicio ON reservas (sala, inicio);

El módulo src/db.js crea un pool de conexiones reutilizables a partir de una variable de entorno:

import pg from "pg";

export const pool = new pg.Pool({
    connectionString: process.env.DATABASE_URL,
    max: 10,
});

Las rutas usan siempre consultas parametrizadas, nunca texto concatenado. Es la defensa principal contra la inyección SQL:

import { Router } from "express";
import { pool } from "../db.js";
import { exigirUsuario } from "../middleware/autenticacion.js";

export const rutasReservas = Router();

rutasReservas.get("/", async (req, res) => {
    const { rows } = await pool.query(
        "SELECT id, sala, responsable, inicio, fin FROM reservas ORDER BY inicio LIMIT 100"
    );
    res.json(rows);
});

rutasReservas.post("/", exigirUsuario, async (req, res) => {
    const { sala, inicio, fin } = req.body ?? {};
    if (!sala || !inicio || !fin) {
        return res
            .status(400)
            .json({ error: "sala, inicio y fin son obligatorios" });
    }

    const solape = await pool.query(
        "SELECT 1 FROM reservas WHERE sala = $1 AND inicio < $3 AND fin > $2",
        [sala, inicio, fin]
    );
    if (solape.rowCount > 0) {
        return res
            .status(409)
            .json({ error: "La sala ya está ocupada en ese horario" });
    }

    const { rows } = await pool.query(
        `INSERT INTO reservas (sala, responsable, inicio, fin)
     VALUES ($1, $2, $3, $4) RETURNING *`,
        [sala, req.usuario.nombre, inicio, fin]
    );
    res.status(201).json(rows[0]);
});

Observa que en Express 5 req.body es undefined si la petición no trae cuerpo, por eso se usa req.body ?? {}. En Express 4 era un objeto vacío.

Las bases de datos NoSQL, como MongoDB, encajan cuando la estructura de los datos varía mucho o el patrón de acceso es muy simple. Redis, por su parte, es el complemento habitual de una base relacional: guarda en memoria datos de acceso frecuente, sesiones o contadores con latencias de microsegundos. En la mayoría de proyectos, empezar con PostgreSQL y añadir Redis cuando las mediciones lo justifiquen es la decisión más sensata.

Autenticación y autorización

La autenticación responde a la pregunta “¿quién eres?” y la autorización a “¿qué puedes hacer?”. Son dos de las áreas donde más errores de seguridad se cometen, así que conviene apoyarse en primitivas probadas en lugar de inventar soluciones propias.

Las contraseñas nunca se guardan en texto plano ni con funciones de hash rápidas como SHA-256. Se usan algoritmos lentos diseñados para este fin, como Argon2, bcrypt o scrypt. Node.js incluye scrypt de forma nativa:

import { randomBytes, scrypt, timingSafeEqual } from "node:crypto";
import { promisify } from "node:util";

const scryptAsync = promisify(scrypt);

export async function hashContrasena(contrasena) {
    const sal = randomBytes(16);
    const derivada = await scryptAsync(contrasena, sal, 64);
    return `${sal.toString("hex")}:${derivada.toString("hex")}`;
}

export async function verificarContrasena(contrasena, almacenada) {
    const [salHex, hashHex] = almacenada.split(":");
    const derivada = await scryptAsync(
        contrasena,
        Buffer.from(salHex, "hex"),
        64
    );
    return timingSafeEqual(derivada, Buffer.from(hashHex, "hex"));
}

Para mantener la sesión existen dos enfoques principales. Las sesiones en servidor guardan el estado en una base de datos o en Redis y envían al navegador una cookie con un identificador; son fáciles de revocar. Los tokens JWT contienen la identidad firmada y el servidor los verifica sin consultar estado; escalan bien entre servicios, pero revocarlos antes de que expiren exige mecanismos adicionales.

Este middleware verifica un token JWT con la biblioteca jose:

import { jwtVerify } from "jose";

const secreto = new TextEncoder().encode(process.env.JWT_SECRETO);

export async function exigirUsuario(req, res, next) {
    const cabecera = req.get("authorization") ?? "";
    const token = cabecera.startsWith("Bearer ") ? cabecera.slice(7) : null;
    if (!token) return res.status(401).json({ error: "Falta el token" });

    try {
        const { payload } = await jwtVerify(token, secreto, {
            algorithms: ["HS256"],
        });
        req.usuario = {
            id: payload.sub,
            nombre: payload.nombre,
            rol: payload.rol,
        };
        next();
    } catch {
        res.status(401).json({ error: "Token inválido o caducado" });
    }
}

Para aplicaciones con inicio de sesión de terceros, como Google o el proveedor corporativo, usa OAuth 2.0 y OpenID Connect mediante bibliotecas consolidadas o servicios de identidad gestionados.

Pruebas automatizadas

Una API sin pruebas se vuelve frágil a medida que crece. Node.js incluye un ejecutor de pruebas nativo, node:test, que basta para muchos proyectos sin instalar dependencias adicionales:

// tests/reservas.test.js
import { test } from "node:test";
import assert from "node:assert/strict";
import { crearApp } from "../src/app.js";

test("la ruta de salud responde ok", async () => {
    const servidor = crearApp().listen(0);
    const { port } = servidor.address();

    const respuesta = await fetch(`http://localhost:${port}/salud`);
    assert.equal(respuesta.status, 200);
    assert.deepEqual(await respuesta.json(), { estado: "ok" });

    servidor.close();
});

node --test

✔ la ruta de salud responde ok (18.42ms)
ℹ tests 1
ℹ pass 1
ℹ fail 0

Combina pruebas unitarias para la lógica de negocio con pruebas de integración que levantan una base de datos real en un contenedor. Detectan errores que los simulacros nunca revelan, como una restricción mal definida o una consulta lenta.

Contenedores con Docker y Docker Compose

Docker empaqueta la aplicación con todo lo que necesita para ejecutarse, y Docker Compose levanta varios servicios relacionados con un solo comando. Así, todo el equipo trabaja con las mismas versiones de Node, PostgreSQL y Redis, y el entorno de desarrollo se parece mucho al de producción.

El Dockerfile de la API:

FROM node:24-slim
ENV NODE_ENV=production
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY src ./src
USER node
EXPOSE 3000
CMD ["node", "src/servidor.js"]

Y compose.yaml, que define la API, la base de datos y la caché:

services:
    api:
        build: .
        ports:
            - "3000:3000"
        environment:
            DATABASE_URL: postgres://reservas:secreto@db:5432/reservas
            REDIS_URL: redis://cache:6379
            JWT_SECRETO: cambia-esto-en-produccion
        depends_on:
            db:
                condition: service_healthy

    db:
        image: postgres:18
        environment:
            POSTGRES_USER: reservas
            POSTGRES_PASSWORD: secreto
            POSTGRES_DB: reservas
        volumes:
            - datos-db:/var/lib/postgresql
            - ./migraciones:/docker-entrypoint-initdb.d:ro
        healthcheck:
            test: ["CMD-SHELL", "pg_isready -U reservas"]
            interval: 5s
            retries: 10

    cache:
        image: redis:8

volumes:
    datos-db:

Con un solo comando tienes el sistema completo funcionando:

docker compose up -d --build
docker compose ps
curl http://localhost:3000/salud

Los archivos de la carpeta migraciones se ejecutan automáticamente la primera vez que se crea el volumen de PostgreSQL. En proyectos reales, conviene usar una herramienta de migraciones dedicada para aplicar los cambios de esquema de forma versionada.

Un proxy inverso con nginx delante de la aplicación

En producción, la aplicación casi nunca recibe tráfico directamente de internet. Configurar un proxy inverso con nginx delante aporta terminación TLS, compresión, límites de tamaño, caché de archivos estáticos y la posibilidad de repartir el tráfico entre varias instancias. La línea estable actual de nginx es la 1.30.

Una configuración básica para la API de reservas:

upstream api_reservas {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    keepalive 32;
}

server {
    listen 443 ssl;
    http2 on;
    server_name api.ejemplo.com;

    ssl_certificate     /etc/letsencrypt/live/api.ejemplo.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.ejemplo.com/privkey.pem;

    client_max_body_size 1m;
    gzip on;
    gzip_types application/json;

    location / {
        proxy_pass http://api_reservas;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name api.ejemplo.com;
    return 301 https://$host$request_uri;
}

El bloque upstream reparte las peticiones entre dos instancias de la API, y las cabeceras X-Forwarded-* permiten que la aplicación conozca la IP real del cliente y el protocolo original. En Express, activa app.set("trust proxy", 1) para que las utilice. Los certificados TLS gratuitos se obtienen y renuevan automáticamente con Let’s Encrypt.

Antes de recargar nginx, valida siempre la configuración:

sudo nginx -t && sudo systemctl reload nginx

Integración y despliegue continuos

La integración y despliegue continuos automatizan lo que antes se hacía a mano: ejecutar pruebas en cada cambio, construir artefactos y publicarlos. Hace unos años eran populares servicios como Travis CI; hoy GitHub Actions se ha convertido en la opción por defecto para proyectos alojados en GitHub, junto a GitLab CI y otras plataformas.

Este flujo ejecuta las pruebas con una base de datos real en cada pull request y construye la imagen de Docker al fusionar en main:

# .github/workflows/ci.yml
name: CI

on:
    pull_request:
    push:
        branches: [main]

jobs:
    pruebas:
        runs-on: ubuntu-latest
        services:
            postgres:
                image: postgres:18
                env:
                    POSTGRES_USER: reservas
                    POSTGRES_PASSWORD: secreto
                    POSTGRES_DB: reservas
                ports: ["5432:5432"]
                options: >-
                    --health-cmd "pg_isready -U reservas"
                    --health-interval 5s
                    --health-retries 10
        env:
            DATABASE_URL: postgres://reservas:secreto@localhost:5432/reservas
        steps:
            - uses: actions/checkout@v7
            - uses: actions/setup-node@v7
              with:
                  node-version: 24
                  cache: npm
            - run: npm ci
            - run: node --test

    imagen:
        needs: pruebas
        if: github.ref == 'refs/heads/main'
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v7
            - run: docker build -t api-reservas:${{ github.sha }} .

A partir de aquí, el último paso suele publicar la imagen en un registro y desplegarla en la plataforma elegida. Proteger la rama principal para que solo se fusionen cambios con las pruebas en verde es una práctica sencilla que evita muchos incidentes.

Dónde alojar tu backend

Hay tres grandes familias de alojamiento, cada una con su equilibrio entre comodidad y control.

Las plataformas como servicio, como Render, Railway, Fly.io o Google Cloud Run, reciben tu código o tu imagen de Docker y se encargan de servidores, escalado y certificados. Son ideales para empezar y para equipos pequeños.

Los servidores virtuales, en proveedores como DigitalOcean, Hetzner, Linode o las instancias de AWS, Google Cloud y Azure, te dan una máquina Linux completa. Exigen administrar sistema operativo, actualizaciones, nginx y seguridad, pero enseñan muchísimo y ofrecen costes predecibles.

Los servicios gestionados de la nube, como bases de datos administradas, colas, funciones serverless y Kubernetes, permiten construir sistemas grandes delegando la operación de cada pieza. Son la opción habitual en empresas medianas y grandes.

Una progresión razonable para aprender es desplegar primero en una plataforma como servicio, después configurar un servidor virtual desde cero con Docker y nginx, y finalmente explorar los servicios gestionados de un proveedor de nube.

Escalado, caché y observabilidad

Cuando el tráfico crece, la primera tentación es comprar un servidor más grande. Ese escalado vertical funciona hasta cierto punto; más allá, se escala horizontalmente con varias instancias detrás de un balanceador. Para que funcione, la aplicación debe ser sin estado: las sesiones y archivos no pueden vivir en la memoria o el disco de una instancia concreta.

La caché es la optimización más rentable. Este ejemplo guarda en Redis la lista de reservas durante 30 segundos, de modo que la mayoría de peticiones no llegan a la base de datos:

import { createClient } from "redis";

const redis = await createClient({ url: process.env.REDIS_URL }).connect();

export async function listarReservasConCache(consultar) {
    const enCache = await redis.get("reservas:lista");
    if (enCache) return JSON.parse(enCache);

    const datos = await consultar();
    await redis.set("reservas:lista", JSON.stringify(datos), { EX: 30 });
    return datos;
}

Las CDN, como Cloudflare o las de los proveedores de nube, sirven archivos estáticos desde ubicaciones cercanas al usuario y descargan a tus servidores de ese trabajo. Las colas de mensajes permiten mover tareas lentas, como enviar correos o generar informes, fuera del ciclo de petición y respuesta.

Nada de esto sirve si no sabes qué está pasando. La observabilidad se apoya en tres pilares: registros estructurados en JSON, métricas como latencia, tasa de errores y uso de recursos, y trazas distribuidas que siguen una petición a través de varios servicios. OpenTelemetry se ha convertido en el estándar abierto para instrumentar aplicaciones y enviar esos datos a la herramienta de análisis que prefieras.

Seguridad: los fundamentos que no pueden faltar

La seguridad no es una fase final, sino un hábito. Estos son los mínimos para cualquier API en producción:

• Valida toda entrada del usuario en el servidor, aunque el frontend ya la valide.
• Usa siempre consultas parametrizadas o un ORM para evitar inyecciones.
• Guarda contraseñas con algoritmos lentos y sal aleatoria.
• Sirve todo por HTTPS y marca las cookies como HttpOnly, Secure y SameSite.
• Configura CORS de forma explícita, permitiendo solo los orígenes necesarios.
• Aplica límites de peticiones por IP o por usuario para frenar abusos y ataques de fuerza bruta.
• Nunca subas secretos al repositorio; usa variables de entorno o gestores de secretos.
• Mantén las dependencias actualizadas y revisa vulnerabilidades con npm audit o herramientas equivalentes.
• Aplica el principio de mínimo privilegio también a la base de datos: el usuario de la aplicación no necesita permisos de administración.

La lista OWASP Top 10 resume las vulnerabilidades más frecuentes en aplicaciones web y es una lectura obligada para cualquier persona que trabaje en backend.

Errores comunes al empezar en backend

Guardar secretos en el código. Las claves de API y contraseñas en el repositorio acaban filtrándose tarde o temprano. Usa un archivo .env excluido de Git para desarrollo y gestores de secretos en producción.

Ignorar los índices de la base de datos. Una consulta que tarda milisegundos con cien filas puede tardar segundos con un millón. Revisa los planes de ejecución con EXPLAIN ANALYZE y crea índices para los filtros frecuentes.

Abrir una conexión a la base de datos por petición. Es lento y agota las conexiones disponibles. Usa siempre un pool compartido, como en el ejemplo.

Devolver errores internos al cliente. Los mensajes de excepción y trazas revelan detalles de la implementación. Registra el detalle en el servidor y devuelve un mensaje genérico.

Diseñar microservicios demasiado pronto. Dividir un sistema pequeño en muchos servicios multiplica la complejidad operativa. Empieza con un monolito bien organizado y separa componentes solo cuando haya una razón clara.

No pensar en el cierre ordenado. Si la aplicación se detiene en mitad de una petición, puede dejar operaciones a medias. Escucha SIGTERM, deja de aceptar conexiones y cierra el pool de la base de datos antes de salir.

Solución de problemas: errores frecuentes

El puerto ya está en uso:

Error: listen EADDRINUSE: address already in use :::3000

Otro proceso, quizá una instancia anterior de tu API, ocupa el puerto. Localízalo con lsof -i :3000 y termínalo, o arranca en otro puerto con PORT=3001.

La base de datos rechaza la conexión:

Error: connect ECONNREFUSED 127.0.0.1:5432

PostgreSQL no está en marcha o escucha en otra dirección. Dentro de Docker Compose, el host no es localhost sino el nombre del servicio, db en el ejemplo.

Credenciales incorrectas:

error: password authentication failed for user "reservas"

La contraseña de DATABASE_URL no coincide con la del usuario. Recuerda que las variables POSTGRES_* de la imagen oficial solo se aplican al crear el volumen por primera vez; si las cambias después, elimina el volumen o modifica el usuario manualmente.

nginx no alcanza la aplicación:

connect() failed (111: Connection refused) while connecting to upstream

En el navegador se ve como un 502 Bad Gateway. La API no está escuchando en la dirección indicada en upstream. Comprueba que esté en marcha y que el puerto coincida.

El navegador bloquea las peticiones de otro origen:

Access to fetch at 'https://api.ejemplo.com/api/reservas' from origin 'https://app.ejemplo.com' has been blocked by CORS policy

El servidor no devuelve las cabeceras CORS para ese origen. Configura el middleware de CORS permitiendo explícitamente el dominio del frontend; no uses * si envías cookies o credenciales.

Variables de entorno sin definir:

TypeError: Cannot read properties of undefined (reading 'startsWith')

Una variable como DATABASE_URL o JWT_SECRETO no está definida en el entorno. Valida la configuración al arrancar y detén la aplicación con un mensaje claro si falta algo. Node.js permite cargar un archivo de entorno de forma nativa con node --env-file=.env src/servidor.js.

Una hoja de ruta para seguir creciendo

Con lo visto en esta guía tienes una base sólida. Para avanzar, una ruta de aprendizaje backend realista podría seguir estas etapas:

1. Profundiza en tu lenguaje: asincronía, manejo de errores, pruebas y estructura de proyectos.
2. Domina SQL y el modelado de datos: normalización, índices, transacciones y planes de ejecución.
3. Construye y despliega tres o cuatro proyectos completos con autenticación, base de datos y CI/CD.
4. Aprende Docker en profundidad y administra al menos un servidor Linux con nginx desde cero.
5. Incorpora caché, colas de mensajes y trabajos en segundo plano.
6. Estudia seguridad con la lista OWASP y aplícala a tus proyectos.
7. Explora la observabilidad con OpenTelemetry y una herramienta de visualización.
8. Cuando domines lo anterior, acércate a arquitecturas distribuidas, Kubernetes y diseño de sistemas a gran escala.

Publica tus proyectos en GitHub con un README que explique cómo ejecutarlos, decisiones de diseño y cómo se despliegan. Para los equipos que contratan, un proyecto pequeño, bien probado y desplegado vale más que muchos tutoriales completados.

Conclusiones

El desarrollo backend es la disciplina que convierte ideas en sistemas que funcionan de forma fiable para miles o millones de personas. Abarca mucho más que escribir un servidor: diseñar APIs claras, modelar y proteger datos, autenticar usuarios, empaquetar aplicaciones, configurar servidores, automatizar despliegues y observar el comportamiento en producción.

La buena noticia es que todo se aprende por capas. Empieza con un lenguaje y una API sencilla, como la de reservas construida aquí con Node.js 24, Express 5 y PostgreSQL 18. Después añade contenedores con Docker y Compose, coloca nginx delante, automatiza las pruebas con GitHub Actions y, cuando el proyecto lo pida, incorpora caché, colas y observabilidad.

Mantén la seguridad como hábito desde el primer día, mide antes de optimizar y resiste la tentación de complicar la arquitectura antes de tiempo. Con constancia y proyectos reales, pasarás de seguir tutoriales a diseñar sistemas propios, que es exactamente lo que distingue a un desarrollador backend profesional.