Node.js y Express: creación de servidores web con rutas, middleware y CRUD

Introducción: por qué Node.js y Express son una base esencial para backend web

La creación de servidores web con Node.js y Express representa una competencia central dentro de la programación web avanzada. Node.js permite ejecutar JavaScript en el lado del servidor, mientras que Express facilita la construcción de servidores web y APIs mediante una estructura clara de rutas, solicitudes HTTP, middleware y respuestas controladas. Esta combinación ayuda al estudiante a comprender cómo una aplicación web deja de ser solamente una interfaz visual y empieza a comunicarse con una capa backend capaz de recibir, procesar y responder solicitudes.

El fundamento técnico de esta sesión está en entender el recorrido de una solicitud HTTP. Un cliente, que puede ser un navegador o una herramienta como Postman, envía una petición al servidor. Express recibe esa petición, revisa si existe una ruta compatible, ejecuta funciones intermedias si corresponde y finalmente envía una respuesta. En ese flujo aparecen conceptos como método HTTP, endpoint, controlador, middleware, parámetros de ruta, cuerpo JSON y código de estado.

El problema real que resuelve este contenido es frecuente en estudiantes que ya conocen JavaScript del lado del navegador, pero todavía no comprenden cómo se construye el backend. Saber manipular el DOM o crear interacciones visuales no basta para construir un sistema web completo. Una aplicación necesita consultar datos, registrar información, actualizar registros y eliminar contenido cuando sea necesario. Para eso se requiere un servidor.

En contexto de producción, esta base se utiliza en sistemas de productos, plataformas educativas, paneles administrativos y aplicaciones interactivas. Aunque una práctica académica puede usar un archivo productos.json como fuente de datos simple, el aprendizaje crítico está en comprender el contrato entre cliente y servidor. Ese contrato se expresa mediante rutas, métodos HTTP y respuestas predecibles.

Decisión técnica crítica: iniciar con un servidor Express básico antes de introducir estructuras más avanzadas. Esta decisión reduce la carga cognitiva y permite observar el flujo esencial: solicitud, ruta, procesamiento y respuesta. Una alternativa descartada para esta sesión sería comenzar directamente con una arquitectura compleja o una base de datos real. Esa alternativa puede ser útil más adelante, pero en esta etapa ocultaría el comportamiento fundamental de Express detrás de demasiadas capas.

Trade-off: usar un archivo JSON simplifica el aprendizaje, pero no representa una solución de persistencia robusta para escenarios reales con muchos usuarios. Aun así, el beneficio pedagógico es alto porque permite observar lectura, escritura, transformación y respuesta sin desviar la sesión hacia administración de bases de datos.

Impacto en rendimiento, seguridad y mantenimiento: comprender rutas y middleware desde el inicio mejora el mantenimiento del servidor, reduce errores al procesar solicitudes y prepara al estudiante para validar el comportamiento antes de conectar un frontend. El impacto a mediano plazo es claro: quien domina este flujo puede avanzar hacia APIs más ordenadas. Quien lo omite suele construir servidores difíciles de probar, con rutas mezcladas y respuestas inconsistentes.

Un error real de industria es desarrollar endpoints sin probarlos de forma aislada. La consecuencia es que los problemas se descubren recién cuando el frontend falla, haciendo más difícil identificar si el error está en la interfaz, en la ruta, en los datos o en el servidor. La deuda técnica potencial aparece cuando las rutas crecen sin orden, los middlewares se colocan en posiciones incorrectas o las respuestas no siguen una lógica común.

Concepto clave

Un servidor Express recibe solicitudes HTTP y responde según rutas definidas.

Error común

Creer que Node.js y Express son lo mismo. Node.js es el entorno de ejecución; Express es el framework que simplifica la creación del servidor.

Buena práctica

Validar primero el servidor y sus rutas antes de conectarlo con una interfaz frontend.

Aplicación real

Un sistema de delivery universitario puede usar rutas para listar productos, registrar pedidos, actualizar precios y eliminar elementos del catálogo.

Instalación y configuración de Node.js y Express

Node.js es un entorno de ejecución para JavaScript construido sobre el motor V8 de Chrome. Su función principal en esta sesión es permitir que JavaScript se ejecute fuera del navegador, específicamente en el lado del servidor. Esta idea cambia la forma en que el estudiante entiende JavaScript: ya no es solo un lenguaje para botones, formularios y efectos visuales, sino también una herramienta para construir backend.

La instalación de Node.js se realiza desde el sitio oficial y se recomienda usar la versión LTS vigente. LTS significa Long Term Support, es decir, soporte de largo plazo. Para una clase universitaria, esta elección es importante porque prioriza estabilidad sobre experimentación. Después de instalar Node.js, se verifica el entorno usando los comandos node -v y npm -v. El primero confirma la versión de Node.js y el segundo confirma la versión de npm, el gestor de paquetes que se instala junto con Node.js.

El problema que resuelve esta configuración es la preparación del entorno. Sin Node.js instalado correctamente, no se puede ejecutar JavaScript en servidor. Sin npm, no se pueden gestionar dependencias como Express. En una práctica real, muchos errores no nacen del código, sino de una instalación incompleta, una terminal mal ubicada o un comando copiado con caracteres incorrectos.

Express se instala dentro de la carpeta del proyecto mediante npm install express. Este comando registra Express como dependencia y permite usarlo desde el archivo principal del servidor. La estructura mínima inicia con una carpeta de proyecto, un archivo package.json, la carpeta node_modules y un archivo app.js donde se escribe el servidor.

Decisión técnica crítica: crear el proyecto desde terminal para que el estudiante observe cada paso: carpeta, inicialización, instalación y archivo principal. Una alternativa descartada sería entregar un proyecto ya armado. Esa alternativa ahorra tiempo, pero reduce la comprensión de cómo se prepara un entorno backend desde cero.

Trade-off: trabajar desde terminal puede ser más lento al inicio, especialmente para estudiantes nuevos, pero fortalece la autonomía técnica. La ventaja es que el estudiante aprende qué comando crea el proyecto, qué comando instala dependencias y qué archivo se ejecuta para levantar el servidor.

Impacto en rendimiento, seguridad y mantenimiento: una instalación correcta evita fallos de ejecución, conflictos de dependencias y proyectos incompletos. Aunque esta sesión no aborda seguridad avanzada, sí establece una base de mantenimiento: cada dependencia debe estar declarada en package.json y cada comando debe ejecutarse en la carpeta correcta.

Una consecuencia a mediano plazo de no dominar esta configuración es depender de proyectos copiados sin entender su estructura. En equipos de desarrollo, esto genera deuda técnica porque los estudiantes o desarrolladores junior no saben reinstalar dependencias, revisar scripts o diagnosticar por qué un servidor no levanta.

Concepto clave

Node.js permite ejecutar JavaScript en el servidor y npm permite instalar dependencias como Express.

Error común

Ejecutar npm install express fuera de la carpeta del proyecto.

Buena práctica

Verificar la instalación con node -v y npm -v antes de crear el servidor.

Aplicación real

Antes de construir un backend para productos, pedidos o usuarios, el entorno debe estar preparado y validado.

Creación del servidor básico con app.js y app.listen

El archivo app.js cumple el papel de punto de entrada del servidor. En una práctica básica con Express, allí se importa el framework, se crea una instancia de aplicación y se indica un puerto de escucha. El código mínimo contiene tres ideas: require para cargar Express, express() para crear la aplicación y app.listen para iniciar el servidor.

El fundamento técnico está en que un servidor debe permanecer escuchando solicitudes. Cuando se ejecuta node app.js, Node.js interpreta el archivo y Express queda esperando conexiones en el puerto definido, por ejemplo 3001. El mensaje en consola confirma que el servidor se inició. Luego el estudiante puede abrir el navegador y acceder a localhost en el puerto indicado.

El problema real que resuelve este paso es pasar de una carpeta de proyecto a un proceso servidor activo. Antes de app.listen, solo hay archivos. Después de app.listen, existe una aplicación backend capaz de recibir solicitudes. Esta diferencia es esencial para comprender la ejecución en servidor.

En contexto de producción, el servidor no se limita a imprimir un mensaje en consola, pero la idea base se mantiene: una aplicación backend debe escuchar solicitudes entrantes. En una práctica universitaria, este paso permite validar rápidamente que Express está instalado, que el archivo principal no tiene errores de sintaxis y que el puerto está disponible.

Decisión técnica crítica: iniciar con un servidor mínimo antes de crear rutas. La alternativa descartada sería escribir inmediatamente un CRUD completo. Eso puede parecer más productivo, pero dificulta identificar errores. Si algo falla, el estudiante no sabrá si el problema está en la instalación, en el puerto, en la ruta, en el middleware o en la lógica del CRUD.

Trade-off: un servidor mínimo no ofrece funcionalidad visible más allá de escuchar solicitudes, pero permite validar la base de ejecución. Esta validación temprana reduce errores acumulados.

Impacto en rendimiento, seguridad y mantenimiento: aunque app.listen por sí solo no define una arquitectura completa, sí marca el inicio del ciclo de vida del servidor. En mantenimiento, tener un punto de entrada claro facilita ubicar dónde se configuran middlewares, rutas y manejo de errores. En seguridad, evita improvisar configuraciones dispersas que luego son difíciles de revisar.

Un error común es interpretar el mensaje Cannot GET / como una falla del servidor. En realidad, ese mensaje aparece cuando el servidor está activo, pero no existe una ruta definida para la raíz. La consecuencia pedagógica de no entender esto es abandonar una práctica correcta por una interpretación equivocada.

Concepto clave

app.listen inicia el servidor y lo deja escuchando solicitudes en un puerto.

Error común

Confundir Cannot GET / con una instalación fallida.

Buena práctica

Primero levantar el servidor mínimo y luego agregar rutas gradualmente.

Aplicación real

Un backend necesita un punto de entrada claro para recibir solicitudes desde navegador, Postman o frontend.

Rutas en Express: método, endpoint y controlador

Las rutas determinan cómo responde el servidor a las solicitudes HTTP. En Express, una ruta básica se define indicando un método, una URL o endpoint y una función controladora. Por ejemplo, app.get permite definir una ruta de lectura mediante el método GET. Dentro de esa ruta, req representa la solicitud del cliente y res permite enviar la respuesta.

El fundamento técnico está en la relación entre URL y comportamiento. Cuando un cliente accede a la raíz del servidor, Express busca una ruta asociada a /. Si existe, ejecuta la función correspondiente. Si el cliente accede a /productos, Express busca una ruta que coincida con ese endpoint. Esta lógica permite que un mismo servidor responda de manera diferente según la ruta solicitada.

El problema real que resuelve este concepto es la organización de respuestas. Sin rutas, el servidor no tiene forma clara de decidir qué hacer ante cada solicitud. Con rutas, se puede separar la respuesta de bienvenida, el listado de productos, la consulta por identificador y otras operaciones.

En producción, las rutas funcionan como contratos de comunicación. El frontend o una herramienta de prueba necesita saber qué endpoint invocar. Si el servidor define GET /productos, el cliente espera que esa ruta devuelva productos. Si se define GET /productos/:id, el cliente espera consultar un producto específico.

Decisión técnica crítica: usar rutas específicas y expresivas. Una alternativa descartada sería responder todo desde una sola ruta y decidir internamente qué hacer según condiciones manuales. Esa alternativa vuelve el código difícil de mantener y reduce la claridad del contrato HTTP.

Trade-off: crear varias rutas exige más organización, pero mejora la legibilidad y la validación. Cada endpoint tiene una responsabilidad más clara.

Impacto en rendimiento, seguridad y mantenimiento: rutas claras facilitan pruebas, reducen ambigüedad y permiten ubicar errores más rápido. Desde el mantenimiento, una ruta bien nombrada comunica intención. Desde seguridad, aunque esta sesión no incorpora validaciones avanzadas, separar rutas ayuda a decidir más adelante qué controles aplicar en cada operación.

Un error real en proyectos iniciales es crear endpoints con nombres inconsistentes. Por ejemplo, usar /producto, /productos-lista y /getProductos sin una lógica común. La consecuencia es que el frontend se vuelve más difícil de conectar y la documentación del backend pierde claridad. La deuda técnica aparece cuando nadie sabe qué ruta debe usarse para cada acción.

Concepto clave

Una ruta Express combina método HTTP, endpoint y función controladora.

Error común

Creer que app.get sirve para cualquier operación, incluso crear o modificar datos.

Buena práctica

Relacionar cada ruta con una intención clara: leer, consultar, crear, actualizar o eliminar.

Aplicación real

Un sistema de productos puede exponer /productos para listar y /productos/:id para consultar por identificador.

Parámetros en rutas y organización con express.Router

Express permite capturar valores dinámicos desde la URL mediante parámetros de ruta. Un ejemplo típico es /productos/:id. En esta estructura, :id representa una parte variable del endpoint. Si el cliente solicita /productos/5, Express captura el valor 5 y lo deja disponible en req.params.id. Esto permite que una sola ruta sirva para consultar distintos productos.

El fundamento técnico de los parámetros está en evitar rutas repetidas. No tendría sentido crear una ruta diferente para cada producto. En lugar de /productos/1, /productos/2 y /productos/3 como rutas independientes, se define /productos/:id y se procesa el identificador dinámicamente.

El problema real que resuelve este patrón es la escalabilidad de endpoints. Un catálogo puede tener pocos productos en clase, pero en un sistema real puede tener muchos registros. La ruta con parámetro permite que el diseño del servidor sea flexible sin multiplicar código innecesario.

Cuando el proyecto crece, app.js puede volverse demasiado extenso si contiene todas las rutas. Por eso el PPT introduce express.Router como mecanismo para organizar mejor el código. Un router permite agrupar rutas relacionadas, por ejemplo rutas de productos, y conectarlas desde app.js mediante app.use. Esta separación mejora la lectura del proyecto.

Decisión técnica crítica: separar rutas de productos en un router cuando el código empieza a crecer. Una alternativa descartada sería mantener todas las rutas en app.js. Esa alternativa puede funcionar en ejemplos muy pequeños, pero genera un archivo difícil de mantener a medida que aparecen más endpoints.

Trade-off: usar routers agrega archivos y requiere cuidar rutas de importación, pero mejora la modularidad. Para estudiantes, esta práctica introduce organización sin cambiar el objetivo conceptual.

Impacto en rendimiento, seguridad y mantenimiento: el principal impacto está en mantenimiento. Un archivo app.js saturado dificulta encontrar errores. Un router bien separado permite ubicar rápidamente las rutas de productos. En seguridad futura, también permite aplicar middlewares específicos por grupo de rutas.

Un error común es no hacer coincidir el nombre del archivo con la ruta usada en require. Por ejemplo, crear routes.js y luego intentar importar ./routes/productos. La consecuencia es un error de módulo no encontrado. Otra deuda técnica aparece cuando se mezclan rutas de productos, usuarios y pruebas en el mismo archivo sin criterio.

Concepto clave

Los parámetros permiten capturar valores dinámicos y express.Router ayuda a organizar rutas por responsabilidad.

Error común

Definir /productos/id en lugar de /productos/:id cuando se necesita un parámetro.

Buena práctica

Usar routers cuando las rutas empiezan a crecer o cuando se desea separar responsabilidades.

Aplicación real

Un módulo de productos puede tener rutas propias para listar, consultar, crear, actualizar y eliminar productos.

Middleware y manejo de solicitudes HTTP

Un middleware es una función que se ejecuta entre la solicitud y la respuesta. Esta definición es clave porque ubica al middleware dentro del flujo del servidor. No es la ruta final, pero puede preparar, registrar, validar o transformar información antes de que la solicitud llegue al controlador correspondiente.

El fundamento técnico se observa con express.json. Este middleware permite que Express interprete datos enviados en formato JSON dentro del cuerpo de una solicitud. Sin este middleware, req.body puede no contener la información esperada cuando se envían datos mediante POST o PUT. También se puede crear un middleware personalizado para registrar en consola la ruta solicitada. En ese caso, next permite continuar hacia la siguiente función o ruta.

El problema real que resuelve el middleware es evitar repetir lógica en cada ruta. Si cada endpoint tuviera que procesar manualmente el cuerpo JSON o registrar actividad por separado, el código crecería de forma innecesaria. Con middleware, ciertas tareas se aplican de manera centralizada antes de responder.

En contexto de producción, los middlewares son fundamentales para procesar solicitudes, servir archivos estáticos, interpretar formularios, registrar actividad y manejar errores. En esta sesión, el foco está en comprender el flujo: solicitud, middleware, ruta y respuesta. Ese orden es más importante que memorizar muchos middlewares.

Decisión técnica crítica: colocar express.json antes de las rutas que necesitan leer req.body. Una alternativa descartada sería intentar leer el cuerpo JSON sin configurar middleware. Esa alternativa produce errores de comprensión porque el estudiante envía datos, pero el servidor no los interpreta como espera.

Trade-off: centralizar procesamiento con middleware mejora la organización, pero exige entender el orden de ejecución. Un middleware mal colocado puede no aplicarse a las rutas que lo necesitan.

Impacto en rendimiento, seguridad y mantenimiento: los middlewares influyen directamente en cómo se procesa cada solicitud. Desde mantenimiento, evitan duplicación. Desde seguridad, pueden convertirse más adelante en puntos de validación. Desde rendimiento, deben usarse con criterio porque todo middleware agregado al flujo puede ejecutarse en cada solicitud si se configura globalmente.

Un error real es olvidar llamar next en un middleware personalizado. La consecuencia es que la solicitud queda detenida y el cliente no recibe respuesta. Otra deuda técnica aparece cuando se agregan middlewares sin saber si son globales, específicos de ruta o de manejo de errores.

Concepto clave

El middleware actúa entre la solicitud y la respuesta, preparando o procesando información antes de llegar a la ruta final.

Error común

Olvidar next y detener el flujo de ejecución.

Buena práctica

Colocar express.json antes de las rutas que reciben datos JSON.

Aplicación real

En una operación POST para crear producto, el middleware permite que Express lea el JSON enviado desde Postman.

Manejo de errores en Express

El manejo de errores en Express se realiza mediante middlewares especiales que capturan fallos durante la ejecución del servidor. Estos middlewares se reconocen porque reciben cuatro parámetros: err, req, res y next. Su función es interceptar errores, registrar información útil y enviar una respuesta controlada al cliente.

El fundamento técnico está en evitar que una falla detenga la aplicación de forma abrupta o devuelva información desordenada. Cuando ocurre un problema, el servidor debe responder de manera predecible. Un ejemplo básico es registrar err.stack en consola y enviar una respuesta con estado 500 indicando que algo salió mal.

El problema real que resuelve este concepto es la estabilidad del backend. En una práctica simple, los errores pueden parecer poco importantes, pero en cualquier sistema que recibe solicitudes reales, un fallo sin control puede afectar la experiencia del usuario y dificultar el diagnóstico.

En contexto de producción, el manejo centralizado de errores permite mejorar seguridad, mantenimiento y trazabilidad. Aunque esta sesión no desarrolla un sistema avanzado de logs, sí introduce la idea esencial: los errores no deben quedar dispersos ni responderse de forma improvisada en cada ruta.

Decisión técnica crítica: definir un middleware de error centralizado. Una alternativa descartada sería manejar errores de forma manual e inconsistente dentro de cada ruta. Esa alternativa produce respuestas distintas para problemas similares y aumenta la duplicación de código.

Trade-off: un middleware de error básico no cubre todos los escenarios posibles, pero establece una estructura clara para responder ante fallos. Más adelante se puede mejorar, pero el patrón inicial ya aporta orden.

Impacto en rendimiento, seguridad y mantenimiento: un manejo controlado de errores mejora la experiencia del usuario y facilita la depuración. Desde seguridad, evita exponer detalles internos innecesarios en la respuesta. Desde mantenimiento, centraliza una parte crítica del comportamiento del servidor.

Un error común es escribir el middleware de error con tres parámetros en lugar de cuatro. Express lo interpretará como middleware normal, no como middleware de manejo de errores. La consecuencia es que los errores no serán capturados como se espera. La deuda técnica aparece cuando el proyecto crece sin una política mínima para responder fallos.

Concepto clave

El middleware de error en Express usa cuatro parámetros: err, req, res y next.

Error común

Enviar errores sin control o responder siempre con mensajes genéricos sin registrar información útil.

Buena práctica

Centralizar el manejo de errores para mejorar estabilidad y mantenimiento.

Aplicación real

Si una lectura de archivo falla, el servidor debe responder de forma controlada en lugar de detenerse abruptamente.

CRUD en el servidor con productos.json

CRUD representa las cuatro operaciones básicas sobre datos: Create, Read, Update y Delete. En español, crear, leer, actualizar y eliminar. En el contexto de Express, estas operaciones se implementan mediante rutas y métodos HTTP. POST se usa para crear, GET para leer, PUT para actualizar y DELETE para eliminar.

El fundamento técnico de esta sección está en relacionar intención de negocio con método HTTP. Si el cliente desea consultar productos, debe realizar una solicitud GET. Si desea agregar un producto, debe enviar una solicitud POST con datos en el cuerpo. Si desea modificar un producto existente, debe usar PUT con un identificador. Si desea eliminarlo, debe usar DELETE con el id correspondiente.

El problema real que resuelve CRUD es la manipulación básica de datos desde el servidor. Sin CRUD, una aplicación solo podría mostrar contenido estático o responder mensajes simples. Con CRUD, el servidor empieza a comportarse como una capa funcional capaz de administrar información.

En esta sesión, productos.json funciona como fuente de datos simple. Contiene una lista de objetos con propiedades como id, nombre y precio. El servidor puede leer ese archivo con fs.readFileSync, convertir su contenido con JSON.parse, modificar el arreglo y guardar cambios con fs.writeFileSync usando JSON.stringify.

Decisión técnica crítica: usar productos.json para concentrar el aprendizaje en rutas y métodos HTTP. Una alternativa descartada sería incorporar una base de datos real desde el inicio. Esa alternativa puede ser necesaria en cursos posteriores, pero aquí desviaría la atención del objetivo principal: entender el flujo CRUD en Express.

Trade-off: un archivo JSON es fácil de entender y visualizar, pero no es adecuado para escenarios reales con concurrencia, volumen alto o múltiples usuarios escribiendo al mismo tiempo. Su valor en esta sesión es pedagógico, no arquitectónico final.

Impacto en rendimiento, seguridad y mantenimiento: leer y escribir archivos completos en cada solicitud no es una solución eficiente para sistemas grandes. Sin embargo, para una práctica inicial, permite observar de forma directa cómo los datos entran, se transforman y se guardan. La consecuencia a mediano plazo de no reconocer esta limitación sería usar productos.json como si fuera una base de datos de producción, generando riesgo de pérdida de datos, bloqueos y mantenimiento difícil.

Un error real de estudiantes es usar GET para crear o modificar datos. La consecuencia es romper la semántica de HTTP y dificultar pruebas. Otra deuda técnica aparece cuando no se valida si el id existe antes de actualizar o eliminar. Aunque la sesión base se enfoca en el CRUD esencial, el criterio profesional exige observar estos riesgos.

Concepto clave

CRUD en Express conecta métodos HTTP con operaciones sobre datos.

Error común

Usar el método HTTP incorrecto para la operación que se quiere realizar.

Buena práctica

Relacionar GET con lectura, POST con creación, PUT con actualización y DELETE con eliminación.

Aplicación real

Un catálogo de productos puede listar, agregar, modificar y eliminar registros desde rutas Express.

Lectura, creación, actualización y eliminación: decisiones técnicas del CRUD

La lectura o Read se implementa con GET /productos. El servidor lee el contenido del archivo productos.json, lo convierte a una estructura JavaScript mediante JSON.parse y responde al cliente con res.json. Esta operación permite mostrar todos los productos disponibles. Su fundamento técnico es transformar datos persistidos en texto JSON hacia una respuesta estructurada que el cliente pueda interpretar.

La creación o Create se implementa con POST /productos. El servidor recibe un nuevo producto desde req.body, lee el archivo actual, agrega el nuevo objeto al arreglo y guarda el resultado. Para que req.body funcione correctamente, express.json debe estar configurado antes de la ruta. Esta dependencia entre middleware y CRUD es una de las ideas más importantes de la sesión.

La actualización o Update se implementa con PUT /productos/:id. El servidor toma el id desde req.params.id, recibe nuevos datos desde req.body y usa map para generar un arreglo actualizado. Si el id coincide, combina el producto existente con los nuevos datos. Luego guarda el arreglo resultante en productos.json.

La eliminación o Delete se implementa con DELETE /productos/:id. El servidor toma el id desde la URL, lee los productos, usa filter para conservar todos los productos cuyo id sea diferente y guarda el nuevo arreglo. Esta operación muestra una forma clara de remover datos según identificador.

Decisión técnica crítica: usar id como criterio de actualización y eliminación. Una alternativa descartada sería actualizar por nombre o posición en el arreglo. Esa alternativa es menos confiable porque los nombres pueden repetirse y las posiciones pueden cambiar.

Trade-off: el uso de id simplifica la identificación, pero exige que cada producto tenga un identificador correcto. Si se agregan productos sin id o con id duplicado, las operaciones pueden volverse inconsistentes.

Impacto en rendimiento, seguridad y mantenimiento: el uso de readFileSync y writeFileSync es sencillo para clase, pero bloquea mientras lee o escribe. En una práctica pequeña esto es aceptable para entender el flujo; en escenarios más exigentes, sería una deuda técnica si se mantiene sin criterio. Desde mantenimiento, map y filter expresan claramente la intención: transformar o excluir elementos.

Un error real es guardar JSON sin formato válido. La consecuencia es que la siguiente lectura con JSON.parse puede fallar. Otro error es olvidar JSON.stringify antes de escribir el archivo, produciendo contenido incorrecto o no esperado. La deuda técnica aparece cuando las rutas CRUD no controlan casos como id inexistente, cuerpo vacío o datos incompletos.

Concepto clave

Cada operación CRUD tiene una ruta, un método HTTP y una transformación concreta de datos.

Error común

Intentar leer req.body en POST o PUT sin haber activado express.json.

Buena práctica

Probar cada operación por separado antes de integrarlas en un flujo completo.

Aplicación real

En un sistema de productos, PUT permite actualizar precio o nombre sin reconstruir todo el catálogo manualmente.

Pruebas con Postman antes de conectar el frontend

Después de crear el servidor y configurar las rutas del CRUD, es indispensable probar su funcionamiento. Postman permite enviar solicitudes HTTP al servidor y revisar las respuestas de manera clara. En esta sesión se usa para probar GET, POST, PUT y DELETE sin depender de una interfaz frontend.

El fundamento técnico de esta práctica está en aislar el backend. Si una ruta falla en Postman, el problema está en el servidor, la solicitud o los datos enviados. Si una ruta funciona en Postman pero falla desde el frontend, entonces el análisis cambia. Esta separación mejora el diagnóstico.

El problema real que resuelve Postman es la validación controlada. Un navegador puede servir para probar rutas GET simples, pero no es suficiente para enviar fácilmente cuerpos JSON en POST o PUT. Postman permite elegir el método, escribir la URL, configurar el cuerpo de la solicitud y observar la respuesta del servidor.

En contexto de producción o preproducción, probar endpoints antes de integrarlos reduce errores en cascada. La práctica académica también menciona alternativas como Insomnia, Thunder Client y Hoppscotch. Todas cumplen una función similar: facilitar pruebas de APIs y solicitudes HTTP.

Decisión técnica crítica: validar el backend antes de conectarlo al frontend. Una alternativa descartada sería construir primero la interfaz y probar todo desde botones o formularios. Esa alternativa hace más difícil diagnosticar errores porque mezcla problemas de interfaz, eventos, rutas, formato JSON y servidor.

Trade-off: usar Postman agrega un paso adicional a la práctica, pero mejora la precisión del diagnóstico. El estudiante aprende a pensar como desarrollador backend: cada endpoint debe probarse como unidad funcional.

Impacto en rendimiento, seguridad y mantenimiento: las pruebas manuales con Postman no sustituyen una estrategia completa de testing, pero sí ayudan a detectar errores básicos de rutas, métodos, cuerpos JSON y códigos de estado. Desde mantenimiento, guardar y repetir solicitudes permite validar cambios. Desde seguridad, permite observar qué datos se envían y qué datos responde el servidor.

Un error real es asumir que el CRUD funciona porque el servidor no muestra errores en consola. La consecuencia es descubrir problemas tarde, cuando el frontend ya está construido. La deuda técnica aparece cuando no existe una cultura mínima de validación de endpoints.

Concepto clave

Postman permite probar solicitudes HTTP y revisar respuestas del servidor antes de integrar el frontend.

Error común

No configurar el cuerpo como JSON al probar POST o PUT.

Buena práctica

Probar cada ruta CRUD con su método HTTP correcto y revisar la respuesta recibida.

Aplicación real

Antes de conectar una pantalla de productos, se valida que el backend pueda listar, crear, actualizar y eliminar productos correctamente.

Actualización técnica sugerida para esta sesión

Esta sección separa la actualización operativa del contenido base. El objetivo no es cambiar el tema ni agregar teoría externa, sino evitar errores prácticos derivados de versiones, comandos o herramientas que pueden cambiar con el tiempo.

Elemento del PPT: descargar Node.js desde el sitio oficial y usar versión LTS.

Situación detectada: la recomendación de usar LTS sigue siendo adecuada, pero la versión concreta cambia con el tiempo.

Mejora recomendada: indicar al estudiante que use la versión LTS vigente al momento de la práctica.

Justificación: LTS prioriza estabilidad y soporte, lo cual es conveniente para una sesión universitaria y para prácticas backend iniciales.

Cómo se aplicará: en clase se mantiene la instrucción “descargar Node.js LTS” sin fijar una versión específica en el material conceptual.

Qué debe saber el estudiante: LTS significa soporte de largo plazo y es una elección estable para aprender y practicar.

Qué no se debe agregar: no convertir esta sesión en administración avanzada de versiones Node.js.

Elemento del PPT: comandos node -v y npm -v.

Situación detectada: en materiales copiados desde documentos o presentaciones puede aparecer un guion tipográfico incorrecto.

Mejora recomendada: escribir siempre node -v y npm -v con guion normal de terminal.

Justificación: copiar un guion largo puede producir errores o comandos no reconocidos.

Cómo se aplicará: el docente debe escribir manualmente los comandos en terminal y pedir al estudiante verificar que el carácter sea correcto.

Qué debe saber el estudiante: la terminal diferencia caracteres aunque visualmente parezcan parecidos.

Qué no se debe agregar: no introducir banderas avanzadas de Node.js ni npm que no pertenecen a la sesión.

Elemento del PPT: instalación de Express con npm install express.

Situación detectada: la instrucción sigue siendo válida como instalación base.

Mejora recomendada: mantener npm install express dentro de la carpeta del proyecto.

Justificación: Express debe quedar registrado como dependencia del proyecto.

Cómo se aplicará: el estudiante ejecuta el comando después de npm init -y.

Qué debe saber el estudiante: si ejecuta el comando fuera de la carpeta, instalará la dependencia en el lugar equivocado.

Qué no se debe agregar: no agregar frameworks alternativos al desarrollo práctico de esta sesión.

Elemento del PPT: pruebas con Postman.

Situación detectada: Postman sigue siendo una herramienta adecuada para enviar solicitudes y revisar respuestas de APIs.

Mejora recomendada: usar Postman como herramienta de validación, manteniendo Insomnia, Thunder Client y Hoppscotch como alternativas mencionadas.

Justificación: permite probar GET, POST, PUT y DELETE sin depender de un frontend.

Cómo se aplicará: cada operación del CRUD debe probarse con su método correspondiente.

Qué debe saber el estudiante: Postman es soporte de práctica, no el concepto central de la sesión.

Qué no se debe agregar: no introducir flujos avanzados de autenticación, colecciones automatizadas o pruebas complejas que excedan el PPT.

Integración académica: del servidor Express al aprendizaje profesional

Esta sesión funciona como puente entre fundamentos de JavaScript y desarrollo backend aplicado. El estudiante aprende que una aplicación web no se sostiene solamente con interfaz; necesita un servidor que reciba solicitudes, procese datos y responda de forma organizada. Node.js ofrece el entorno para ejecutar JavaScript en servidor, y Express aporta la estructura práctica para crear rutas, middleware y operaciones CRUD.

El fundamento técnico integrador es el flujo completo: cliente, solicitud HTTP, middleware, ruta, operación sobre datos y respuesta. Cada parte cumple una función. El cliente solicita, el servidor escucha, el middleware procesa, la ruta decide, el CRUD manipula datos y la respuesta comunica el resultado.

El problema real que resuelve esta integración es la fragmentación del aprendizaje. Muchos estudiantes ven comandos, rutas y JSON como piezas separadas. Esta sesión permite unirlas en un proceso coherente. Cuando el estudiante prueba con Postman y observa cambios en productos.json, entiende que el backend es un sistema en ejecución, no una colección de fragmentos aislados.

En contexto profesional, esta comprensión es fundamental para trabajar con APIs, integrar frontend y backend, depurar errores y explicar el comportamiento de un servidor. Aunque el proyecto académico sea simple, el criterio adquirido es transferible a escenarios más complejos.

Decisión técnica crítica: enseñar primero el flujo completo con una fuente de datos simple. Una alternativa descartada sería fragmentar la sesión en teoría aislada sin práctica. Esa alternativa reduce la retención y deja al estudiante sin validación observable.

Trade-off: una práctica integrada puede requerir más tiempo que una explicación conceptual, pero produce aprendizaje verificable. El estudiante no solo define Node.js o Express; puede levantar un servidor y probar rutas.

Impacto en rendimiento, seguridad y mantenimiento: comprender el flujo desde el inicio facilita decisiones posteriores sobre organización, validación y pruebas. A mediano plazo, el estudiante podrá reconocer cuándo un problema pertenece al cliente, a la ruta, al middleware, al cuerpo JSON o a la manipulación de datos.

Un error real de aprendizaje es avanzar hacia frameworks o arquitecturas más complejas sin dominar rutas, métodos HTTP y middleware. La consecuencia es una dependencia excesiva de plantillas. La deuda técnica personal aparece cuando el estudiante puede ejecutar proyectos, pero no puede explicar por qué funcionan.

Concepto clave

El aprendizaje profesional empieza cuando el estudiante puede explicar el recorrido completo de una solicitud HTTP.

Error común

Copiar código de Express sin entender qué hacen req, res, next, app.get o app.use.

Buena práctica

Explicar cada ruta en términos de método, endpoint, entrada, procesamiento y salida.

Aplicación real

Antes de conectar un frontend, el backend debe funcionar y responder correctamente de forma independiente.

Resumen técnico de la sesión

La creación de servidores web con Node.js y Express permite construir una base backend clara y aplicable. Node.js ejecuta JavaScript en el servidor. Express simplifica la creación de rutas, el uso de middleware y el manejo de respuestas HTTP. npm permite instalar dependencias y configurar el proyecto.

El servidor se inicia desde app.js mediante app.listen. Las rutas se definen con métodos como app.get y pueden recibir parámetros dinámicos mediante estructuras como /productos/:id. Cuando el código crece, express.Router permite organizar rutas por responsabilidad. El middleware se ejecuta entre solicitud y respuesta, y express.json permite interpretar cuerpos JSON. El manejo de errores se centraliza mediante un middleware especial con err, req, res y next.

El CRUD permite crear, leer, actualizar y eliminar datos. En esta sesión, esas operaciones se implementan con POST, GET, PUT y DELETE sobre un archivo productos.json. Aunque este archivo funciona como fuente simple de datos, el valor principal está en comprender cómo Express recibe solicitudes y modifica la información.

Postman permite validar el servidor antes de conectarlo con el frontend. Esta práctica mejora el diagnóstico, reduce errores y refuerza la comprensión del backend como sistema independiente.

Autoevaluación profesional

Pregunta 1: ¿Puedes explicar la diferencia entre Node.js y Express sin decir que son lo mismo?

Pregunta 2: ¿Puedes identificar qué método HTTP corresponde a cada operación CRUD?

Pregunta 3: ¿Puedes explicar por qué express.json debe colocarse antes de rutas que leen req.body?

Pregunta 4: ¿Puedes interpretar el mensaje Cannot GET / sin asumir que el servidor falló?

Pregunta 5: ¿Puedes probar una ruta POST o PUT en Postman enviando un cuerpo JSON válido?

Continuación formativa

Después de esta sesión, el estudiante debe practicar la creación de nuevas rutas, modificar el archivo productos.json, probar distintos métodos HTTP y explicar el flujo de una solicitud desde Postman hasta la respuesta del servidor. La siguiente etapa natural es conectar este backend con un frontend, manteniendo primero la validación independiente del servidor.

Para reforzar el aprendizaje, revisa los recursos del ecosistema Lideratec Academy.

Blog: https://lideratecacademy.com/

Canal YouTube: https://www.youtube.com/@LideratecAcademy

El criterio profesional que deja esta sesión es simple y poderoso: antes de construir interfaces complejas, asegúrate de que el servidor reciba, procese y responda correctamente. Un backend bien comprendido se prueba, se organiza y se explica con claridad.