Patrones Avanzados de Renderizado de Sitios en Jamstack

hablaré sobre los patrones avanzados de renderizado de sitios en JAMstack. Bueno, llegaré a mi introducción en un minuto. Sí, trabajo como ingeniero de experiencia de desarrollo en Netlify y tengo un canal de YouTube donde hago tutoriales en video sobre desarrollo web. Si quieres seguirme en las redes sociales, estoy en Twitter, en Ekene underscore IO. Vamos a ello. Vale, aún no vamos a ello porque también me gustaría decirte que además de ser ingeniero de experiencia de desarrollo y hacer mi cosa en YouTube y aprender JavaScript y trabajar con él, lo que realmente quiero hacer es ser un mixólogo para poder emborrachar a todos mis amigos sin motivo alguno. Esa es probablemente una historia para otro momento. Pero eventualmente, llegaré a contar la historia. Y espero que todos estén aquí para escucharla cuando eso suceda. Pero seguiré adelante y comenzaré hoy. Entonces, lo que aprenderás hoy es cómo funciona el renderizado en JAMstack. Si has estado construyendo aplicaciones JAMstack con Knox o con cualquier otro framework, en tu generador de sitios estáticos, entenderás mejor cómo funciona el renderizado. También entenderás los pros y contras de algunos de los patrones de renderizado que tenemos, lo que aportan y las compensaciones que también tienen. Por último, también aprenderás qué hacer cuando tu sitio JAMstack tiene un rendimiento deficiente. Por ejemplo, si tarda mucho en compilarse, entenderás por qué sucede eso y las cosas que puedes hacer para acelerar ese proceso. Pero antes de sumergirnos en ello, hagamos un viaje al pasado para entender por qué esto es importante en primer lugar. Muy bien. Hasta ahora, lo que sucede es que cuando un usuario llega a tu sitio y solicita productos. Y en este caso, me refiero a cuando un usuario llega a tu sitio web y hace clic en productos, idealmente lo que sucede es que se envía una solicitud a tu servidor y dependiendo de la arquitectura de tu servidor y cómo está configurado. Esta solicitud podría pasar por tus balanceadores de carga, tus servidores web, tus servidores de aplicaciones y bases de datos y todas esas cosas que suceden detrás de escena para atender esa solicitud. Idealmente, esto se envía, tu servidor procesa la solicitud, produce el contenido correcto y lo envía de vuelta al usuario. Mientras todo eso sucede detrás de escena, por supuesto, tu usuario verá una pantalla en blanco o una pantalla de carga o un spinner, dependiendo de cómo hayas construido tu sitio. Esto no es muy bueno para el desarrollador y tampoco es muy bueno para el usuario que utiliza la aplicación porque tienen que quedarse en una pantalla en blanco o una pantalla de carga durante un tiempo antes de que se sirva el contenido real. Pero construir de la manera de JAMstack nos ayuda a resolver ese problema, y lo resuelve de esta manera, ¿verdad? Todo ese procesamiento ocurre antes de que el sitio se publique. Por ejemplo, si has construido tu aplicación JAMstack, una vez que ejecutas el comando de compilación, lo que sucede es que el generador de sitios estáticos se encarga de hacer todas las solicitudes en tu nombre, ¿verdad? Y genera todas las páginas, genera todas las rutas dinámicas y todas las partes que estarán disponibles en tu aplicación. Y luego el contenido se sirve a tus usuarios. Entonces, lo que sucede ahora es que en lugar de que los usuarios lleguen a tu sitio y hagan clic en botones para hacer solicitudes, todas esas solicitudes se realizan en tiempo de compilación para que cuando tus usuarios lleguen al sitio, todo el contenido que necesitan esté disponible de inmediato. Entonces no hay retrasos, no hay tiempo de espera, no hay giros de carga que duren para siempre. Entonces, esta es una buena manera, pero como puedes imaginar, como toda solución, como en todas partes que

La tecnología viene con una solución, también tiene algunas compensaciones. Pero antes de hablar sobre las compensaciones, los beneficios que obtenemos al utilizar el enfoque JAMstack son que tu sitio es más rápido y tus usuarios están contentos. ¿Verdad? Si nunca tienes que esperar en pantallas de carga para obtener contenido, o si visitas un sitio y ves que es rápido, si haces clic en un botón y todo sucede como debería sin retrasos, tus usuarios estarán contentos. Como usuario, yo estaría contento, ¿verdad? Y también obtienes un mejor SEO de manera predeterminada, ya que como desarrollador o propietario del sitio, todo el contenido de tu sitio está disponible de inmediato. Entonces, Google y todos los motores de búsqueda estarán contentos. Pueden rastrear e indexar tu sitio correctamente porque todo el contenido está disponible con anticipación. Y también, implementar en la CDN significa que tienes un punto de ataque limitado. Por lo tanto, es más seguro porque solo tienes que preocuparte por tu sitio y la CDN. No tienes que preocuparte por asegurar tus bases de datos, tus balanceadores de carga, tus servidores web y todas esas cosas, solo tienes que preocuparte por tu propia aplicación y la CDN se encarga del resto por ti. Construir de esta manera también permite a los desarrolladores mantenerse dentro de sus habilidades principales. Me refiero a mí mismo como un desarrollador de front-end. Me gusta construir con Vue.js y Nox.js. Nunca quiero tener que preocuparme por cómo funcionan los balanceadores de carga o los contenedores o Docker, ¿verdad? Y construir de esta manera me ayuda a mantenerme dentro de mi conjunto de habilidades y no preocuparme por esas cosas que no conozco.

cómodo de forma predeterminada. De todos modos, eso es todo acerca de construir de esta manera. Si te sientes como estas personas que están bailando aquí, así es exactamente como me sentí cuando terminamos la plataforma JAMstack Explorer con mi equipo, lo construimos todo en la JAMstack, hicimos muchas cosas dinámicas, pero al final del día, nos divertimos y realmente no hicimos tantas cosas que nos hacen sentir incómodos como desarrolladores.

Muy bien, pero como dije, cada nueva solución introduce sus propias compensaciones. Entonces hay un poco de compensación aquí, que es que si construyes de esta manera, cuando tu sitio se vuelve grande, como puedes imaginar, ya que el proceso de construcción genera todas esas páginas de antemano, significa que si tienes muchas páginas en tu aplicación, si tienes 10,000, 100,000 páginas, todas esas páginas se generarán en el momento de la construcción, lo que significa que tendrás que esperar un poco más para que tus sitios se construyan en lugar de simplemente implementarlo tal como está. Y para que eso sea un poco más claro, imagina que tienes un sitio como este que tiene mil productos. Una vez que comienza tu proceso de construcción, todos esos productos, todos esos productos se generarán. Esto es antes de que tu sitio se implemente antes de que se publique. Entonces, el proceso de construcción lleva, veamos esto 100, 200, 300, 400. Va todo, todo el camino hasta 8,000 productos se generan, y luego, si tienes más, si tienes como 50,000, por ejemplo, tendrás que esperar todo ese tiempo para que expire antes de que se generen y se implementen todas tus páginas de productos. Entonces, por ejemplo, supongamos que tengo un sitio llamado misitio.com. En ese sitio, tengo 1,500 páginas de productos, páginas de blog y comunicados de prensa. Ahora, lo que sucede es que tengo un total de 4,000 páginas, ¿verdad? Entonces, si quiero implementar este sitio, mi proceso de construcción se activará y pregenerará todas estas páginas. Y digamos hipotéticamente, esto no es ideal de ninguna manera, pero digamos para los fines de esta presentación, que le lleva a nuestro generador de sitios estáticos un segundo construir una página. Como dije, esto no es la realidad, pero trabajemos con eso. Entonces, suponiendo que lleva un segundo construir una significa que me llevará 4,000 segundos implementar los sitios, construir el sitio antes de implementarlo. Y eso es como una hora más, ¿verdad? Entonces, imagina construir tu sitio, prepararlo, terminar, poner los toques finales y simplemente querer implementar tu sitio y tener que sentarte y esperar una hora para que se construya. Eso no es bueno. Nadie quiere eso. Y eso no es todo, ¿verdad? Si quieres actualizar el sitio, pasas por el mismo proceso exacto. En este caso, imagina que quieres agregar una página de producto más a tu sitio existente, que has construido e implementado. Lo que sucede es que tu producto va a obtener una página de producto más, ¿verdad? Entonces, en lugar de tener 1,500, tienes 1,501, lo que te da 4,001 páginas. Y lo que sucede es que, debido a que es un sitio Jamstack, el proceso de construcción se reiniciará. Y cuando eso suceda, volverá a construir todo el sitio nuevamente. Entonces, eso es otra hora más que tienes que esperar para que tu sitio se construya, solo porque actualizaste una página de producto. Eso no es ideal. No quiero eso. Estoy seguro de que tú tampoco, lo que nos lleva a las soluciones. Mientras todo esto está sucediendo, todos en la comunidad se dieron cuenta de que esto es un cuello de botella que debía solucionarse. Entonces, eso es algo bueno de la comunidad de Jamstack, todos se unen para encontrar soluciones a problemas como este que afectan a todos.

Entonces, la primera solución es la compilación incremental. Creo que esto se originó en Gatsby hace algunos años cuando estaban buscando cómo reducir los tiempos de compilación en el Jamstack. Y solo para dejar eso muy claro, lo que hace la compilación incremental es imaginar que tienes un sitio que tiene solo siete páginas de productos. Cuando implementas el sitio, será un sitio en vivo. Las personas pueden interactuar con él, pero solo pueden ver siete productos, porque eso es lo que está disponible en tu sitio. Pero ¿qué sucede cuando actualizas ese sitio y agregas otra página de producto para tener ocho páginas? En este caso, se regenerará todo tu sitio. Y lo que eso significa es que, en lugar de construir solo una página, se construirán ocho páginas, porque se construirá incluso la que ya se había construido antes, porque por supuesto, tiene que regenerar todo el sitio. Lo que hace la compilación incremental es darte la oportunidad de construir solo la nueva página que has introducido en tu sitio y dejar las páginas anteriores como están. Esto ahorra una cantidad increíble de tiempo cuando se trata de compilaciones posteriores de tu sitio. En este caso, tenías siete páginas construidas antes, agregaste una página más, solo se genera esa nueva página, todo lo demás se mantiene como está. Entonces, al actualizar tu sitio, nunca tienes que esperar todos esos tiempos largos para reconstruir todo tu sitio. Pero, por supuesto, tiene sus compensaciones, no afecta la compilación inicial. Por ejemplo, si tuviera como 4000 páginas como en los otros ejemplos, cuando implemento ese sitio, todavía tendré que esperar ese tiempo de una hora más, tiempo hipotético para esperar a que se construya el sitio por primera vez para que no se vea afectado. Solo tiene un impacto en las compilaciones posteriores y las actualizaciones del sitio. Y también rompe los conceptos de implementación atómica e inmutable, que es algo en lo que nos enfocamos mucho en el JAMstack. Si no sabes qué es eso, pondré un enlace en la descripción en la sección de recursos para que puedas consultarlo y ver qué es eso.

se trata de eso. Muy bien, y la siguiente solución que surgió en la community son los micrositios. Este patrón literalmente dice que si tienes un gran conjunto de sitios que están juntos y tienen muchas páginas diferentes, considera dividirlos en diferentes micrositios para que sea fácil de gestionar como variaciones independientes de tu sitio en lugar de un gran conjunto que debe construirse en conjunto. Para visualizar esto, considera este globo en la pantalla ahora mismo como un sitio web grande que tiene tres secciones diferentes: productos, blog y prensa. Lo que sugiere este patrón es dividir esto en tres sitios distintos para que no estén todos juntos en un solo sitio grande que debe construirse en conjunto. La ventaja de hacerlo de esta manera es que todas las partes de tu sitio son independientes entre sí, lo que significa que si estoy construyendo mi sitio de productos, no afecta a mi blog y no afecta a mi prensa. Si estoy actualizando una página del blog, mi sitio de productos no se reconstruirá. El sitio de comunicados de prensa no se reconstruirá porque son sitios individuales e independientes que están vinculados a mi sitio principal mediante proxies y redirecciones. Y cómo funciona es imaginemos que tengo estos tres sitios divididos en diferentes sitios web desplegados. Tengo un sitio web de productos. Tengo un sitio web de blog, un sitio web de prensa, que son todos sitios individuales, independientes. Y luego llego a mi sitio.com, que es donde quiero reunirlos a los tres. Puedo usar una redirección para dirigir mi página sitio.com/productos, para que apunte a ese sitio web de productos que he construido en otro lugar. Lo mismo sucederá con el blog y la prensa. Y si no te gustan las redirecciones o prefieres usar proxies, eso también está disponible según tus preferencias y cómo quieras diseñar tu sitio.

Ah, bueno, por supuesto, tiene algunas compensaciones y advertencias. Como dije antes, tiene redirecciones y proxies complejos. Entonces, si no estás muy familiarizado con las redirecciones o cómo funcionan los proxies, esto puede no ser muy amigable para ti porque realmente necesitas entender cómo hacer eso. Para construir un micrositio, no afecta a las compilaciones iniciales. Es como el funcionamiento de las compilaciones incrementales, no tiene mucho impacto en la compilación inicial porque si estás implementando tus sitios de productos, si estás implementando tu blog, si estás implementando tu prensa, todo se implementa como sitios independientes. Pero si todavía tienes, por ejemplo, 5000 páginas de productos en el sitio, aún llevará todo ese tiempo volver a construirlo. Aunque ahora es más pequeño porque es un solo sitio en lugar de construir los tres sitios juntos. Por supuesto, tienes varios sitios que gestionar. En este caso, solo tengo tres sitios, productos, blog y prensa, pero imagina que tienes 15 sitios diferentes, secciones de tu sitio que estás construyendo de forma independiente. Significa que tienes, significa que tienes tantos sitios que debes gestionar de forma individual, lo cual puede ser difícil a veces. Esto nos lleva a la última solución, la solución de ISR. Aquí es donde las cosas comienzan a ponerse interesantes, diría yo. Regeneración estática incremental. Eso siempre es complicado de decir. ¿Por qué? Bueno, te permite elegir qué tipo de páginas, cuántas páginas quieres

para construir en el momento de la compilación. ¿Tiene sentido? No, te permite elegir cuántas páginas quieres generar en el momento de la compilación en lugar de generar todo por defecto, ¿verdad? Simplemente dice: `Ok, tengo 10,000 páginas, pero quiero generar solo cien de esas páginas cuando se construye mi sitio y haré el resto cuando los usuarios las soliciten. Y cómo funciona es así, este es un proceso típico de JAMstack, ¿verdad? Cuando construyes tu sitio, se generan todos los activos, todas las páginas y todas las rutas dinámicas y todo, ¿verdad? Pero lo que digo es que te daré la oportunidad de generar solo una parte de esas páginas. No tienes que hacer todo en el momento de la compilación. Puedes generar solo las que quieres que tus usuarios vean de inmediato, y luego puedes hacer el resto cuando las personas las soliciten, lo cual es genial, ¿verdad? Ahora, así es como se desarrolla. Sé que ya estás preguntando, como qué sucede cuando un usuario solicita una página que no se pregeneró en el momento de la compilación ¿verdad? Esa es una buena pregunta. Pero lo que sucede es que primero necesitas entender que cuando se genera y despliega tu sitio, todo el contenido del sitio se envía a la CDN que luego sirve a tus usuarios, ¿verdad? Ahora, cuando una página no existe en la CDN y un usuario la solicita, como en este caso, la página que he marcado con el círculo rojo lo que sucede es que esa página en particular comienza a regenerarse. Bueno, en este caso, comienza a generarse por primera vez porque no se generó antes. Y mientras eso sucede, ISR servirá una versión de respaldo de esa página a tus usuarios para que no vean una pantalla de carga o algo así. Y mientras eso sucede en segundo plano, la página se está generando. Y cuando la generación haya terminado, la página se coloca en la CDN que luego sirve a tus usuarios el contenido real. Genial. Genial. Todo bien. Antes de hablar sobre las advertencias, observa cómo tiene un gran impacto en la compilación inicial que hemos estado tratando de resolver durante un tiempo. Porque ahora tienes la oportunidad de decir: `Oh, no quiero generar cada parte de mi sitio al mismo tiempo cuando se está construyendo mi sitio, solo quiero generar el 5% de él`. Literalmente puedes decidir qué páginas quieres generar en el momento de la compilación. Tiene un gran impacto en nuestra compilación inicial porque, a diferencia de esperar a que se construyan 5,000 páginas, puedes construir 100 o 500. Y eso asegurará que tu sitio se implemente mucho más rápido que antes. También nos brinda lo mejor de ambos mundos, ¿verdad? Puedes generar estáticamente todas tus páginas, pero cuando solo solicitas contenido que no se generó en el momento de la compilación, puedes usar SSR para generar esas páginas y servirlas a los usuarios. Pero, por supuesto, también tiene sus compensaciones. Debido a que ISR utiliza la estrategia de caché de revalidación obsoleta, significa que corres el riesgo de servir contenido obsoleto a tus usuarios cuando el sitio se está revalidando. También he puesto un enlace en la sección de recursos si quieres entender mejor la revalidación obsoleta, lo pondré allí para explicarlo muy bien. También compromete las implementaciones atómicas y de grupo limitado debido a cómo afecta al contenido que se actualiza en un sitio que ya se ha implementado sin volver a implementar los sitios para purgar la caché y todo eso. Esto tampoco es agnóstico al framework. Soy un desarrollador front-end y me gusta construir con Vue y Knox. Pero esto solo está disponible para los desarrolladores del próximo año, lo que significa que realmente no me ayuda de ninguna manera. Esas son algunas advertencias.

Veamos la última solución de la que quiero hablar hoy. Y eso es el renderizado persistente distribuido que actualmente está en beta, pero probablemente saldrá de beta pronto. Lo que hace es eliminar la necesidad de revalidación y purgar completamente la caché cuando hay una nueva implementación. De esta manera, todo el contenido que has generado está disponible para tus usuarios, se llama contenido crítico, el contenido que has diferido se generará solo cuando un usuario lo solicite. Y creo que esto utiliza funcionesserverless para generar esas páginas bajo demanda y luego ponerlas en la caché. Cuando necesitas actualizar la caché, simplemente ejecutas una nueva implementación y se purgará la caché. Y esto es intencional porque de esta manera se preservan las implementaciones atómicas e inmutables y no estamos comprometiendo ninguno de los conceptos de Jamstack que realmente nos importan. Y hemos visto esto cobrar vida con el lanzamiento de Gatsby v4, algo llamado generación estática diferida, que es un nuevo modo de renderizado que se introdujo en Gatsby 4. Y como puedes ver, está ahí fuera en el mundo, la gente lo está usando. Creo que me gusta especialmente. Actualmente estoy construyendo algo con DSG y estoy viendo cómo podemos hacer completamente SSG y SSR en sitios Jamstack sin comprometer ninguno de los principios fundamentales que realmente nos importan. La sección de recursos de la que hablé, voy a añadir todos los enlaces a las cosas de las que hablé para proporcionarte más recursos para que puedas entender algunas de estas cosas si aún no las conoces o si no estás familiarizado con ninguna de estas cosas. Y gracias a todos por tenerme aquí. Ha sido divertido. Me lo he pasado bien compartiendo estas cosas con todos. Una vez más, estoy en Twitter y en todas partes en la web en kenny underscore io y ese es mi canal de YouTube en la pantalla si quieres echar un vistazo. Gracias a todos y nos vemos la próxima vez. Adiós.