Nuevos modos de renderizado en Gatsby v4

Rate this content
Bookmark

Gatsby v4 ahora tiene SSR y un nuevo modo de renderizado llamado DSG. Entre SSG, SSR, DSG, ISR y DPR, el Jamstack ha visto recientemente una avalancha de nuevos modos de renderizado que funcionan para cada caso de uso que parecía inviable en el pasado. Pero saber qué elegir para tu sitio o una parte de tu sitio y qué hace cada uno de estos realmente bajo el capó es confuso y fácil de hacer incorrectamente.

Esta pista aclarará la confusión y se adentrará en cada uno de ellos, discutiendo matices e incluso echando un vistazo bajo el capó para ver cómo funcionan y qué promesas de escalabilidad y consistencia ofrecen y cuáles cumplen.

24 min
22 Oct, 2021

Video Summary and Transcription

Gatsby v4 introduce la generación estática diferida (DSG), combinando los beneficios de la generación de sitios estáticos (SSG) y el renderizado en el servidor (SSR). Este enfoque permite construcciones más rápidas y una caché más determinista. Gatsby v4 también incluye características como la ejecución de consultas en paralelo y LMDB para un rendimiento mejorado. El enfoque se centra en las integraciones y en mejorar la experiencia del desarrollador (DX) en el futuro.

Available in English

1. Introducción a Gatsby v4 y Jamstack

Short description:

Mi nombre es Sid, trabajo en Gatsby Inc. He estado allí por un tiempo. Gatsby Cloud es el mejor lugar para construir y implementar tus sitios de Gatsby. Hablemos de lo que eso significa. Jamstack ha estado presente por un tiempo. Los principios fundamentales de la pre-renderización y el desacoplamiento se supone que te brindan más confianza en tu sitio. La generación de sitios estáticos ha funcionado bien para nosotros durante un tiempo. En Gatsby en Gatsby Cloud, hemos visto sitios bastante grandes, hemos visto sitios de comercio electrónico y blogs y demás. Hemos visto sitios que han llegado a casi 100,000 páginas. Y es increíble que podamos hacer eso con lo que comenzó como un simple generador de sitios estáticos. Es bueno para el SEO, es rápido y también es barato de implementar.

Un tiempo realmente largo. De hecho, creo que algunos de ustedes los conocí por primera vez, así que ha sido genial. Ha sido surrealista, realmente. Mi nombre es Sid, trabajo en Gatsby Inc. He estado allí por un tiempo.

A lo largo de los años, he ayudado a construir y mantener el proyecto de código abierto de Gatsby. Más recientemente, he estado trabajando en Gatsby Cloud. Gatsby Cloud es el mejor lugar para construir e implementar tus sitios de Gatsby. Y voy a hablar sobre varias cosas diferentes que hemos hecho con Gatsby v4. En caso de que te lo hayas perdido, hemos estado ocupados. Gatsby v4 salió ayer y tiene varios modos de renderizado. Hablemos de lo que eso significa.

Entonces, antes de todo eso, una breve lección de historia. Jamstack ha estado presente por un tiempo. Han pasado un par de años. Pero cuando comenzó, eran solo sitios estáticos. Tenías generadores de sitios estáticos como Hugo, ahora tienes Eleventy. Eleventy, hemos tenido Gatsby, Next, en algún momento también agregó SSG. La idea con Jamstack era preconstruir tus activos, HTML, CSS, JavaScript, etc. Y desplegarlo en el edge. Y los principios fundamentales, como dije, copié y pegué esto, los principios fundamentales de la pre-renderización y el desacoplamiento se supone que te brindan más confianza en tu sitio.

Lo interesante de esto es la pre-renderización. ¿Por qué te brinda más confianza y por qué es más resistente? Porque lo que necesitas hacer para construir una página ya está hecho, no tienes que hacerlo en el momento de la solicitud. Por lo tanto, hay muy poco que pueda salir mal, sin embargo, no siempre es tan simple. Antes de llegar a por qué no es simple. La generación de sitios estáticos ha funcionado bien para nosotros durante un tiempo. En Gatsby en Gatsby Cloud, hemos visto sitios bastante grandes, hemos visto sitios de comercio electrónico y blogs y demás. Hemos visto sitios que han llegado a casi 100,000 páginas. Y es increíble que podamos hacer eso con lo que comenzó como un simple generador de sitios estáticos. Y en caso de que te hayas perdido los beneficios de SSG en los últimos años, es bueno para el SEO, es rápido y también es barato de implementar.

2. Introducción a Netlify y SSG

Short description:

Tenemos a Matt aquí de Netlify. Netlify se ha convertido en la forma predeterminada de implementar cosas porque es barato y gratuito. Cuando visitas un sitio en Netlify o Gatsby Cloud, estás accediendo efectivamente a un depósito de almacenamiento y obteniendo un archivo estático. No hay mucho código en ejecución en tiempo de ejecución, lo que lo hace resistente.

Tenemos a Matt aquí de Netlify. Probablemente todos ustedes hayan usado Netlify en algún momento, ¿verdad? Y casi se ha convertido en la forma predeterminada de implementar cosas, ¿verdad? Porque es barato, es gratuito. Él está justo allí, por cierto, su foto estaba justo allí por un segundo. Y en caso de que, ya sabes, quieras saber cómo se ve realmente SSG bajo el capó, cuando visitas un sitio en Netlify, Gatsby cloud, cualquiera de estos hosts, estás accediendo efectivamente a un depósito de almacenamiento, ya sea S3, GCP o cualquier otro. Estás obteniendo un archivo estático. No hay mucho código que se esté ejecutando en runtime, y por eso es tan resistente.

3. Desafíos con SSG y la Introducción de SSR

Short description:

Esto no siempre es escalable para sitios realmente grandes. Con el tiempo, a medida que agregas más productos, el tiempo de construcción puede volverse extremadamente lento, lo que lo hace impráctico. Una forma de abordar esto es utilizando el renderizado del lado del servidor (SSR), que implica tener un servidor que sirva cada solicitud y una caché delante de él. Sin embargo, el uso de SSR significa perder los beneficios de la generación de sitios estáticos (SSG) y presenta desafíos con la imprevisibilidad de la caché.

Hablemos un poco más sobre dónde esto se desmorona, ¿de acuerdo? Esto no siempre es escalable. He escuchado esto a lo largo de los años de personas en GitHub, en Twitter, etc. Que es genial para tu blog, o para un sitio pequeño, pero no es escalable para sitios realmente grandes. ¿Qué pasa si tienes muchas páginas y demás? No estoy de acuerdo. Hablaremos sobre por qué.

Supongamos que quieres construir un sitio de e-commerce, ¿de acuerdo? Comienzas con lo que parece una plantilla de Tailwind UI, que compré, por cierto. Y tienes una página de inicio con tus productos y demás, y tienes alrededor de 20-30 productos y se construye rápidamente y todo es genial. Y tienes otra página donde tienes una camiseta que vendes y todo es maravilloso. Todo tu sitio se construye en menos de un minuto. La vida es buena. Pero luego, tienes muchos más productos, ¿de acuerdo? Con el tiempo, ganas dinero, vendes más camisetas o tazas o lo que estés vendiendo. Y ahora, de repente, esto sucede. ¿Ves esa marca de tiempo allí? Eso es una hora y 54 minutos. No me lo inventé. Esa es una captura de pantalla. Julian trabaja conmigo, esa es una captura de pantalla. Un sitio tardó una hora y 54 minutos en construirse. Es algo inutilizable, ¿no? Quiero decir, no puedes esperar dos horas después de cada cambio que hagas. Y esto es real. Hemos visto esto. Hemos tenido clientes que han visto esto. Y esta es una de las razones por las que SSG se desmorona, puede volverse lento, porque quieres hacer todo ese trabajo en tiempo de construcción, y tal vez eso sea demasiado trabajo. Entonces, ¿cómo solucionas esto? Bueno, en nuestro sitio de e-commerce que estamos tratando de construir, lo que normalmente haces es, ya sabes, te frustras, y dices, hey, esto no es escalable, y llamas a un viejo amigo. Next. O realmente cualquier cosa que haga SSR.

Y la forma en que funciona SSR es que, bueno, hemos hecho esto a lo largo de los años, tienes algún servidor, ya sea Node.js, PHP, lo que sea, que sirve cada solicitud, ¿de acuerdo?, y tienes una caché delante de él. Funciona bien, nos ha servido durante años, pero ahora has perdido todos los beneficios y todo lo que SSG te prometió, todo lo que querías que fuera estático en primer lugar. La caché es mucho más difícil de predecir, no es determinista. La caché tiende a ser específica del usuario, a veces incluso específica del borde, ¿verdad? Es difícil saber qué está en caché en qué momento para tu sitio, para todos tus usuarios.

4. Desafíos con SSG y APIs en tiempo de ejecución

Short description:

También consumes todos estos servicios y APIs en tiempo de ejecución. ¿Recuerdas cuando Facebook se cayó hace un par de semanas? Tu página no se renderiza. Así que es frágil. Y supongamos que eso no sucede y escalas bien, eso puede volverse realmente costoso. Y esto es lo que ves cuando todo se desmorona.

También consumes todos estos servicios y APIs en tiempo de ejecución. ¿Recuerdas cuando Facebook se cayó hace un par de semanas? Quiero decir, si ellos pueden caer, nuestras APIs también pueden caer, ¿verdad? Y supongamos que eso sucede en tiempo de ejecución cuando intentas visitar una página. ¿Qué sucede? Tu página no se renderiza. Así que es frágil. Y supongamos que eso no sucede y escalas bien, eso puede volverse realmente costoso, ¿verdad? Y esto es lo que ves cuando todo se desmorona. Puedes ver que obtuve eso de internet, porque Gatsby, esto nunca sucede. Así que descargué la captura de pantalla.

5. Desafíos con SSG y Generación Diferida de Estática

Short description:

Por eso, a menudo optas por SSR cuando tienes muchas páginas. En el momento en que mezclas SSG con SSR, tienes un conjunto completamente nuevo de problemas. Con Gatsby V4, tenemos lo que llamamos generación diferida de estática. Obtienes todos los beneficios de la generación estática de páginas, pero con la escala de SSR. La idea es que, en lugar de construir todas las páginas, solo construyes las críticas y pospones el resto. Tus tiempos de construcción se convierten en una función de tu tráfico. Gatsby crea una instantánea de tus datos y el paquete de JavaScript en el momento de la construcción para generar las páginas más tarde. Este enfoque también proporciona una caché más determinista.

Por eso, a menudo optas por SSR cuando tienes muchas páginas. En el momento en que mezclas SSG con SSR, tienes un conjunto completamente nuevo de problemas. Con SSG, es genial para un par de páginas. Así que digamos que construyes tu página de inicio estáticamente porque no cambia con tanta frecuencia. Y en nuestro ejemplo del que hemos estado hablando durante un tiempo, tus páginas de producto se generan mediante SSR. Es un buen compromiso. Escala bien, ¿verdad? Tus construcciones ya no tardan dos horas, pero pierdes la atomicidad de la construcción. Y lo que quiero decir con atomicidad de la construcción es que ambas partes de tu sitio se construyen de forma independiente en diferentes momentos. Es difícil asegurarse de que sean consistentes entre sí. Puedes encontrarte con una página de inicio que dice que el producto A está disponible y hacer clic para luego ver que no lo está. Y eso es una experiencia terrible. No quieres eso.

Entonces, ¿cómo solucionas esto? ¿Cómo llegas a un compromiso y tienes construcciones rápidas pero también consistencia en las páginas, pero aún intentas construir algunas cosas más tarde? Es complicado. ¿Cómo pospones un poco el trabajo? En el espectro del que hemos estado hablando con SSR en un extremo y SSG en el otro, tiene que haber algo intermedio, ¿verdad? Quiero decir, SSR es maravilloso para algunos casos de uso. SSG debería ser tu opción predeterminada. Pero, ¿qué pasa con estos casos de uso intermedios? Y eso es realmente de lo que trata esta charla. Con Gatsby V4, tenemos lo que llamamos generación diferida de estática. Puedes pensar en ello como SSG, pero más tarde. Obtienes todos los beneficios de la generación estática de páginas, pero con la escala de SSR. Y esto puede sonar demasiado bueno para ser verdad, pero en realidad es bastante simple. La idea es que hablamos de todo ese trabajo que necesitas hacer para construir todas estas páginas, que llevaba como dos horas, pero en lugar de construir todas ellas, solo construyes las críticas, pospones las que no son tan críticas. Y ahora, en lugar de que tus tiempos de construcción sean una función del número de páginas que tiene tu sitio, es una función de tu tráfico. Lo cual es bastante interesante si lo piensas. Además, no necesitas acceder a estas APIs o consumir estos servicios en tiempo de ejecución. Lo que hace Gatsby es que creará una instantánea de tus datos y el paquete de JavaScript en el momento de la construcción y lo usará para generar estas páginas más tarde. Además, tu caché es mucho más determinista. Recuerda que hablamos de la caché, la caché es difícil, ¿verdad? Es uno de los problemas más difíciles con los que tenemos que lidiar y resolver. Una caché no determinista puede causar mucha confusión.

6. Generación Diferida de Estática y Modos de Renderizado

Short description:

Con la generación diferida de estática, tu caché es global y atómica, eliminando inconsistencias. El proceso implica ejecutar código para generar una página a partir de una instantánea, almacenándola en caché como activos estáticos. Las solicitudes posteriores para la página se sirven como cualquier otra página SSG. Gatsby 4 ahora admite estos modos de renderizado.

Con la generación diferida de estática, tu caché no es específica del borde ni del usuario. Tu caché es global, como suele ser con SSG, pero aún puedes obtener estos beneficios de poder posponer parte del trabajo. Y como resultado de eso, también es atómico. No tendrás esas inconsistencias de las que hablamos.

Hablemos un poco más sobre cómo funciona, sin embargo. Aquí hay un bonito diagrama. Y si lo miras, hay dos secciones. Está la primera solicitud en la parte superior y la segunda solicitud debajo de ella. Veamos la primera. La primera se ve igual que una solicitud de SSR. Accedes a una URL, hay un caché perdido, así que en su lugar vuelves a algún lugar. ¿Verdad? En algún lugar. En algún lugar. Hay algún código en ejecución. Digamos que la página se llama about. Hay algún archivo llamado about.js que se ejecuta, mira esa instantánea, genera esa página para ti, hace todo lo que necesitas. Al igual que un servidor SSR. Y envía esa respuesta de vuelta. Mira lo que más hace. También lo almacena en caché. Y esto puede parecer bastante simple en la superficie, pero es muy diferente de cómo es SSR y a lo que estamos acostumbrados. Esa caché no es una caché HTTP. Esa caché son los activos estáticos guardados en algún lugar. Así que cada vez que haya una solicitud después de eso, simplemente la obtienes como lo harías para cualquier otra página SSG. Y eso no es la primera solicitud ni la segunda solicitud para un usuario específico. Es la primera y segunda solicitud en general. Así que si envío un sitio Gatsby con una página marcada como diferida, y si mi rastreador llegara a una página, la generaría. Y cualquier otra persona que visite mi sitio después de eso obtendría esa página como cualquier otra página estática. Así que puedes ver hacia dónde va esto. Gatsby 4 ahora admite todos estos diferentes modos de renderizado.

7. SSG, SSR y DSG en Gatsby

Short description:

Tenemos SSG, SSR y DSG. Optar por DSG es fácil con la función create page y configurando defer en true. SSR es similar con la función get server data. Puedes combinar SSR y datos de tiempo de compilación, lo que permite contenido dinámico y estático en la misma página. Se proporcionan ejemplos de SSR y diferimiento.

Tenemos SSG, que es como de antemano, ¿verdad? Tenemos SSR, que es justo a tiempo, y tenemos DSG, a lo que me gusta llamar a la moda tarde. No es difícil de usar tampoco. Si miras la documentación, realmente todo lo que necesitas hacer para optar por DSG para una página es ejecutar create page. Si has usado Gatsby antes, probablemente lo hayas visto. Si no lo has hecho, es una función. Necesitas pasar una opción más, configurar defer en true, y listo. Incluso puede ser una condición.

En la mayoría de los casos, tus complementos lo manejarán por ti incluso. Optar por SSR es similar. Exportas una función en tu archivo. Se llama get server data. Esto es muy similar a lo que hace Next con get server side props, creo. Las páginas en las que optas por esto se omiten automáticamente en el tiempo de compilación, por lo que no necesitas hacer nada más. Todo funciona. Todo se invalida. Todo está cuidado. Incluso puedes combinar algunas páginas con data de SSR y data de tiempo de compilación. Eso es bastante increíble si lo piensas. Puedes tener páginas de productos que tienen datos de productos que no cambian con frecuencia, que se obtienen en el tiempo de compilación, y puedes tener datos de disponibilidad obtenidos en tiempo de ejecución. Puedes combinar eso en una página. Así que realmente en ese espectro, puedes estar en cualquier punto intermedio con todas tus páginas.

Es Gatsby. Cómo se ven esos ejemplos es así. Así es como se ve una página de SSR en Gatsby. Tienes un componente react como siempre hemos tenido. Lo único diferente aquí respecto a una página regular es esa pequeña exportación al final. Exporta una función asíncrona que obtiene nuestros data. En el momento en que exportas esa función desde un archivo de página o una plantilla, eso se convierte en una página de SSR. Y el ejemplo para el diferimiento es, como dije, es una clave. Simplemente configuras defer en true y eso es todo.

8. Características y disponibilidad de Gatsby V4

Short description:

Tu página está diferida. Gatsby V4 introduce la ejecución paralela de consultas, lo que resulta en compilaciones más rápidas. Gatsby V4 también incluye LMDB, que mejora el rendimiento. Prueba Gatsby V4 ahora e instálalo con 'BM install Gatsby'. Funciona en Gatsby Cloud y otras plataformas en la nube. Gatsby sigue siendo de código abierto.

Tu página está diferida. Todo esto está en Gatsby V4. Tuve que mantener la diapositiva porque es muy bonita. Tiene un doblez agradable. Parece la portada de un álbum de K-pop. Pero sí, todo está en Gatsby V4.

Gatsby V4 tiene otras cosas también. Ahora tenemos la ejecución paralela de consultas. Hemos descubierto cuántos hilos tienes en tu máquina. Ejecutamos todas tus consultas en paralelo. Tus compilaciones son más rápidas. Esperemos que lo notes. Pero no tienes que hacer nada para optar por ello. Simplemente funciona. Es algo que está bajo el capó. También hay muchas otras cosas bajo el capó, incluyendo algo llamado LMDB, que como usuario de Gatsby, no tienes que conocer ni preocuparte, pero se utiliza bajo el capó y hace posible muchas de estas cosas.

Puedes probar Gatsby V4 ahora. Salió ayer. Bastante bien sincronizado, diría yo. Envía BM install Gatsby, y obtendrás Gatsby V4. Y funciona en Gatsby Cloud hoy. También funciona en otras plataformas en la nube. Sabes a qué me refiero con eso. Pero sí, y para ser justos, Gatsby sigue siendo de código abierto. Puedes construir tus activos, implementar ese código realmente en cualquier lugar que desees, siempre y cuando pongas algo de trabajo. Y eso fue todo. Esa fue mi charla. Mi nombre es Sid. Ese es mi nombre de usuario en Twitter. Si tienes preguntas o si quieres hablar, no dudes en enviarme un mensaje directo o mencionarme en un tweet.

QnA

Q&A sobre DSG de Gatsby y Reconstrucción de Páginas

Short description:

Gracias. Gracias. Gracias. Gracias. Gracias. Gracias. Sid, eres mi persona favorita por dos razones. ¿Puedes adaptar el DSG de Gatsby para renderizar páginas en el Edge? Sí, puedes. Si ejecutas una compilación de Gatsby localmente, puedes echar un vistazo a tu directorio .cache. Todos los activos que necesitas para el DSG están ahí. Glenn ha preguntado si los datos no cambian para una ruta en particular, ¿sabe el DSG que no debe reconstruir esa página? La respuesta es sí, puede hacerlo.

Gracias. Gracias. Gracias. Gracias. Gracias. Gracias. Sid, eres mi persona favorita por dos razones. Primero, porque eres increíble. Pero también, estás a tiempo, así que volvemos al horario. Por favor, toma asiento. Bienvenido a la caja caliente.

Así que tenemos muchas preguntas para ti. Y no hay mucha votación en estas. Todas están al mismo nivel en este momento. ¿Las agregaste todas, Jan? No lo hice. OK, aquí vamos. Así que voy a empezar desde arriba.

¿Puedes adaptar el DSG de Gatsby para renderizar páginas en el Edge, por ejemplo, para calcular en el Edge o con Cloudflare Workers? Sí, puedes. Si ejecutas una compilación de Gatsby localmente, puedes echar un vistazo a tu directorio .cache. Todos los activos que necesitas para el DSG están ahí. La documentación es escasa. Acaba de salir hace un par de días. Eso mejorará. Pero puedes hacerlo si miras el directorio .cache. Hay un directorio de funciones dentro de él. Elige algunos de esos archivos. Ponlos en la nube correcta y simplemente funcionará, con suerte.

Genial. Glenn ha hecho la pregunta, si los datos no cambian para una ruta en particular, ¿sabe el DSG que no debe reconstruir esa página, que puede reutilizar la versión del despliegue anterior? Excelente pregunta. La respuesta es sí, puede hacerlo.

Caché y Complejidad en Gatsby

Short description:

Las páginas en Gatsby Cloud se almacenan en caché según su contenido, lo que permite una caché eficiente. Gatsby utiliza internamente LMDB para manejar la complejidad de la serialización y deserialización entre los workers. Esto permite la paralelización y mejora la experiencia del desarrollador. Sin embargo, el uso de DSG para contenido personalizado específico de usuarios autenticados aún no es compatible, pero Gatsby planea introducir un middleware previo a la ruta con este propósito.

Lo bueno de cómo hemos construido las cosas en Gatsby cloud es que las páginas se almacenan en caché según su contenido. Incluso si provienen de una compilación diferente, aún guardamos esos activos estáticos de forma independiente del ID de compilación. Si compilas la misma página una y otra vez, nada ha cambiado. Vamos a usar la misma y simplemente la omitiremos automáticamente.

Tengo una pregunta personal de seguimiento sobre eso. ¿Cuánta complejidad estás introduciendo internamente en Gatsby para que todo esto funcione? Porque el diagrama que dibujas es muy bonito, y es claro, y básicamente es como una caché directa. Pero ¿cuánta magia necesita Gatsby para hacer que esto funcione? Bastante. No voy a mentir, bastante. Y eso es lo que es LMDB. LMDB nos permite serializar y deserializar ese estado entre los workers. Y también nos permite, en el pasado, Gatsby ha tenido mucho de su estado en memoria. Y esa ha sido una de las principales razones por las que no hemos podido movernos a los workers y paralelizar las cosas. Con LMDB, ahora podemos hacerlo. Y sí, hay complejidad. Sí, las cosas bajo el capó son más complicadas. Pero todo es por la experiencia del desarrollador. Y la experiencia del desarrollador es mejor. Así que supongo que vale la pena.

Exactamente. Como desarrollador, aprecio cualquier mejora en mi experiencia. Así que, ya sabes. Y esperamos que eso también se traduzca en la experiencia del usuario al final del proceso.

La siguiente pregunta es de Adam Young. ¿Podemos usar DSG para código que podríamos tener como una ruta del cliente? Algo como contenido personalizado específico para un usuario autenticado, que se almacena en caché específicamente para ellos. Excelente pregunta. Aún no. Porque para poder hacer eso, aún tendrías que. Todavía tendríamos que ejecutar parte de tu código para poder verificar la autenticación por usuario, etc. Tenemos la intención de desarrollar lo que llamamos middleware previo a la ruta durante el tiempo de SSR y DSG. Así que esto sucederá.

Build System Latency and Containerization

Short description:

Pero hasta el día de hoy, no. No puedes. Si quieres ir a SSR en casos de páginas como esa. O ir al lado del cliente. ¿Qué hay del tiempo que tarda el sistema de compilación en arrancar? ¿No agrega mucha latencia? En realidad, es ridículamente rápido. Incluso antes de que termine tu compilación, toda tu compilación. Enviamos eso a través de sockets. Precalentamos los contenedores, que se ejecutarían para SSR. Idealmente, no debería haber ninguna latencia introducida por esta infraestructura. La latencia que verás probablemente se deba a la complejidad del código del usuario y la cantidad de datos que tienes. Pero sí, pensamos en esto.

Pero hasta el día de hoy, no. No puedes. Si quieres ir a SSR en casos de páginas como esa. O ir al lado del cliente.

Genial. ¿Qué hay del tiempo que tarda el sistema de compilación en arrancar? ¿No agrega mucha latencia? Supongo. Vale, respondiste la pregunta.

Esa es una gran pregunta. Realmente trabajamos duro en eso. Pruébalo. En realidad, es ridículamente rápido. Entonces, lo que hacemos es, incluso antes de que termine tu compilación, toda tu compilación. Ahora, la compilación de Gatsby implica varias cosas. Generamos tus paquetes de JavaScript. Generamos CSS. Y luego escribimos archivos HTML por página. Ahora, tus archivos HTML son una función de ese paquete. Pero tu SSR y DSG no tienen que esperar a todos esos. Tan pronto como tengamos tu paquete listo, incluso antes de que termine toda la compilación, los enviamos a través de sockets. Precalentamos los contenedores, que se ejecutarían para SSR. Entonces, antes de que termine tu compilación, tus contenedores de SSR ya están en funcionamiento y listos. También requerimos tu código. Por lo tanto, está en la caché de requerimientos. Todo está precalentado. Idealmente, no debería haber ninguna latencia introducida por esta infraestructura. La latencia que verás probablemente se deba a la complejidad del código del usuario y la cantidad de data que tienes. Pero sí, pensamos en esto. Haré un seguimiento de eso. Siempre he tenido curiosidad. Construyes una plataforma como esta, y siempre te refieres a contenedores.

Optimización de imágenes y tiempos de compilación

Short description:

Entonces simplemente agrupas las instancias de nodo en contenedores y las alojas en algún lugar. Tenemos una imagen personalizada que ejecutamos, muy simplificada. ¿Es viable optimizar las imágenes solo para la primera solicitud o las imágenes deberían ser más críticas? Los tiempos de compilación ahora son una función de tu tráfico.

Entonces simplemente agrupas las instancias de nodo en contenedores y las alojas en algún lugar. Pero ¿tienes que hacer algo optimizado a nivel de plataforma o tiempo de ejecución? ¿Son solo cajas de nodo estándar? Tenemos. Tenemos una imagen personalizada que ejecutamos, muy simplificada que no tiene muchas cosas que normalmente se asocian con la ejecución de cualquier servidor de nodo. Pero en realidad, es solo un contenedor. Es solo node.js.

De acuerdo, genial. Creo que tenemos tiempo para un par de preguntas más, y hay muchas. ¿Es viable optimizar las imágenes solo para la primera solicitud, o las imágenes deberían ser más críticas? Interesante. Aquí está la cosa. Realmente puedes hacer ambas cosas. Creo que depende de tu caso de uso. Si sientes que quieres que tus imágenes, si tus imágenes se comparten entre páginas, y si algunas de esas páginas se generan estáticamente, esas imágenes se generarán críticamente en el tiempo de compilación de todos modos. En caso de que tus imágenes no sean críticas y solo estén en páginas diferidas, se generarán en la primera solicitud. En la mayoría de los casos, no me preocuparía tanto, porque recuerda, solo estamos hablando de la primera solicitud. Cada solicitud después de eso será estática. A menudo, al acceder a una página que enlaza con otra página como esta se activará esa primera solicitud de todos modos, debido a la precarga. Por lo general, no me preocuparía tanto, pero pruébalo.

Genial. Tenemos un par de preguntas más. Creo que Slido debería protegernos de cosas como esto, un comentario en lugar de una pregunta. Pero se coló un comentario y creo que es genial, lo leeré en voz alta. Los tiempos de compilación ahora son una función de tu tráfico. Esto me dejó asombrado. Y esto no es una pregunta, pero me gustaría escuchar un poco más al respecto. Sí, eso. Sí. Y escribí esto esta mañana a las 6 AM. Pero en realidad, si piensas en todos tus sitios generados estáticamente antes de esto, antes de que esto fuera posible, tu tiempo de compilación siempre era una función del número total de páginas que tenías. Si tienes 10,000 páginas, tu tiempo de compilación será una función de cuántas páginas tienes. Pero si marcaras todas tus páginas como diferidas, y probablemente no lo harías para todas tus páginas.

El Futuro de Gatsby y Enfoque en Integraciones

Short description:

Ahora tus tiempos de compilación son simplemente una función de tu tráfico en tiempo de ejecución. Gatsby v4 ha hecho que Gatsby sea viable para varios casos de uso, incluido SSR. El próximo enfoque está en las integraciones y en mejorar la experiencia del desarrollador (DX).

Pero si lo hicieras, tus tiempos de compilación ahora son simplemente una función de tu tráfico en tiempo de ejecución. Tus tiempos de compilación serían muy rápidos. Pero entonces, es casi como dividir tu tiempo de compilación en tu tiempo de compilación inicial y luego tu tiempo de compilación diferido que ocurriría cuando el tráfico llega a tu sitio. Y por eso creo que es una función de tu tráfico.

Excelente. Oh, excelente. Y creo que una pregunta final, esta es buena para terminar, como una respuesta de un minuto. ¿Qué viene a continuación para Gatsby? ¿Cuál es la cosa emocionante a la que estás esperando? Mucho. Creo que con Gatsby v4, en lo que trabajamos y en lo que invertimos mucho fue en poder hacer que Gatsby sea viable para casos de uso para los que antes no lo era. Gatsby nunca había tenido SSR antes. Y eso es algo en lo que hemos estado pensando durante años, y finalmente lo construimos. Creo que ahora Gatsby realmente se puede usar para cualquier tipo de sitio, ya sea que estés haciendo SSR, DSG, SSG, y así sucesivamente. En cuanto a lo que viene a continuación, creo que el DX es lo siguiente para nosotros. Hoy en día, para usar DSG, aún necesitas pasar esa opción. Defer True para Create Page. No admite la API de enrutamiento del sistema de archivos, por ejemplo. Muchos complementos, muchos complementos de la community y CMS necesitan adoptar estas cosas y funcionar de manera nativa. Entonces, lo siguiente para nosotros es enfocarnos en estas integraciones y asegurarnos de que todo funcione realmente como nos gustaría. Y el DX general, eso es lo siguiente para este trimestre.

Increíble. Muchas gracias, Sid. Aplausos para Sid, por favor. Estoy. Gracias. Música

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn