Desarrollo Web con Node y Express, 2ª Edición

Capítulo 1. Presentación de Express

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

La revolución de JavaScript

Antes de introducir el tema principal de este libro, es importante proporcionar un poco de antecedentes y contexto histórico, y eso significa hablar de JavaScript y Node. La era de JavaScript está realmente sobre nosotros. Desde sus humildes comienzos como lenguaje de programación del lado del cliente, no sólo se ha vuelto completamente omnipresente en el lado del cliente, sino que su uso como lenguaje del lado del servidor también ha despegado finalmente, gracias a Node.

La promesa de una pila tecnológica totalmente JavaScript es clara: ¡se acabaron los cambios de contexto! Ya no tienes que cambiar mentalmente de JavaScript a PHP, C#, Ruby o Python (o cualquier otro lenguaje del lado del servidor). Además, capacita a los ingenieros de frontend para dar el salto a la programación del lado del servidor. Esto no quiere decir que la programación del lado del servidor sea estrictamente sobre el lenguaje; aún hay mucho que aprender. Sin embargo, con JavaScript, al menos el lenguaje no será una barrera.

Este libro es para todos aquellos que ven la promesa de la pila tecnológica JavaScript. Tal vez seas un ingeniero de frontend que busca ampliar su experiencia al desarrollo de backend. Tal vez seas un desarrollador backend experimentado como yo que busca en JavaScript una alternativa viable a los arraigados lenguajes del lado del servidor.

Si has sido ingeniero de software durante tanto tiempo como yo, habrás visto ponerse de moda muchos lenguajes, marcos de trabajo y API. Algunos han despegado, y otros se han desvanecido en la obsolescencia. Probablemente te enorgullezcas de tu capacidad para aprender rápidamente nuevos lenguajes, nuevos sistemas. Cada nuevo lenguaje con el que te cruzas te resulta un poco más familiar: reconoces un poco aquí de un lenguaje que aprendiste en la universidad, un poco allá de aquel trabajo que tuviste hace unos años. Es bueno tener ese tipo de perspectiva, sin duda, pero también es agotador. A veces sólo quieres hacer algo, sin tener que aprender una tecnología completamente nueva o desempolvar habilidades que no has utilizado en meses o años.

JavaScript puede parecer, al principio, un campeón improbable. Te comprendo, créeme. Si me hubieras dicho en 2007 que no sólo llegaría a pensar en JavaScript como mi lenguaje preferido, sino que además escribiría un libro sobre él, te habría dicho que estabas loco. Tenía todos los prejuicios habituales contra JavaScript: Pensaba que era un lenguaje "de juguete", algo para que aficionados y diletantes lo manoseasen y abusasen de él. Para ser justos, JavaScript bajaba el listón para los aficionados, y había mucho JavaScript cuestionable por ahí, lo que no ayudaba a la reputación del lenguaje. Para darle la vuelta a un dicho popular: "Odia al jugador, no al juego".

Es lamentable que la gente sufra este prejuicio contra JavaScript; ha impedido que la gente descubra lo potente, flexible y elegante que es el lenguaje. Mucha gente está empezando ahora a tomarse en serio JavaScript, a pesar de que el lenguaje tal y como lo conocemos ahora existe desde 1996 (aunque muchas de sus características más atractivas se añadieron en 2005).

Al coger este libro, probablemente te hayas liberado de ese prejuicio: bien porque, como yo, lo has superado, bien porque nunca lo tuviste en primer lugar. En cualquiera de los dos casos, eres afortunado, y estoy deseando presentarte Express, una tecnología posible gracias a un lenguaje delicioso y sorprendente.

En 2009, años después de que la gente empezara a darse cuenta de la potencia y expresividad de JavaScript como lenguaje de programación para navegadores, Ryan Dahl vio el potencial de JavaScript como lenguaje del lado del servidor, y así nació Node.js. Era una época fértil para la tecnología de Internet. Ruby (y Ruby on Rails) tomó algunas ideas geniales de la informática académica, las combinó con algunas ideas nuevas propias y mostró al mundo una forma más rápida de crear sitios y aplicaciones web. Microsoft, en un valiente esfuerzo por ser relevante en la era de Internet, hizo cosas asombrosas con .NET y aprendió no sólo de Ruby y JavaScript, sino también de los errores de Java, al tiempo que tomaba prestado en gran medida de los salones de la academia.

Hoy en día, los desarrolladores web tienen la libertad de utilizar las últimas características del lenguaje JavaScript sin miedo a alienar a los usuarios con navegadores antiguos, gracias a tecnologías de transcompilación como Babel. Webpack se ha convertido en la solución omnipresente para gestionar las dependencias en las aplicaciones web y garantizar el rendimiento, y marcos como React, Angular y Vue están cambiando la forma en que la gente aborda el desarrollo web, relegando las bibliotecas declarativas de manipulación del Modelo de Objetos del Documento (DOM) (como jQuery) a noticias de ayer.

Es un momento apasionante para dedicarse a la tecnología de Internet. Por todas partes hay nuevas ideas asombrosas (o viejas ideas asombrosas revitalizadas). El espíritu de innovación y entusiasmo es mayor ahora que en muchos años.

Presentación de Exprés

El sitio web de Express lo describe como un "marco de aplicaciones web Node.js mínimo y flexible que proporciona un sólido conjunto de funciones para aplicaciones web y móviles". Pero, ¿qué significa eso realmente? Desglosemos esa descripción:

Mínimo

Éste es uno de los aspectos más atractivos de Express. Muchas veces, los desarrolladores de frameworks olvidan que normalmente "menos es más". La filosofía de Express es proporcionar la capa mínima entre tu cerebro y el servidor. Eso no significa que no sea robusto o que no tenga suficientes funciones útiles. Significa que se interpone menos en tu camino, permitiéndote la plena expresión de tus ideas, al tiempo que te proporciona algo útil. Express te proporciona un marco mínimo, y tú puedes añadir diferentes partes de la funcionalidad de Express según necesites, sustituyendo lo que no satisfaga tus necesidades. Esto es un soplo de aire fresco. Tantos marcos de trabajo te lo dan todo, dejándote con un proyecto hinchado, misterioso y complejo antes incluso de que hayas escrito una sola línea de código. A menudo, la primera tarea es perder el tiempo eliminando la funcionalidad innecesaria o sustituyendo la que no cumple los requisitos. Express adopta el enfoque opuesto, permitiéndote añadir lo que necesites cuando lo necesites.

Flexible

Al fin y al cabo, lo que hace Express es muy sencillo: acepta solicitudes HTTP de un cliente (que puede ser un navegador, un dispositivo móvil, otro servidor, una aplicación de escritorio... cualquier cosa que hable HTTP) y devuelve una respuesta HTTP. Este patrón básico describe casi todo lo que se conecta a Internet, lo que hace que Express sea extremadamente flexible en sus aplicaciones.

Marco de aplicación web

Quizá una descripción más precisa sería "parte del lado del servidor de un framework de aplicaciones web". Hoy en día, cuando piensas en "marco de aplicaciones web", generalmente piensas en un marco de aplicaciones de una sola página como React, Angular o Vue. Sin embargo, salvo un puñado de aplicaciones independientes, la mayoría de las aplicaciones web necesitan compartir datos e integrarse con otros servicios. Generalmente lo hacen a través de una API web, que puede considerarse el componente del lado del servidor de un marco de aplicaciones web. Ten en cuenta que sigue siendo posible (y a veces deseable) construir una aplicación completa sólo con renderizado del lado del servidor, ¡en cuyo caso Express puede muy bien constituir todo el marco de la aplicación web!

Además de las características de Express mencionadas explícitamente en su propia descripción, yo añadiría dos propias:

Rápido

Cuando Express se convirtió en el marco web de referencia para el desarrollo con Node.js, atrajo mucha atención de las grandes empresas que ejecutaban sitios web de alto rendimiento y tráfico. Esto presionó al equipo de Express para que se centrara en el rendimiento, y ahora Express ofrece un rendimiento líder para sitios web de alto tráfico.

Sin opinión

Una de las características del ecosistema JavaScript es su tamaño y diversidad. Aunque Express suele estar en el centro del desarrollo web con Node.js, hay cientos (si no miles) de paquetes de la comunidad que forman parte de una aplicación Express. El equipo de Express reconoció esta diversidad del ecosistema y respondió proporcionando un sistema de middleware extremadamente flexible que facilita el uso de los componentes que elijas al crear tu aplicación. A lo largo del desarrollo de Express, puedes ver cómo se desprende de componentes "integrados" en favor de middleware configurable.

He mencionado que Express es la "parte del lado del servidor" de un marco de aplicaciones web... así que probablemente deberíamos considerar la relación entre las aplicaciones del lado del servidor y las del lado del cliente.

Aplicaciones del lado del servidor y del lado del cliente

Una aplicación del lado del servidor es aquella en la que las páginas de la aplicación se renderizan en el servidor (como HTML, CSS, imágenes y otros activos multimedia, y JavaScript) y se envían al cliente. Una aplicación del lado del cliente, por el contrario, renderiza la mayor parte de su propia interfaz de usuario a partir de un paquete de aplicación inicial que se envía una sola vez. Es decir, una vez que el navegador recibe el HTML inicial (generalmente muy mínimo), utiliza JavaScript para modificar dinámicamente el DOM de y no necesita depender del servidor para mostrar nuevas páginas (aunque los datos en bruto suelen seguir procediendo del servidor).

Antes de 1999, las aplicaciones del lado del servidor eran la norma. De hecho, el término aplicación web se introdujo oficialmente ese año. Considero el periodo comprendido aproximadamente entre 1999 y 2012 como la era Web 2.0, durante la cual se desarrollaron las tecnologías y técnicas que acabarían convirtiéndose en aplicaciones del lado del cliente. En 2012, con los smartphones firmemente arraigados, era práctica común enviar la menor cantidad de información posible a través de la red, una práctica que favorecía las aplicaciones del lado del cliente.

Las aplicaciones del lado del servidor suelen llamarse renderizadas del lado del servidor (SSR), y las aplicaciones del lado del cliente suelen llamarseaplicaciones de una sola página(SPA) . Las aplicaciones del lado del cliente se realizan plenamente en frameworks como React, Angular y Vue. Siempre me ha parecido que "una sola página" es un término un poco inapropiado porque, desde la perspectiva del usuario, puede haber muchas páginas. La única diferencia es si la página se envía desde el servidor o se renderiza dinámicamente en el cliente.

En realidad, hay muchas líneas difusas entre las aplicaciones del lado del servidor y las aplicaciones del lado del cliente. Muchas aplicaciones del lado del cliente tienen dos o tres paquetes HTML que pueden enviarse a ese cliente (por ejemplo, la interfaz pública y la interfaz de inicio de sesión, o una interfaz normal y una interfaz de administrador). Además, las SPA se combinan a menudo con SSR para aumentar el rendimiento de la carga de la primera página y ayudar a la optimización de los motores de búsqueda (SEO).

En general, si el servidor envía un pequeño número de archivos HTML (generalmente de uno a tres), y el usuario experimenta una experiencia rica y multivista basada en la manipulación dinámica del DOM, consideramos que se trata de una renderización del lado del cliente. Los datos (normalmente en forma de JSON) y los activos multimedia para las distintas vistas suelen seguir procediendo de la red.

A Express, por supuesto, no le importa mucho si estás haciendo una aplicación del lado del servidor o del lado del cliente; está encantada de desempeñar cualquiera de los dos papeles. A Express le da igual si estás sirviendo un paquete HTML o cien.

Aunque las SPA han "ganado" definitivamente como arquitectura de aplicación web predominante, este libro comienza con ejemplos coherentes con las aplicaciones del lado del servidor. Siguen siendo relevantes, y la diferencia conceptual entre servir un paquete HTML o muchos es pequeña. Hay un ejemplo de SPA en el Capítulo 16.

Breve historia de Express

El creador de Express, TJ Holowaychuk, describe Express como un framework web inspirado en Sinatra, que es un framework web basado en Ruby. No es ninguna sorpresa que Express tome prestado de un framework construido sobre Ruby: Ruby generó una gran cantidad de enfoques geniales para el desarrollo web, destinados a hacer que el desarrollo web sea más rápido, más eficiente y más fácil de mantener.

Por mucho que Express se inspirara en Sinatra, también estaba profundamente entrelazado con Connect, una biblioteca "plug-in" para Node. Connect acuñó el término middleware para describir módulos Node enchufables que pueden gestionar peticiones web en distintos grados. En 2014, en la versión 4.0, Express eliminó su dependencia de Connect, pero sigue debiendo su concepto de middleware a Connect.

Nota

Express sufrió una reescritura bastante sustancial entre la 2.x y la 3.0, y de nuevo entre la 3.x y la 4.0. Este libro se centra en la versión 4.0.

Nodo: Un nuevo tipo de servidor web

En cierto modo, Node tiene mucho en común con otros servidores web populares, como Internet Information Services (IIS) de Microsoft o Apache. Sin embargo, lo más interesante es en qué se diferencia, así que empecemos por ahí.

Al igual que Express, el enfoque de Node respecto a los servidores web es muy minimalista. A diferencia de IIS o Apache, que una persona puede pasarse muchos años dominando, Node es fácil de instalar y configurar. Eso no quiere decir que ajustar los servidores Node para obtener el máximo rendimiento en un entorno de producción sea una cuestión trivial; es sólo que las opciones de configuración son más sencillas y directas.

Otra diferencia importante entre Node y los servidores web más tradicionales es que Node es monohilo. A primera vista, esto puede parecer un paso atrás. Pero resulta que es una genialidad. El monohilo simplifica enormemente la tarea de escribir aplicaciones web, y si necesitas el rendimiento de una aplicación multihilo, puedes simplemente crear más instancias de Node, y tendrás efectivamente las ventajas de rendimiento del multihilo. El lector astuto probablemente esté pensando que esto suena a humo y espejos. Al fin y al cabo, ¿el multihilo a través del paralelismo del servidor (en contraposición al paralelismo de la aplicación) no consiste simplemente en desplazar la complejidad, no en eliminarla? Tal vez, pero en mi experiencia, ha desplazado la complejidad exactamente a donde debería estar. Además, con la creciente popularidad de la computación en nube y el tratamiento de los servidores como mercancías genéricas, este enfoque tiene mucho más sentido. IIS y Apache son realmente potentes, y están diseñados para exprimir hasta la última gota de rendimiento del potente hardware actual. Pero eso tiene un coste: requieren una experiencia considerable para configurarlos y ajustarlos para conseguir ese rendimiento.

En cuanto a la forma de escribir las aplicaciones, las aplicaciones Node tienen más en común con las aplicaciones PHP o Ruby que con las aplicaciones .NET o Java. Aunque el motor JavaScript que utiliza Node (el V8 de Google) compila JavaScript a código máquina nativo (como C o C++), lo hace de forma transparente,¹ por lo que, desde la perspectiva del usuario, se comporta como un lenguaje puramente interpretado. No tener que compilar por separado reduce las molestias de mantenimiento e implementación: todo lo que tienes que hacer es actualizar un archivo JavaScript, y tus cambios estarán disponibles automáticamente.

Otra ventaja convincente de las aplicaciones Node es que Node es increíblemente independiente de la plataforma. No es la primera ni la única tecnología de servidor independiente de la plataforma, pero la independencia de la plataforma es realmente más un espectro que una proposición binaria. Por ejemplo, puedes ejecutar aplicaciones .NET en un servidor Linux gracias a Mono, pero es un esfuerzo penoso debido a la documentación irregular y a las incompatibilidades del sistema. Del mismo modo, puedes ejecutar aplicaciones PHP en un servidor Windows, pero no suele ser tan fácil de configurar como en una máquina Linux. Node, en cambio, es muy fácil de configurar en los principales sistemas operativos (Windows, macOS y Linux) y permite una colaboración sencilla. Entre los equipos de diseño de sitios web, es bastante común una mezcla de PC y Mac. Ciertas plataformas, como .NET, suponen un reto para los desarrolladores y diseñadores frontales, que suelen utilizar Mac, lo que tiene un gran impacto en la colaboración y la eficiencia. La idea de poder poner en marcha un servidor funcional en cualquier sistema operativo en cuestión de minutos (¡o incluso segundos!) es un sueño hecho realidad.

El ecosistema de nodos

Node, por supuesto, se encuentra en el corazón de la pila. Es el software que permite ejecutar JavaScript en el servidor, desacoplado de un navegador, lo que a su vez permite utilizar marcos escritos en JavaScript (como Express). Otro componente importante es la base de datos, que se tratará más a fondo en el Capítulo 13. Todas las aplicaciones web, salvo las más sencillas, necesitarán una base de datos, y hay bases de datos que se adaptan mejor al ecosistema Node que otras.

No es de extrañar que existan interfaces de bases de datos para las principales bases de datos relacionales (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server); sería una tontería desatender a esos gigantes establecidos. Sin embargo, la llegada del desarrollo de Node ha revitalizado un nuevo enfoque del almacenamiento de bases de datos: las llamadas bases de datos NoSQL. No siempre es útil definir algo como lo que no es, así que añadiremos que estas bases de datos NoSQL podrían denominarse más adecuadamente "bases de datos de documentos" o "bases de datos de pares clave/valor". Proporcionan un enfoque conceptualmente más sencillo del almacenamiento de datos. Hay muchas, pero MongoDB es una de las pioneras, y es la base de datos NoSQL que utilizaremos en este libro.

Dado que la construcción de un sitio web funcional depende de múltiples piezas de tecnología, se han creado acrónimos para describir la "pila" sobre la que se construye un sitio web. Por ejemplo, la combinación de Linux, Apache, MySQL y PHP se denomina pila LAMP. Valeri Karpov, ingeniero de MongoDB, acuñó el acrónimo MEAN: Mongo, Express, Angular y Node. Aunque es ciertamente pegadizo, es limitante: hay tantas opciones de bases de datos y marcos de aplicaciones que "MEAN" no capta la diversidad del ecosistema (también deja fuera lo que creo que es un componente importante: los motores de renderizado).

Acuñar un acrónimo inclusivo es un ejercicio interesante. El componente indispensable, por supuesto, es Node. Aunque existen otros contenedores JavaScript del lado del servidor, Node se perfila como el dominante. Express, además, no es el único framework de aplicaciones web disponible, aunque se acerca a Node en su dominio. Los otros dos componentes que suelen ser esenciales para el desarrollo de aplicaciones web son un servidor de bases de datos y un motor de renderizado (ya sea un motor de plantillas como Handlebars o un marco SPA como React). Para estos dos últimos componentes, no hay tantos líderes claros, y aquí es donde creo que es un flaco favor ser restrictivo.

Lo que une a todas estas tecnologías es JavaScript, así que en un esfuerzo por ser inclusivo, me referiré a lapila JavaScript. A efectos de este libro, eso significa Node, Express y MongoDB (también hay un ejemplo de base de datos relacional enel Capítulo 13).

Licencias

Al desarrollar aplicaciones Node, puede que tengas que prestar más atención a las licencias de lo que nunca antes lo habías hecho (yo desde luego sí). Una de las bellezas del ecosistema Node es la gran variedad de paquetes que tienes a tu disposición. Sin embargo, cada uno de esos paquetes conlleva su propia licencia, y lo que es peor, cada paquete puede depender de otros paquetes, lo que significa que entender la licencia de las distintas partes de la aplicación que has escrito puede ser complicado.

Sin embargo, hay buenas noticias. Una de las licencias más populares para los paquetes Node es la licencia MIT, que es indoloramente permisiva y te permite hacer casi todo lo que quieras, incluso utilizar el paquete en software de código cerrado. Sin embargo, no debes dar por sentado que todos los paquetes que utilices tienen licencia MIT.

Consejo

Hay varios paquetes disponibles en npm que intentarán averiguar las licencias de cada dependencia en tu proyecto. Busca en npmnlf o license-report.

Aunque MIT es la licencia más común que encontrarás, también puedes ver las siguientes licencias:

Licencia Pública General GNU (GPL)

La GPL es una popular licencia de código abierto que ha sido ingeniosamente elaborada para mantener el software libre. Eso significa que si utilizas código con licencia GPL en tu proyecto, tu proyecto también debe tener licencia GPL. Naturalmente, esto significa que tu proyecto no puede ser de código cerrado.

Apache 2.0

Esta licencia, al igual que la MIT, te permite utilizar una licencia diferente para tu proyecto, incluida una licencia de código cerrado. Sin embargo, debes incluir un aviso sobre los componentes que utilizan la licencia Apache 2.0.

Distribución de Software Berkeley (BSD)

Al igual que Apache, esta licencia te permite utilizar la licencia que desees para tu proyecto, siempre que incluyas un aviso de los componentes con licencia BSD.

Nota

A veces el software tiene doble licencia (licencia bajo dos licencias diferentes). Una razón común para hacer esto es permitir que el software se utilice tanto en proyectos GPL como en proyectos con licencias más permisivas. (Para que un componente pueda utilizarse en software GPL, el componente debe tener licencia GPL). Éste es un esquema de licencia que empleo a menudo con mis propios proyectos: licencia dual con GPL y MIT.

Por último, si te encuentras escribiendo tus propios paquetes, debes ser un buen ciudadano y elegir una licencia para tu paquete, y documentarla correctamente. No hay nada más frustrante para un desarrollador que utilizar el paquete de alguien y tener que rebuscar en el código fuente para determinar la licencia o, peor aún, descubrir que no tiene licencia alguna.

Conclusión

Espero que este capítulo te haya dado alguna idea más de lo que es Express y de cómo encaja en el ecosistema más amplio de Node y JavaScript, así como algo de claridad sobre la relación entre las aplicaciones web del lado del servidor y del lado del cliente.

Si aún te sientes confuso sobre lo que es Express en realidad, no te preocupes: a veces es mucho más fácil empezar a usar algo para entender lo que es, y este libro te ayudará a empezar a crear aplicaciones web con Express. Sin embargo, antes de empezar a utilizar Express, vamos a dar una vuelta por Node en el siguiente capítulo, que es una información de fondo importante para entender cómo funciona Express.

¹ A menudo llamada compilación justo a tiempo (JIT).