Nuevos modos de renderizado en Gatsby v4

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.

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.

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.

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.

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.

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.

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.

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.

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.

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á.

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.

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.

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