Configure CloudFront para alojar su aplicación web trucos CSS

En mi último artículo, vimos cómo configurar una aplicación web que sirve partes y paquetes de CSS y JavaScript de CloudFront. Lo integramos en Vite por lo tanto, cuando la aplicación se ejecuta en un navegador, CloudFront descargará los activos solicitados del archivo HTML principal de la aplicación como CDN.

Si bien el último almacenamiento en caché de CloudFront ofrece beneficios, el mantenimiento de los recursos de su aplicación desde estas múltiples ubicaciones no está exento de costos. Vamos a ver Prueba de página web rastreando mi propia aplicación web trabajando con la configuración de la última publicación del blog.

Esta publicación le mostrará cómo solucionar esto. Veremos cómo hospedar todo aplicación web de CloudFront y tener reenvío de CloudFront, o "proxy", solicitudes de datos no almacenados en caché, autenticación, etc. a nuestro servidor web principal.

Tenga en cuenta que esto es mucho más trabajo de lo que vimos en el último artículo, y las instrucciones probablemente serán diferentes para usted según las necesidades exactas de su aplicación web, por lo que su kilometraje puede variar. Cambiaremos los registros DNS y, dependiendo de su aplicación web, es posible que deba agregar algunos encabezados de caché para evitar que ciertos activos se almacenen en caché. ¡Miraremos todo esto!

Es posible que se pregunte si la configuración que vimos en el último artículo ofrece algunos beneficios debido a lo que hacemos aquí en este artículo. Dado el largo tiempo de conexión, ¿sería mejor renunciar a la CDN y, en su lugar, dar servicio a todos nuestros activos desde el servidor web para evitar esta espera más larga? Medí esto con mi propia aplicación web y la versión anterior de CDN fue realmente más rápida, pero no mucho. La carga inicial de la página LCP fue entre 200 y 300 ms más rápida. Y recuerda que esto es solo para el cargo inicial. Una vez que se configura esta conexión, el almacenamiento en caché de extremidades debería agregar mucho más valor a todas sus pistas subsiguientes cargadas de forma asíncrona.

Configurar nuestro DNS

Nuestro objetivo final es servir toda nuestra aplicación web cloudFront. Esto significa que cuando lleguemos a nuestro dominio, queremos que los resultados provengan de CloudFront en lugar de cualquier servidor web al que esté conectado actualmente. Esto significa que tendremos que cambiar nuestra configuración de DNS, usaremos AWS Route 53 para esto.

yo suelo mydemo.technology como ejemplo, que es el dominio que poseo. Aquí te mostraré todos los pasos. Pero mientras leo esto, eliminaré este dominio de mi aplicación web. Entonces, cuando comencé a mostrarles los registros CNAME reales y similares, ya no existirán.

Vaya a la página de inicio de Route 53 y haga clic en áreas alojadas:

Hacer clic Crear un área alojada e ingrese el dominio de la aplicación:

Realmente no hemos logrado nada todavía. Le dijimos a AWS que queríamos que él administrara este dominio por nosotros y AWS nos proporcionó los servidores de nombres a través de los cuales enrutar nuestro tráfico. Para implementar esto, debemos ir a donde esté registrado el dominio. Debe haber un lugar para iniciar sesión en sus propios servidores de nombres.

Tenga en cuenta que mi dominio está registrado en GoDaddy y esto se refleja en las capturas de pantalla de este artículo. La interfaz de usuario, la configuración y las opciones pueden diferir de lo que ve en su grabadora.

Atención: Le recomiendo que guarde los servidores de nombres originales, así como todos los registros DNS, antes de realizar cambios. De esa manera, si algo sale mal, tienes todo lo que necesitas para volver a ser como era antes de empezar. E incluso si todo funciona bien, aún querrá agregar cualquier otra entrada a la Ruta 53 nuevamente, es decir. registros MX, etc

Configurar una distribución de CloudFront

Hagamos una distribución de CloudFront para alojar nuestra aplicación web. Hemos cubierto los conceptos básicos en la última publicación, así que iremos directamente a eso. Un gran cambio desde la última vez es lo que estamos introduciendo para el dominio de origen. No coloque el dominio de nivel superiorpor ejemplo, tu-aplicación.net. Lo que necesita es el dominio principal donde se aloja su aplicación. Si se trata de Heroku, ingrese la URL proporcionada por Heroku.

Luego, asegúrese de cambiar el protocolo predeterminado si planea usar este sitio a través de una conexión HTTPS segura:

Esta parte es crucial. Si su aplicación web está realizando la autenticación, alojamiento de datos u otra cosa, asegúrese de activar verbos que no sean GET. Si omite esta parte, todas las solicitudes POST de autenticación, mutación de datos, etc. será Si su aplicación web no hace más que servir activos y todas estas cosas son manejadas por servicios externos, ¡entonces es genial! Tienes una gran configuración y puedes omitir este paso.

Necesitamos hacer muchos cambios en la clave de caché y la configuración de la solicitud de origen en comparación con la última vez:

Necesitamos crear una política de almacenamiento en caché con un TTL mínimo de 0 para que los encabezados sin almacenamiento en caché que devolvamos se cumplan correctamente. También es posible que desee activar todas las cadenas de consulta. Observé un comportamiento extraño cuando surgieron varias consultas de GraphQL junto con diferentes cadenas de consulta que se ignoraron, lo que hizo que todas estas consultas parecieran idénticas desde el punto de vista de CloudFront.

Mi política era esta:

Para una solicitud de política de origen, si es necesario, debemos asegurarnos de que enviamos cadenas de solicitud y cookies para que cosas como la autenticación y las solicitudes de datos funcionen. Para ser claros, esto determina si las cookies y las cadenas de solicitud se enviarán desde CloudFront a su servidor web (por ejemplo, Heroku o similar).

El mío se ve así:

Finalmente, para las reglas de encabezado de respuesta, podemos seleccionar "CORS With Preflight" de la lista. Eventualmente, sus dos primeros tendrán diferentes nombres dependiendo de cómo los configure. Pero el mío se ve así:

Vinculemos nuestro dominio, sea el que sea, a esta distribución de CloudFront. Desafortunadamente, esto es más trabajo de lo que cabría esperar. Necesitamos demostrarle a AWS que realmente somos dueños del dominio porque, hasta donde Amazon sabe, no lo somos. creamos una zona alojada en la Ruta 53. Y tomamos los servidores de nombres que nos diste y los registramos con GoDaddy (o con quien haya registrado tu dominio). Pero Amazon aún no lo sabe. Necesitamos demostrarle a Amazon que sí controlamos el DNS de este dominio.

Primero, te pediremos un certificado SSL.

Entonces vamos a pedir el enlace al certificado:

Ahora seleccionaremos la opción de solicitar una opción de certificado público:

Necesitamos proporcionar el dominio:

Y en mi caso el certificado está pendiente:

Entonces, voy a hacer clic en él:

Esto prueba que poseemos y controlamos este dominio. En una sección separada, regrese a la Ruta 53 y abra nuestra área alojada:

Ahora necesitamos crear el registro CNAME. Copia la primera parte para nombre de registroPor ejemplo, si CNAME es _xhyqtrajdkrr.mydemo.technologyluego pega _xhyqtrajdkrr parte. Para Valor de registrocopiar el valor completo.

Suponiendo que haya registrado los servidores de nombres de AWS con su host de dominio, GoDaddy o cualquier otra persona, AWS pronto podrá hacer ping al registro de DNS que deseaba crear, ver la respuesta que espera y confirmar su certificado.

Puede llevar tiempo distribuir los servidores de nombres que especificó al principio. En teoría, puede tardar hasta 72 horas, pero normalmente se actualiza en una hora para mí.

Verás el éxito en el dominio:

... así como el certificado:

Pobre de mí!! Casi termino. Ahora conectemos todo esto con nuestra distribución CloudFront. Podemos volver a la pantalla de configuración de CloudFront. Ahora, bajo la costumbre certificado SSLnecesitamos ver lo que hemos creado (y todos los demás que ha creado en el pasado):

Luego agreguemos el dominio de nivel superior de la aplicación:

Todo lo que queda es decirle a Route 53 que dirija nuestro dominio a esta distribución de CloudFront. Entonces, volvamos a Route 53 y creemos otro registro DNS.

Debe ingresar un registro A para IPv4 y un registro AAAA para IPv6. Para ambos, deje el nombre del registro en blanco, ya que solo registramos nuestro dominio de nivel superior y nada más.

Seleccione el tipo de registro A. Luego, especifique el registro como un alias y haga coincidir el alias con la distribución de CloudFront. Esto debería abrir una opción para seleccionar su distribución de CloudFront y, dado que registramos previamente el dominio con CloudFront, debería ver esa distribución y solo esa distribución al seleccionar.

Repetimos los mismos pasos para el tipo de registro AAAA que necesitamos para soportar IPv6.

Inicie su aplicación web y asegúrese de que realmente funcione. ¡Debería!

Cosas para probar y verificar

Bueno, aunque técnicamente estamos listos aquí, probablemente todavía hay algunas cosas que debe hacer para satisfacer las necesidades exactas de su aplicación web. Las diferentes aplicaciones tienen diferentes necesidades, y lo que he demostrado hasta ahora nos ha llevado a través de los pasos generales para dirigir las cosas a través de CloudFront para un mejor rendimiento. Probablemente hay cosas exclusivas de su aplicación que requieren más amor. Entonces, para eso, déjame ver algunos posibles elementos adicionales que puedes encontrar durante la configuración.

Primero, asegúrese de que todos los POST que tiene se envíen correctamente a su fuente. Suponiendo que CloudFront esté correctamente configurado para reenviar cookies a su fuente, esto ya debería funcionar, pero no hay nada de malo en la inspección.

De mayor preocupación son todas las demás solicitudes GET que se envían a su aplicación web. De manera predeterminada, todas las solicitudes GET que recibe CloudFront, si se almacenan en caché, se entregan en su aplicación web con la respuesta almacenada en caché. Esto puede ser catastrófico. Todas las solicitudes de datos a cada punto final REST o GraphQL enviadas con GET son almacenadas en caché por la CDN. Y si envía un trabajador de servicio, esto también se almacenará en caché, en lugar del comportamiento normal en el que la versión actual se envía a un segundo plano y se actualiza si hay cambios.

Para decirle a CloudFront no para almacenar en caché ciertas cosas, asegúrese de establecer "Cache-Control" encabezado a "no-cache" Si usa un marco como Rápidopuede configurar el middleware para el acceso a sus datos con algo como esto:

app.use("/graphql", (req, res, next) => {
  res.set("Cache-Control", "no-cache");
  next();
});
app.use(
  "/graphql",
  expressGraphql({
    schema: executableSchema,
    graphiql: true,
    rootValue: root
  })
); 

Para cosas como los trabajadores de servicio, puede establecer reglas específicas para estos archivos antes de su middleware estático:

app.get("/service-worker.js", express.static(__dirname + "/react/dist", { setHeaders: resp => resp.set("Cache-Control", "no-cache") }));
app.get("/sw-index-bundle.js", express.static(__dirname + "/react/dist", { setHeaders: resp => resp.set("Cache-Control", "no-cache") }));
app.use(express.static(__dirname + "/react/dist", { maxAge: 432000 * 1000 * 10 }));

Y así. Pruebe todo con cuidado, porque hay muchas cosas que pueden salir mal. Y después de cada cambio que realice, asegúrese de ejecutar una desactivación completa en CloudFront y borre el caché antes de reiniciar su aplicación web para probar si las cosas se excluyeron correctamente del caché. Puedes hacer esto desde discapacidades sección en CloudFront. Ábrelo y colócalo. /* por el valor de borrar todo.

Implementación funcional de CloudFront

Ahora que tenemos todo funcionando, ejecutemos nuestro seguimiento en WebPageTest nuevamente:

Y así es, ya no tenemos enlaces de ajuste, como vimos antes para nuestros activos. Para mi propia aplicación web, vi una mejora significativa de 500 ms en LCP. ¡Esta es una ganancia sólida!

---

Alojar una aplicación web completa en CDN puede ofrecer lo mejor de todos los mundos. Recibimos almacenamiento en caché final para recursos estáticos, pero sin costos de conexión. Desafortunadamente, esta mejora no es gratis. La configuración adecuada de todos los servidores proxy necesarios no es completamente intuitiva y aún existe la necesidad de configurar encabezados de caché para evitar solicitudes que no se pueden almacenar en caché para ejecutar en la caché de CDN.