¡Hola habitantes! Cree aplicaciones web dinámicas con Express, un componente clave de la pila de desarrollo de Node / JavaScript. Ethan Brown describe cómo trabajar con Express 5 creando una aplicación completa. El libro cubre todas las etapas y componentes, desde la representación del servidor hasta el desarrollo de API para trabajar con aplicaciones de una sola página (SPA). Express es el término medio entre un marco bien establecido y ningún marco en absoluto, por lo que le deja algo de libertad en sus elecciones arquitectónicas. Este libro proporcionará las mejores soluciones para los desarrolladores front-end y back-end que utilizan Express. ¡Aprenda a ver el desarrollo web desde un nuevo ángulo! - Crear un sistema de plantillas para mostrar datos dinámicos. Obtenga más información sobre los objetos de solicitud y respuesta, el middleware y el enrutamiento de URL.- Crear una simulación del entorno de producción y probar en él. - Aprenda el almacenamiento a largo plazo de información en bases de datos de documentos usando MongoDB y en bases de datos relacionales usando PostgreSQL. - Comparte tus recursos con otros programas gracias a la API. - Cree aplicaciones seguras utilizando autenticación, autorización y HTTPS. - Integre con las redes sociales, habilite la geolocalización y mucho más. - Implemente un plan para lanzar y mantener su aplicación. - Domina las habilidades críticas de depuración.- Cree aplicaciones seguras utilizando autenticación, autorización y HTTPS. - Integre con las redes sociales, habilite la geolocalización y mucho más. - Implemente un plan para lanzar y mantener su aplicación. - Domina las habilidades críticas de depuración.- Cree aplicaciones seguras utilizando autenticación, autorización y HTTPS. - Integre con las redes sociales, habilite la geolocalización y mucho más. - Implemente un plan para lanzar y mantener su aplicación. - Domina las habilidades críticas de depuración.
Redes de entrega de contenido
Cuando lleve su sitio a producción, los activos estáticos deben cargarse en algún lugar de Internet. Puede que estés acostumbrado a ponerlos en el mismo servidor donde se genera todo tu HTML dinámico. Nuestro ejemplo hasta ahora también ha utilizado este enfoque: el servidor Node / Express, lanzado por el comando node meadowlark.js, sirve tanto para todo tipo de HTML como para recursos estáticos. Sin embargo, si desea optimizar el rendimiento de su sitio (o mantenerlo en el futuro), necesitará la capacidad de alojar recursos estáticos en una red de entrega de contenido (CDN). CDN es un servidor optimizado para entregar recursos estáticos. Utiliza encabezados especiales (sobre los que aprenderemos más pronto) que permiten el almacenamiento en caché del navegador.
Además, una CDN puede incluir optimización geográfica (a menudo denominada almacenamiento en caché perimetral), lo que significa que el contenido estático se entregará desde el servidor más cercano a su cliente. Aunque Internet es muy rápido (por supuesto, no funciona a la velocidad de la luz, pero muy cerca), los datos se entregarán incluso más rápido desde una distancia de cientos de kilómetros que de miles. El ahorro de tiempo es insignificante en cada caso individual, pero cuando se multiplica por la cantidad de usuarios, solicitudes y recursos, rápidamente se vuelve impresionante.
La mayoría de sus recursos estáticos serán referenciados en vistas HTML.
<link> CSS-, <script> — JavaScript, <img> ,
Es una práctica común tener enlaces estáticos en CSS, generalmente en la propiedad background-image. Por último, a veces se hace referencia a recursos estáticos en JavaScript, por ejemplo, el código JavaScript puede cambiar o insertar etiquetas de forma dinámica.
<img>
o las propiedades de la imagen de fondo.
No se preocupe por el uso compartido de recursos entre dominios (CORS) cuando utilice una CDN. Los recursos externos cargados en HTML no están sujetos a las reglas de CORS: solo necesita habilitar CORS para los recursos cargados a través de Ajax (consulte el Capítulo 15).
Diseñar para una CDN La
forma de utilizar una CDN depende de la arquitectura de su sitio. La mayoría de las redes de entrega de contenido le permiten establecer reglas de enrutamiento para determinar dónde enviar las solicitudes entrantes. Si bien puede establecer reglas de enrutamiento bastante complejas, generalmente se reduce a enviar solicitudes de recursos estáticos a una ubicación (generalmente proporcionada por su CDN) y solicitudes de puntos finales dinámicos (páginas dinámicas o puntos finales API) a otra.
Elegir y configurar una CDN es un tema muy amplio que no cubriré aquí, pero le daré información básica para ayudarlo a configurar la CDN que elija.
El enfoque más simple para estructurar su aplicación es hacer que los recursos dinámicos y estáticos sean fácilmente distinguibles. Esto hará que sus reglas de enrutamiento CDN sean lo más simples posible. Si bien esto se puede lograr usando subdominios (por ejemplo, los recursos dinámicos se brindan desde meadowlark.com y los recursos estáticos desde static.meadowlark.com), este enfoque agrega complejidad adicional y complica el desarrollo local. Una forma más fácil es usar rutas de solicitud: por ejemplo, todo lo que comienza con / public / son recursos estáticos y todo lo demás es dinámico. El enfoque puede ser diferente si está generando contenido con Express o si utiliza Express para proporcionar una API para una aplicación de una sola página.
Sitio web de representación del lado del servidor
Si usa Express para representar HTML dinámico (en otras palabras, todo lo que comienza con / static /) son recursos estáticos, y todo lo demás es dinámico. Con este enfoque, todas sus URL (generadas dinámicamente) serán como usted desea que sean (¡a menos que comiencen con / static /, por supuesto!), Y todos sus recursos estáticos tendrán el prefijo / static /:
<img src="/static/img/meadowlark-logo-1.png" alt="Meadowlark Logo">
<a href="/about">Meadowlark Travel</a>.
Hasta ahora en este libro, hemos utilizado middleware estático, como si todos los recursos estáticos estuvieran dispuestos en el directorio raíz. Por lo tanto, al colocar el recurso estático foo.png en la carpeta pública, nos referimos a él en la ruta URL /foo.png, no en /static/foo.png. Por supuesto, es posible crear un subdirectorio estático dentro del directorio público existente y la URL de /public/static/foo.png será /static/foo.png, pero esto no es muy inteligente. Afortunadamente, el middleware estático nos permite evitar esto especificando una ruta diferente al llamar a app.use:
app.use('/static', express.static('public'))
Ahora, en el entorno de desarrollo, podemos usar la misma estructura de URL que en la explotación. Si el contenido de la carpeta pública y la CDN están sincronizados, puede hacer referencia a recursos estáticos en ambos lugares y cambiar sin problemas entre desarrollo y producción.
Al configurar el enrutamiento para el CDN (deberá consultar la documentación de su CDN), el enrutamiento se verá así.
Aplicaciones de una
sola página Las aplicaciones de una sola página son generalmente lo opuesto a los sitios web renderizados del lado del servidor: solo se pasará la API al servidor (por ejemplo, cualquier solicitud que comience con / api), todo lo demás se pasa al almacenamiento de archivos estáticos.
En el Capítulo 16, vio que puede crear un ensamblado para operar su aplicación que incluirá todos los recursos estáticos que se cargan en la CDN. Entonces solo necesita asegurarse de que la configuración de enrutamiento de su API sea correcta. De esta forma tendrás la siguiente ruta.
Ahora que hemos aprendido cómo estructurar una aplicación para una transición fluida del desarrollo a la producción, veamos qué sucede realmente en el almacenamiento en caché y cómo optimiza el rendimiento.
Almacenamiento en caché de recursos estáticos
Ya sea que utilice Express o CDN para proporcionar recursos estáticos, vale la pena comprender los encabezados de solicitud HTTP que utiliza el navegador para determinar cuándo y cómo almacenar en caché los recursos estáticos.
- Caduca / Cache-Control. Estos dos encabezados le indican a su navegador la cantidad máxima de tiempo que se puede almacenar en caché un recurso. El navegador los toma en serio: si le dicen que almacene algo durante un mes, simplemente no lo volverá a descargar durante un mes, mientras permanezca en la caché. Es importante comprender que el navegador puede eliminar una imagen del caché antes de la fecha de vencimiento por razones que usted no puede controlar. Por ejemplo, el usuario puede borrar manualmente el caché o el navegador puede eliminar su recurso para dejar espacio para los recursos que el usuario visita con más frecuencia. Solo necesitas uno de estos encabezados. Expires tiene más soporte, por lo que es preferible usarlo. Si el recurso está en la caché y aún no ha caducado,el navegador no ejecutará la solicitud GET en absoluto, lo que mejorará el rendimiento, especialmente en dispositivos móviles.
- Última modificación / ETag. Proporcione una especie de control de versión: si el navegador necesita verificar un recurso, verificará esas etiquetas antes de cargar el contenido. La solicitud GET al servidor aún se ejecutará, pero si los valores devueltos en estos encabezados demuestran al navegador que el recurso no ha cambiado, el navegador no procederá a descargar el archivo. Como sugiere el nombre, Last-Modified le permite establecer la fecha de la última modificación de un activo. ETag le permite usar una cadena arbitraria, generalmente una cadena de versión o un hash de contenido.
Al emitir recursos estáticos, use el encabezado Expires y Last-Modified o ETag. El middleware estático integrado de Express instala Cache-Control, pero no procesa Last-Modified ni ETag. Por lo tanto, es adecuado para el desarrollo, pero no para el funcionamiento.
Si elige alojar sus activos estáticos en una CDN, como Amazon CloudFront, Microsoft Azure, Fastly, Cloudflare, Akamai o StackPath, obtiene una bonificación: la mayoría de estos detalles se gestionarán por usted. Podrá realizar ajustes precisos, aunque la configuración predeterminada en cualquiera de estos servicios también está bien.
Modificar contenido estático
El almacenamiento en caché mejora significativamente el rendimiento de su sitio, pero no sin consecuencias. En particular, si cambia alguno de los recursos estáticos, es posible que los clientes no vean el cambio hasta que las versiones en caché del navegador hayan expirado. Google recomienda almacenar en caché durante un mes, preferiblemente un año. Imagine un usuario que visita su sitio todos los días a través del mismo navegador: ¡solo puede ver sus actualizaciones después de un año!
Obviamente, esta no es una situación deseable, pero no puede decirles a sus usuarios que borren el caché. La solución a este problema es deshabilitar la eliminación de caché. Este truco le dará control sobre cuándo el navegador debe recargar el recurso. Este método simplemente agrega información de la versión al nombre del archivo. Cuando actualiza un recurso, el nombre del recurso cambia y el navegador sabe que debe descargarlo. Normalmente, esto equivale a controlar las versiones del recurso (main.2.css o main.css? Version = 2) o agregar algún tipo de hash (main.e16b7e149dccfcc399e025e0c454bf77.css). Independientemente del método que utilice, cuando actualiza un recurso, su nombre cambia y el navegador sabe que debe cargarlo.
Puedes hacer lo mismo con los recursos multimedia. Tomemos nuestro logo (/static/img/meadowlark_logo.png). Si lo colocamos en un CDN para maximizar el rendimiento estableciendo el período de retención en un año y luego cambiando el logotipo, es posible que los usuarios no vean el cambio durante un año. Sin embargo, si cambiamos el nombre del logo a /static/img/meadowlark_logo-1.png y reflejamos este cambio en HTML, el navegador tendrá que descargarlo ya que parece ser un nuevo recurso.
Si se decidió por un marco de aplicación de una sola página, como create-react-app o similar, en la etapa de compilación se creará un conjunto de recursos listos para usar con hashes agregados.
Si está comenzando desde cero, probablemente quiera echar un vistazo a los constructores (eso es lo que hay debajo del capó de los marcos de aplicaciones de una sola página). JavaScript, CSS y algunos otros tipos de recursos estáticos se incluirán en el menor número posible de ensamblados y el resultado se minimizará tanto como sea posible. La personalización de la compilación es un tema extenso, pero afortunadamente hay mucha buena documentación al respecto. A continuación se muestran los coleccionistas más populares disponibles actualmente.
- Paquete web (https://webpack.js.org/). Uno de los primeros coleccionistas en lograr un progreso real. Todavía tiene muchos seguidores. Es muy complejo y hay un precio que pagar por esa complejidad: la curva de aprendizaje es empinada. Sin embargo, este empacador es bueno para aprender los conceptos básicos.
- Paquete (https://parceljs.org/). Apareció hace poco e hizo mucho ruido. Está muy bien documentado, es muy rápido y, lo que es más importante, tiene la curva de aprendizaje más corta. Es adecuado si necesita hacer el trabajo rápidamente y sin problemas.
- Paquete acumulativo (https://rollupjs.org/). Se encuentra en algún lugar entre Webpack y Parcel. Como Webpack, es robusto y rico en funciones. Sin embargo, es más fácil comenzar con Webpack, pero no tan fácil como Parcel.
Resumen
A pesar de su aparente simplicidad, los recursos estáticos son una gran molestia. Sin embargo, constituyen la mayor parte de los datos transmitidos a sus visitantes, por lo que el tiempo dedicado a optimizarlos valdrá la pena.
Una solución viable para los recursos estáticos, que no se mencionó anteriormente, es exponer los recursos estáticos a una CDN y siempre usar la URL completa del recurso en las vistas y CSS. Este enfoque tiene la ventaja de ser muy simple, pero si alguna vez deseas organizar un hackathon de una semana en una cabaña en el bosque sin acceso a Internet, ¡estás en problemas!
El montaje y la minificación cuidadosos son otra área en la que puede ahorrar tiempo si las ganancias de rendimiento de su aplicación no justifican el esfuerzo. En particular, si solo tiene uno o dos archivos JavaScript en su sitio, y todo el CSS está en el mismo archivo, puede omitir la construcción por completo, pero las aplicaciones del mundo real tienden a crecer con el tiempo.
Cualquiera que sea el método que elija para servir recursos estáticos, le aconsejo que los cargue por separado, preferiblemente en un CDN. Si te parece que es problemático, te lo aseguro: no es tan difícil como parece. Especialmente si dedicas un poco de tiempo al sistema de implementación de antemano para que la implementación de recursos estáticos en una ubicación y aplicaciones en otra sea automática.
Si está preocupado por el costo de hospedaje en un CDN, le insto a que eche un vistazo a las cantidades que está pagando actualmente por hospedaje. La mayoría de los proveedores de alojamiento cobran mucho dinero por el tráfico, incluso si usted no lo sabe. Sin embargo, si de repente su sitio aparece en Slashdot y experimenta el efecto de slashdot, es posible que reciba una factura de alojamiento completamente inesperada. El alojamiento CDN generalmente se configura de tal manera que solo paga por lo que usa. Por ejemplo, el sitio que dirijo para una empresa mediana local utiliza aproximadamente 20 GB de tráfico al mes, mientras que las tarifas de alojamiento estático (que es un sitio con muchos medios) son solo un par de dólares al mes.
Los beneficios de colocar recursos estáticos en una CDN son sustanciales y el costo y la inconveniencia de hacerlo son mínimos, por lo que le recomiendo encarecidamente que elija este camino.
Con ciertos trucos de JavaScript en el navegador, puede usar MENOS sin compilar. Sin embargo, este enfoque puede tener consecuencias negativas en términos de rendimiento, por lo que no recomiendo usarlo.
Se pueden encontrar más detalles sobre el libro en el sitio web de la editorial
» Tabla de contenido
» Extracto
Para los habitantes un 25% de descuento en el cupón - JavaScript
Al pagar la versión impresa del libro, se envía un libro electrónico por e- correo.