Next.js para Desarrolladores de React.js

Hola. Muchas gracias a todos por hacer el tiempo para estar aquí y por elegir esta masterclass en lugar de quizás algunas otras. Así que espero que estén emocionados con el tema. Intentaremos repasar muchas cosas útiles sin intentar que sea demasiado aburrido o demasiado monótono. Así que voy a dar lo mejor de mí para que sea algo agradable, agradable de ver y escuchar tanto como podamos mientras nos adentramos en algunos temas advanced también.

Así que daré lo mejor de mí. Mi equipo también se adelantó. Tengo que darles un gran reconocimiento por preparar incluso las diapositivas, la presentación, todo. Vamos a tener algunas demostraciones en vivo. Vamos a tener muchas cosas. Así que estoy realmente agradecido por tu presencia aquí. Y mientras la gente se une, podemos empezar lentamente.

Así que supongo que el objetivo de todos ustedes aquí es quizás ver cómo podemos aprovechar mejor no solo lo que Next.js ofrece, sino lo que React ofrece, y luego lo que Next.js simplifica y crea un envoltorio de, ¿verdad?, para usar mejor el React, pero por lo tanto, el código de Next.js en producción también. Ese va a ser el tema de hoy.

Así que, sumergiéndonos directamente, los React Server Components, probablemente la mayor charla de 2023 después de la IA. Si has estado en Twitter o X, probablemente has visto a la gente hablar de ello todos los días. A algunas personas les encantan. A algunas personas les disgustan. Y la mayoría de la gente simplemente está confundida. Tenemos preguntas como, ¿qué es RSC, como en React Server Components? ¿No es lo mismo que SSR? ¿Por qué React está volviendo a PHP? ¿Cómo encaja todo esto con Next.js? ¿Y puedo usarlo sin Next.js? Ahora mismo, es un poco un lío. Haré lo posible por desenredar ese lío para ti.

Así que antes de eso, una pequeña auto-presentación. Soy Adrian, el fundador de JavaScript Mastery. Hemos publicado muchos videos educativos diferentes en YouTube sobre temas como JavaScript, React, y durante el último año, mucho de Next.js. Y también, he sido reconocido como una estrella de GitHub, una especie de posición ofrecida por GitHub para personas que realmente intentan devolver a la audiencia y a las personas que se centran en la educación. Así que doy lo mejor de mí para crear más de cientos de videos basados en proyectos donde enseñamos a los desarrolladores cómo construir aplicaciones reales de principio a fin. Y he estado trabajando mucho con el nuevo Next.js, desde que salió, casi usándolo en todos nuestros videos de YouTube. Lo hemos tenido mucho, construyendo aplicaciones reales, enseñándolo en nuestro curso de Next.js también. Y es completamente nuevo Next.js. Desde el 13 al 14 e incluso más allá, hay muchas cosas nuevas sucediendo con Next.js. También creamos el curso de Next.js aquí mismo al que casi 3,000 personas se han unido. Y en esta masterclass, explicaré lo que he aprendido sobre los componentes del servidor React y cómo se conectan con Next.js de una manera fácil de entender.

Así que comencemos con un calentamiento en la era previa a los componentes del servidor React. Las cosas eran simples y directas. React estaba garantizado para funcionar en el navegador del cliente, nada más. Simplemente envía grandes fragmentos de paquetes de JavaScript con un mínimo archivo HTML individual y dile al navegador del cliente que maneje todo lo demás. El proceso, tal como lo conocemos, el cliente hace una solicitud al servidor, que parece algo así. El servidor responde a HTML y al paquete de JavaScript. El cliente renderiza HTML y descarga todo lo mencionado en el paquete de JavaScript. El cliente ejecuta ese JavaScript y luego pinta el contenido en la pantalla. Esta fue una sorprendentemente increíble invención web. Todavía lo es, pero como todas las cosas, todavía tiene inconvenientes.

Sí, incluso React tiene inconvenientes, los más importantes son el performance. Cuanto más JavaScript envíes, más tiempo tardará tu sitio en cargar inicialmente. Y en el mundo de hoy, la primera impresión es crucial para mantener a tus usuarios comprometidos en nuestros sitios web. También no debemos olvidar los dispositivos de gama baja, donde presumimos que todos los usuarios tienen dispositivos, redes y navegadores de primera línea y confiando en que su navegador podría manejar eso. Sin embargo, no todos poseen los dispositivos más recientes, y no podemos pasar por alto el hecho de que con el tiempo, estamos incorporando características cada vez más advanced en los sitios web. Si has experimentado con Next.js durante el desarrollo, podrías haber observado que no funciona de manera óptima en MacBooks con chips Intel. Son máquinas potentes, pero la nueva tecnología es exigente. A medida que evoluciona la nueva tecnología, también lo hacen los desafíos para los usuarios en configuraciones menos advanced que fueron poderosas algún día. Y por supuesto, no podemos hablar de los inconvenientes de React sin mencionar el SEO. Sí, sí, has oído eso varias veces, React no se lleva bien con el SEO. Habría sido increíble si los rastreadores web entendieran JavaScript, pero desafortunadamente, ese no es el caso. Y con el mínimo HTML de React, nuestro sitio web no llega a entender correctamente el SEO. Entonces, para abordar este problema, Next.js implementó SSR. SSR, renderizado en el lado del servidor, este método implica renderizar React en un servidor, generando HTML, y luego enviándolo al cliente. Luego, el cliente es responsable de renderizar esos nodos y elementos HTML e incorporar el JavaScript necesario para habilitar contenido interactivo. Es importante entender que hasta ahora, SSR solo puede renderizar los componentes React que son aptos para renderizar en el servidor. Los componentes que requieren interactividad, como aquellos con oyentes de eventos o dependencias en las APIs web, no son ejecutados por SSR. Puedes pensar en SSR como un método para crear un plano de nuestro sitio web. Genera y muestra cómo aparecerá inicialmente tu página web.

Por ejemplo, considera el siguiente escenario en la página. Tenemos un archivo home.js, o tenemos un contador típico que has visto cientos de veces. Creo que también se presentó en los documentos de React.js como uno de los primeros ejemplos de uso de estados cuando salieron los hooks. ¿Cuántos de ustedes estuvieron aquí para React 15, React 16, cuando pasamos de componentes basados en clases a solo hooks? No dudes en decírmelo en el chat. No muchas de las nuevas generaciones de desarrolladores que están programando ahora han pasado por ese tiempo. ¿Has estado aquí para esa transición? Sí, es una locura pensar que algunos de nosotros hemos empezado con componentes de clase y algunos de nosotros, o algunos de ustedes tal vez, nunca han usado componentes basados en clases, lo cual es bastante interesante para pensar. Tenemos este ejemplo aquí, y el resultado de la salida SSR sería así, donde simplemente tenemos bienvenido a mi nueva aplicación Next.js. Donde tenemos el botón y el contador. Eso es el SSR. Se produce una página HTML aquí, que comprende una lista de elementos y nodos, que representan los componentes de esa página. ¿Pero qué pasa con la interactividad? Todos los estados y oyentes de eventos se envían al cliente y como paquetes de JavaScript, que el navegador del cliente carga e inicia la construcción del DOM virtual. El cliente compara el DOM estático que recibimos inicialmente con el DOM virtual que creará utilizando el código JavaScript proporcionado, y luego determina si coinciden correctamente. Si no, lanzará un error, diciendo que muchos desarrolladores de Next.js están frustrados, que va a parecer algo así. Un error de hidratación. Todo este proceso de reconciliación del DOM virtual, que el cliente cree que representa la página, con el DOM estático real que el servidor entregó, se llama hidratación. El favorito de todos, Dan Abramov, lo puso de esta manera, a través de sus modelos mentales. Antes, así sin el SSR, tenemos el árbol de React, donde renderizamos componentes a HTML. Tenemos el main.js y luego agrupamos el código para interacciones como esta. Y luego después del SSR, va a parecer algo así. Donde tenemos el árbol del servidor, con el sistema de archivos, bases de datos, servicios internos, y muchas otras cosas. Y pasamos props al árbol de React, así. Básicamente, un DOM virtual, o árbol, creado por el cliente, que parece esto. Servidor, cliente, y ahora tenemos todo sucediendo en el cliente también. Sí, puedo ver en los mensajes también que Davie envió la superposición de hidratación de builder.io React. Así que, eso es algo bastante interesante para tener en cuenta. También podemos compartirlo definitivamente en el Discord, así que siempre que tengamos algo, tenemos un foro y podemos mantener nuestra discusión allí. Es bastante útil saber que podemos tener mensajes de error mejores y mejorados cuando se trata de hidratación. Gracias por compartir eso. Pero eso es suficiente sobre SSR por ahora. Lo entiendes. Dado que tenemos este sólido enfoque de SSR, ¿por qué deberíamos molestarnos con los componentes del servidor React? Bueno, la hidratación convencional que discutimos anteriormente, antes de los componentes del servidor React y Next 13, implicaba una hidratación de página completa. Esto significaba que cuando se cargaba la página, todo el componente 3 de React, incluyendo todos los componentes, ya fueran inicialmente visibles o interactuados por el usuario, se hidrataban en el lado del cliente. ¿Qué significa esto para el performance? Aunque puedes ver algo en la página, no será interactivo hasta que el cliente cargue todo lo relacionado con esa página, específicamente el paquete de JavaScript necesario para hidratar el árbol estático. Claro, logramos una carga inicial más rápida en esta etapa, pero luego hay un retraso con el que podemos interactuar, y porque estamos esperando que el JavaScript se hidrate, hay una brecha. Para bases de código más extensas, puede llevar a cargas de página iniciales más grandes y procesamiento de JavaScript, incluso para componentes que pueden no ser inicialmente requeridos. Así es donde entran los componentes del servidor React. El componente del servidor React es un nuevo tipo de componente. Está asegurado para funcionar exclusivamente en el servidor. Nunca se hidratan en el lado del cliente. Así que como resultado, no se envía JavaScript extra, lo que resulta en un tamaño de paquete de JavaScript más pequeño, una carga de página más rápida, hidratación selectiva, y una experiencia mejorada tanto para la interfaz de usuario como para la experiencia del desarrollador. Pero antes de eso, permíteme explicar cómo funcionan los componentes del servidor React y cómo podemos usarlos. Es importante notar que los componentes del servidor React son exclusivamente una característica de React. Ha habido mucho debate en internet ahora.

Oye, ¿por qué necesitamos Next.js si esta es una característica de React? No estoy seguro de dónde te sitúas con ese punto, pero es bastante simple, ¿verdad? Los Componentes del Servidor React son una característica exclusiva de React. Pero no está vinculada a ningún marco específico. Aunque, actualmente, la forma recomendada de utilizar los Componentes del Servidor React es a través de Next.js. Aquí puedes verlo mencionado directamente en los documentos oficiales de React.js. Técnicamente es posible usarlo de forma independiente. Sin embargo, no se recomienda su uso sin un marco para la producción y la configuración puede ser un problema con React puro.

Puedes ver la demostración aquí mismo. Antes de ver la demostración, quiero hacerte un par de preguntas aquí. ¿Cuál es tu postura al respecto? ¿Usar los Componentes del Servidor React independientemente de un marco? ¿Has intentado hacer eso antes? ¿Has intentado usarlo para bases de código más grandes? Sé que es difícil romper el hielo, pero siempre me gusta tener alguna interacción también. No dudes en usar el chat también. Podría ser un poco más fácil. Veo a un par de personas simplemente diciendo que no han usado los Componentes del Servidor React todavía. Son bastante nuevos. React realmente no proporcionó una forma sencilla para que los usemos. Pero si hago una pregunta, ¿has usado los Componentes del Servidor React con Next? La respuesta cambia drásticamente, supongo. Dame solo un rápido sí o no si los has usado con Next. Puedo ver muchos síes ahí.

Esta es la demostración oficial de los Componentes del Servidor React aquí usando solo React. Lo que puedes ver aquí es que definitivamente podemos usarlo. Tenemos el servidor, pero necesita un servidor. Aquí podemos ver que dentro del servidor, apiserver.js, si nos desplazamos hacia abajo hasta el app.get aquí y voy a acercarlo un poco. Tenemos este app.get forward slash, y puedes ver que estamos enviando HTML de vuelta aquí mismo. Así que técnicamente estos son los Componentes del Servidor React en acción. Los está obteniendo del servidor y los está devolviendo. Ahora estamos sumergiéndonos en el código base oficial. Además, el React o render React tree aquí no solo está construyendo el árbol de React como discutimos. Está manejando varias tareas, incluyendo el envío de respuestas y la creación de rutas para otras páginas también. Así que si salimos de esta carpeta e inspeccionamos el archivo package.json aquí mismo, notarás que estamos utilizando React DOM server webpack aquí mismo, este paquete, versión 18.3.0 next aquí mismo, y también estamos usando el paquete server only 0.0.1. Eso es bueno. Este es el proceso al usar los Componentes del Servidor React sin ningún marco en este momento. Nos requiere configurar nuestro propio servidor, scripting y manejar la renderización de forma independiente. Y aquí es donde los marcos como Next.js se vuelven valiosos. Usar un Componente del Servidor React en Next.js es sin esfuerzo. Y la última versión de Next.js, el enrutador de la aplicación, hace que el RSC sea el componente predeterminado, como todos ustedes podrían saber, lo cual es bastante emocionante. Así que ahora quiero sumergirme en una demostración rápida. Sí. Vamos a tener demostraciones también. No he preparado ningún video para eso. Va a ser solo una rápida y buena demostración antigua de Visual Studio Code, que, como podrías saber, a menudo sale mal. Así que ten paciencia conmigo. No puedes tener una demostración sin que algo salga mal, ¿verdad? Lo que vamos a hacer aquí es asegurarnos de que estamos en mi escritorio aquí mismo o más bien simplemente crear un nuevo archivo aquí mismo para Git Nation. Todos estos archivos se proporcionarán en el servidor de Discord más tarde, y podremos tener más conversaciones sobre eso también. Así que vamos a empezar desde los comienzos más básicos creando una nueva terminal aquí mismo y creando una nueva aplicación Next.js ejecutando npx create-next-app. Vamos a elegir un nombre. En este caso, podemos hacer algo como hello-rsc y simplemente voy a presionar Enter para todo. Vamos a obtener la configuración predeterminada, y esto va a crear una nueva estructura básica de archivos Next.js. Ahora lo tenemos. Tenemos nuestra propia aplicación y el componente, por supuesto, está dentro de la página.tsx. Este es nuestro primer Componente del Servidor React. ¿Cómo lo sabemos? ¿Alguien puede decirme? ¿Cómo sabemos que este es un componente del servidor? Sí, eso es correcto. Radik, espero haberlo entendido bien. Simon también. No hay una directiva use client en la parte superior. Eso es todo. Es tan simple como eso. No tenemos que hacer nada más. Next.js lo hace por defecto si no nos salimos de nuestro camino para proporcionar específicamente la directiva use client. Genial. Entonces, ahora vamos a hacer una rápida demostración aquí mismo. Si añadimos un registro de consola aquí mismo, vamos a hacerlo quizás aquí mismo en la parte superior, console.log, y si hacemos algo como hello-Rome-rsc aquí mismo. Déjame intentar deletrearlo correctamente. Ahí vamos. Hola desde RSC. Y ahora si ejecutamos nuestra aplicación ejecutando NPMI, que primero tenemos que navegar aquí mismo. Así que moviéndonos a hello-rsc, ejecutamos NPMI, y luego ejecutamos npm run dev. Si lo ejecutamos y si visitamos nuestra aplicación en localhost 3000, ahí vamos, creo que podemos ver hola desde RSC aquí mismo en nuestra terminal. Y si abrimos el elemento de inspección aquí mismo, podrás notar que no hay absolutamente nada sucediendo en nuestra consola del navegador. ¿Verdad? Bastante simple, pero lo vemos aquí mismo en nuestra terminal. Así que si inspeccionamos la vista o vemos el código fuente de esta aplicación, podemos hacerlo aquí mismo y vamos a la parte HTML también en los elementos. Ahí vamos. Ten paciencia conmigo. Genial. Así que podemos ver nuestro CSS, que no nos preocupa en este momento. Pero podemos ver la etiqueta de script aquí mismo. La última etiqueta de script, creo que es.

Si abres la carpeta de la aplicación, encontrarás nuestros archivos HTML generados. Si buscamos la aplicación, aquí, encontrarás todos los archivos HTML generados. Formateando este índice HTML te mostrará el código exacto que teníamos en nuestro page.tsx, que era un componente de servidor puro.

Justo debajo, hay algo llamado index.rsc. Puedes verlo aquí. Puede que no parezca muy legible, pero vamos a pedirle a ChatGPT que lo simplifique y lo haga comprensible para nosotros. Si hago esto, puedo abrir una nueva ventana. Permíteme hacerlo justo aquí. Vaya, creo que lo perdí. Permíteme hacerlo en mi otro monitor y lo traeré. Este es otro, supongo, punto de discusión en este momento. ¿Con qué frecuencia utilizas ChatGPT en tus flujos de trabajo diarios mientras intento abrirlo y ponerlo en marcha, especialmente con el desarrollo? ¿Has probado a usar GitHub Copilot? ¿Sigues utilizando ChatGPT o nunca lo utilizas? Vale, puedo ver, sí, puedo ver que algunas personas han dicho casi nunca. Y luego tengo la mayoría de los días, Copilot y ChatGPT también. Eso está bien, sí. Así que si hacemos esto aquí, y si intento simplemente pedirle que lo explique para nosotros, o al menos decir que lo haga legible, veamos qué va a pasar. Vale, estructura detallada, elementos HTML y CSS. Vale, para hacerlo legible, desglosarlo en componentes. Y ahora va a hacer lo suyo. Estoy usando GPT-4, es un poco... Sí, es un poco más lento, pero va a repasar la cosa real, debería simplificar. Creo que al final de su discusión explicará un poco lo que es. Pero ya tienes la idea. Esencialmente aquí, deberíamos tener un árbol que represente el contenido de la página, mostrando todos los elementos de arriba a abajo. ¿Puede simplificarlo? Puede ser un acierto o un error, como ya sabrás, ¿verdad? Así que inmediatamente sabe que es una página de Next.js, y parece que está explicándolo. Pero yo quería que me proporcionara un árbol, pero eso es difícil de ver. Esencialmente lo que deberíamos obtener si intentamos diseccionar esto, te darás cuenta de un árbol de diferentes elementos, ¿verdad? Así que intenta recordar ese modelo mental creado por Dan Abramov. Los componentes del servidor React no producen directamente archivos HTML. En cambio, generan una estructura de DOM virtual, como vemos aquí mismo. Y así es como React, la biblioteca sabe qué hacer. Así que ahora lo que podemos hacer es, supongo, simplemente preguntarnos, ¿cuándo deberíamos usar los componentes del servidor React? Permíteme ver. Dame un segundo. Si volvemos a nuestra demostración aquí mismo, ahí vamos. Tenemos esta gran cosa aquí mismo. Y actualmente, no estamos utilizando ningún componente del cliente. Supongo que la pregunta es, ¿por qué usaríamos cualquier componente del cliente en absoluto, si podemos usar componentes del servidor? Bueno, vamos a intentar crear un pequeño componente del cliente dentro de la carpeta de la aplicación, para intentar comparar las diferencias entre cómo se están renderizando en segundo plano.

Así que si vamos aquí a la aplicación, vamos a crear un nuevo componente, supongo que podemos llamarlo client.tsx. Y podemos ejecutar rafce para ponerlo en marcha muy rápidamente. Y tenemos nuestro componente del cliente, dentro del cual podemos usar la directiva use client. Ahí vamos. Esto es bastante simple. Lo que también me gustaría hacer es crear otro subcomponente, const sub client component también, que va a parecer esto. Este subcomponente del cliente puede simplemente devolver un div que va a decir subcomponente del cliente. Ahora queremos modificar el archivo page.tsx para escribir algo básico, que nos va a permitir obtener el RSC mínimo. Así que si volvemos a la página, voy a reemplazar este main entero, y donde yo quiero llegar es simplemente devolver un main que va a decir algo como bienvenido a git nation. Ahí vamos. Y podemos añadir una etiqueta P justo debajo. Que va a decir algo como esto es un componente del servidor, ¿vale? Lo estamos haciendo paso a paso. Ahora veamos qué obtenemos sin importar este componente del cliente dentro de nuestra página principal page.tsx. Permíteme ver. Si intentamos ejecutar npm run build una vez más. Vale, como puedes ver, lo está construyendo. Está tardando un poco más de tiempo ahora. Y dentro de nuestro .next, tenemos servidor, tenemos aplicación, tenemos la page.jsx una vez más, tenemos estático también. Hay muchas cosas sucediendo. Y luego tenemos las páginas, 404 y 500 generadas automáticamente. Permíteme ver lo que estaba buscando específicamente aquí. Si vamos Oh, sí, ahí vamos. Puedo ver la respuesta proporcionada por el chat GPT. Y esto es exactamente lo que estábamos buscando. Así que si lo traigo aquí mismo, esto es más o menos lo que estábamos buscando, ¿verdad? Así que tenemos la versión completa versión simplificada del código, o tenemos el bloque de código uno, bloque de código dos, bloque de código tres, bloque de código cuatro, que es enorme, y contiene todos los hijos aquí mismo con nombres de clase y todo. Esto es lo que es un componente del servidor react. Es una reestructuración sencilla para mejorar la legibilidad en este caso. Así es como los componentes del servidor React trabajan detrás de las escenas para generar y enviar esos datos a nuestro DOM virtual dinámico. Y también allí, nunca está el código para el componente del cliente, lo único que tiene es el código para los componentes del servidor.

Ahora bien, esta fue una demostración rápida, pero quiero profundizar en responder a la pregunta de cuándo deberíamos usar los componentes del servidor React en primer lugar? Ahí vamos. Así que esta documentación de JS lo explica muy claramente. Realmente es una de las mejores documentaciones del mundo, donde nos muestra exactamente cuándo, y nos da soluciones realmente sencillas aquí mismo. Aquí podemos ver que cuando estoy desarrollando mi aplicación, me pregunto, ¿requiere este componente interactividad? Si la respuesta es sí, ¿verdad? Vamos a esbozar un poco esto. Si la respuesta es sí, es un componente del cliente. Si la respuesta es no, es un componente del servidor. Y esto sigue el principio de separación de preocupaciones, guiándonos para crear componentes del servidor y componentes del cliente basados en sus roles específicos.

Entonces, veamos por qué deberíamos usar los componentes del servidor React. En primer lugar, van a resultar en una reducción del código del lado del cliente, donde el uso adecuado de RSC nos permite mantener la mayoría del código y los cambios necesarios en el lado del servidor minimizando o eliminando el tamaño del paquete para el componente RSC que se envía al lado del servidor. Menos código del lado del cliente significa tiempos de carga más rápidos y muchos más beneficios. Mejora de la seguridad, ¿verdad? Porque la obtención de datos en el lado del servidor es más segura que en el lado del cliente, donde las variables de entorno están fácilmente expuestas. Y lo sabemos, ¿verdad? Pero a veces puedes caer en la trampa de hacerlo accidentalmente allí. De esta manera siempre está en el servidor. Mejora de la latencia también, donde la ejecución del lado del servidor de las operaciones de fetch o de la base de datos resulta en una mejor latencia, ya que los servidores y los centros de datos suelen estar geográficamente cerca, lo que lleva a respuestas más rápidas y un acceso más rápido a los datos. Y finalmente, tenemos beneficios de UX y DX. La mayoría de los componentes del servidor simplemente tienen una mejor experiencia que el SSR tradicional, un tema que abordaremos en breve. En el lado de la experiencia del desarrollador, el uso de RSC, especialmente para la obtención de datos, es sencillo. En versiones anteriores de Next.js, la obtención de datos en el lado del servidor estaba limitada al nivel de la página. No era posible hacer la obtención de datos del lado del servidor a nivel de componente. Ahora sí se puede. Además, el proceso era un poco menos intuitivo, en contraste con la simplicidad de usar los componentes del servidor React. Como puedes ver, este es un gran bloque de código donde tenemos algo simple, aparentemente, ¿verdad? Pero luego tenemos que hacer todo esto de get server side props también. Supongo que la mayoría de vosotros estáis al tanto de eso. Donde ahora, tenemos algo que es mucho más simple. Tenemos exactamente lo que queremos, un component

Los React server components son componentes que se ejecutan específicamente en el lado del servidor. Producen una carga útil de RSC, que es esencialmente una representación del lado del servidor de todo el DOM virtual, el modelo de objeto de documento para una aplicación dada. Esta carga útil describe dónde se debe colocar cada componente en la estructura del DOM y frameworks como Next.js entran en juego en este punto.

Toman la carga útil de RSC y el archivo HTML generado desde el lado del servidor, DOM virtual y los envían como un paquete al cliente, que es el navegador del usuario. Ahora en el lado del cliente, el navegador lee el DOM virtual del lado del servidor y comienza a construir su propia versión. Añade los componentes necesarios del lado del cliente al árbol según se especifica. Y este proceso se llama hidratación.

Es importante destacar que los React server components y la renderización del lado del servidor, SSR, son conceptos diferentes. Mientras que puedes usar RSC por sí solo, hacerlo requiere la gestión manual de varios aspectos, mientras que los frameworks integrados como Next.js simplifican este proceso al manejar eficientemente tanto RSC como SSR para ti. El mecanismo SSR renderiza tanto los componentes del lado del servidor utilizando la carga útil JSON o la carga útil de RSC generada por RSC y los componentes del lado del cliente, transformándolos finalmente en el código HTML que representa el plano de toda la aplicación.

Deberíamos considerar el uso de RSC para la obtención de data, cualquier cosa relacionada con la security o información sensible y la ejecución de dependencias pesadas. Mientras que los componentes RSC, o lo siento, los componentes del lado del cliente RCC podemos usar para cualquier cosa que necesite interactividad. Y eso es más o menos todo. Estaba pasando a la siguiente diapositiva, esperando que aparecieran más cosas, pero no, ¿verdad? Sólo usamos RCC cuando necesitamos alguna interactividad del lado del cliente. Es tan simple como eso. Ahora, lo que todo esto significa, si usamos correctamente sus componentes correspondientes para lo que necesitamos. Significa que vamos a reducir el código del lado del cliente. También vamos a mejorar la security. Vamos a mejorar la latencia de la red. Vamos a obtener un SEO optimizado y tener una mejor user experience y developer experience, que es lo que más nos importa.

Genial. Ahora, cubriré el bit de edge versus node al final, ya que estamos profundamente en los mecanismos de SSR y RSC en este momento, que es la base para estos bits. Pero aprendemos que con la renderización del lado del cliente aquí, cargamos todo y ejecutamos todo para mostrar cualquier cosa que se parezca a esto. Todo está sucediendo en el lado del cliente. Así, nuestros usuarios tuvieron que mirar la pantalla blanca durante un buen tiempo. Con la renderización del lado del servidor por otro lado, ejecutamos algo en el servidor como esto, y luego mostramos algo en el sitio y luego cargamos todo para hidratar las partes que hacen la interacción. Mucho mejor, ¿verdad? Eso seguro mejora los tiempos de carga iniciales ya que estamos mostrando algo, una cosa no interactiva al principio, pero oye, ellos obtienen algo, ¿verdad? Así, esto nos ayuda a no perder a potenciales usuarios o clientes no tan pacientes, ¿verdad? Y eso nos ayuda a mantenerlos. Puedo ver algunos comentarios aquí, mejorar la security, ¿cómo? Bueno, normalmente siempre es mejor ejecutar código seguro en el servidor. Como en el lado del cliente, las cosas se exponen fácilmente, ¿verdad? No estoy diciendo que esto esté mejorando la security sobre el enfoque típico del lado del servidor. Sólo estoy diciendo que tal vez hace un poco más fácil para nosotros no cometer el error de exponer algunas variables en el lado del cliente. Siempre que estés haciendo algo de security, siempre que estés haciendo algunos pagos, típicamente bibliotecas y paquetes como Stripe ni siquiera te permiten hacer muchos sitios en el cliente.

Así que ahora, simplemente hace que sea un poco más conveniente llamarlo en el servidor, y el servidor siendo los componentes directamente, ¿verdad? Lo que lo hace súper fácil de hacer. Ahora, para abordar algunos de los problemas mencionados, React 18 introdujo dos conceptos significativos, streaming e hidratación selectiva. El streaming es como enviar partes de un rompecabezas desde el servidor a tu ordenador tan pronto como se crean, en lugar de esperar a que todo el rompecabezas esté terminado antes de enviarlo. De esa manera, el servidor entrega las piezas a medida que las hace. Mientras que en la renderización tradicional del lado del servidor, cuando un usuario hace una solicitud, el servidor comienza a crear la página HTML, y el cliente tiene que esperar a que se genere toda la página. Después de recibir la página, que es sólo el contenido inicial, el cliente luego descarga todo el JavaScript y comienza a hidratarlo. Sin embargo, con la renderización del lado del servidor mediante streaming, tan pronto como el usuario hace una solicitud, el servidor comienza a ejecutar los componentes. En el momento en que están listos, se envían al cliente uno por uno, y esto elimina el tiempo de espera para la generación completa de la página antes de que el contenido se envíe al cliente. Pero, ¿qué pasa si hay un problema de red? Bueno, piénsalo como una carretera con mucho tráfico. Red, ¿verdad? Y los camiones siendo los datos que no pueden moverse rápido. Con el streaming, si la carretera está llena, el servidor pausa el envío de piezas de datos duros hasta que haya espacio de nuevo. Esto evita que el servidor se sature, y tu ordenador puede seguir trabajando en el rompecabezas cuando haya espacio. Y el streaming permite a tu servidor manejar múltiples tareas simultáneamente, incluso cuando se enfrenta a desafíos, tu sitio web sigue siendo rápido y receptivo. Así que una vez más, esta es una característica introducida en React 18, y para usarla, tendrás que usar Render to Node stream para transmitir el contenido de tu aplicación. Como se mencionó antes, frameworks como Next.js afortunadamente tienen soporte incorporado para esto. Todo lo que necesitas hacer es comprender el concepto, tomar decisiones informadas y centrarte en la lógica del negocio. En esencia, la renderización del lado del servidor mediante streaming utiliza Render to Node stream en lugar de Render to string, utilizado en la renderización regular del lado del servidor, para transmitir o enviar trozos de datos según sea necesario, en lugar de enviar todo de una vez. ¿OK? Así que los problemas del servidor no van a hacer nada para detenerlo. Y también, una vez más, vemos que Next.js utiliza de manera realmente conveniente y inteligente las características que están incorporadas en React. Simplemente las utiliza, y las envuelve de una manera que las hace más fáciles para nosotros para usar. Pero aún así, no olvides, tenemos que comprender el concepto para poder tomar decisiones informadas.

Entonces, ¿qué es la hidratación selectiva en primer lugar? ¿Qué crees que sería el mecanismo de hidratación si usáramos la renderización del lado del servidor con streaming donde estamos enviando contenido a medida que están listos? ¿Esperar a que todo esté listo y luego empezar a hidratar? Eso no sería el mejor uso de SSR, ¿verdad? Con la hidratación tradicional, obtenemos todo el árbol, y luego React lo hidrata, de principio a fin, solo una vez. Bueno, ahora, imagina a un niño que tiene un montón de juguetes para jugar. Antes de que ese niño pueda empezar a jugar con cualquier juguete, necesita recoger todas las instrucciones para los juguetes. Por supuesto, no es realmente así, pero solo aguanta conmigo por un segundo. Ahora, si algunos manuales son realmente grandes, ¿verdad?, él tendrá que esperar hasta que los consiga antes de que pueda empezar a jugar con cualquier juguete. Bueno, incluso si hay juguetes más pequeños con manuales más pequeños, todavía tiene que esperar a que los grandes terminen, así que hasta que tenga todas las instrucciones, puede jugar con cualquier juguete. Esto sucede con la hidratación regular también. Pero, con React 18 y streaming SSR, React hidrata el árbol sin esperar a que los componentes más grandes estén listos. Eso es de lo que se trata la hidratación selectiva. Un proceso en el que React hidrata los componentes o fragmentos que ha recibido a través del streaming, en lugar de esperar a que todo esté terminado. Comienza a hidratar tan pronto como tiene algo que hidratar. Pero, ¿cómo sabrá React? Bueno, es simple. Envuelve lo que creas que tardará más tiempo en cargar con suspense. Esto le dice a React que no espere a que este componente termine y que continúe transmitiendo e hidratando el resto del contenido. Entonces, ¿se genera de nuevo el DOM virtual o el árbol en el servidor? ¿Cuál es el flujo de trabajo aquí? Bueno, el proceso es así. Tenemos que envolver los componentes que crees que tardarán más tiempo en renderizarse, como este. También podemos hacer algunos cálculos o operaciones extensas y simplemente envolver eso con suspense y renderizamos el fallback que está cargando. Se ve así. El cliente hace una solicitud al servidor, React comienza a renderizar el componente del servidor de React y a construir el DOM virtual en el servidor, y en el momento en que encuentra el código donde estamos usando el suspense, utilizará el código de fallback dentro de ese árbol y luego continuará construyendo el resto de la parte. Ahora, cuando el componente termina de hacer su trabajo, transmitirá nuevo HTML que contiene el código de fallback de suspense al cliente, junto con el envío del script para mostrar lo que ha sido reemplazado con el código de fallback que se ha renderizado en la UI. No es tan fácil de entender, pero el mecanismo subyacente es, por supuesto, difícil. Para demostrar el flujo de trabajo rápidamente, vamos a abrir la aplicación que tengo aquí. Por cierto, obtendrás el enlace completo del código de GitHub en la descripción, o en este caso, va a estar en ese foro de Discord que tenemos. Realmente me gustaría que continuáramos la conversación allí, porque estamos discutiendo muchos temas para los que realmente no puedes encontrar mucha información en línea, y creo que esa es la razón por la que estoy haciendo esto. Con temas nuevos, como este, tal vez tus empleadores te han enviado, o tal vez has venido por tu cuenta, lo cual es increíble, para aprender cómo usar lo último y lo mejor de lo que nos hace más eficientes. Hoy en día, no puedes encontrar eso tan fácilmente en línea. Lo sé, porque tuve que buscar en muchas páginas de GitHub. No hay documentación en absoluto. Tienes que encontrarla por tu cuenta. El hecho de que estés aquí ahora mismo, escuchando esto, es simplemente increíble. Solo quería decir eso. El enlace va a estar allí. Lo que estaba diciendo es, me gustaría que continuáramos esta conversación en Discord, porque todos podemos aprender unos de otros incluso después de que esta charla haya terminado. Genial. Vamos a repasar esta aplicación muy rápido. Vamos a crear una aplicación de muestra, un componente de muestra, envuelto dentro de suspense. Va a hacer llamadas fetch. Va a hacer muchas cosas. Vamos a sumergirnos en nuestro segundo ejemplo del día. Voy a cerrar esto, colapsar todos los archivos, y simplemente volver a navegar aquí. Vamos a crear nuestro segundo ejemplo del día ejecutando mpx create next app. Vamos a llamarlo. Hagamos algo como hello-stream, ya que estamos aprendiendo sobre streaming.

¿Disculpa, Adrian? Sí, lo siento. Adelante. Me siento tentado a seguirte mientras programas esto, pero no estoy seguro si esa era la intención. Sí, creo que sería difícil, pero diría que vamos a tener una grabación de esto. También vamos a tener un chat en Discord, y también voy a darte ejemplos completos de estos repositorios que estamos creando. Recomendaría tal vez verlo, tomar algunas notas, lo cual sería genial también, y luego podemos revisarlos más tarde, y puedes hacer preguntas si tienes alguna, mientras intentas replicar eso más tarde. ¿Está bien? Sí, gracias por aclarar eso. Genial, no te preocupes, Vanessa.

Vamos a ver también. Veamos, así que intentemos abrir este stream, y lo que podemos hacer es entrar aquí. Dame un segundo, solo intento asegurarme de que expliquemos esto lo mejor que podamos. Tenemos este HelloStream, y quiero pedir un segundo, tengo a mi colega aquí preparando también algunos archivos para mí aquí. Estoy tratando de averiguar qué exactamente deberíamos mostrar aquí. También queremos llegar a este árbol del que hablamos hace no mucho, así que déjame crear un archivo demo.js aquí mismo, y esencialmente estamos hablando de este árbol haciendo la carga. Queremos averiguar dónde tenemos este React suspense, pero por supuesto quiero averiguar una forma de llegar a eso.

En lugar de escribir todo el código aquí, déjame abrir, o más bien pegar una nueva carpeta aquí mismo, que se llamará HelloStream, pero más bien la nueva que contiene el código. Aquí queremos seguir y proceder con la demo. Como puedes ver, es una vez más una página simple donde solo importamos un componente llamado.sampleSuspense. Todavía estamos renderizando el componente en el lado del servidor aquí mismo, y tenemos el main aquí mismo donde acabamos de renderizar el main, h1, html, tenemos un componente de servidor, y luego estamos llamando al suspense aquí mismo con una devolución de un simple loading y luego poniendo el sample suspense aquí mismo, que está llamando a nuestra API de Pokey, por lo que está haciendo una llamada API todavía en el servidor. Nos está dando algunos data, y luego está mostrando esos data de una manera JSON stringified. Ejemplo bastante simple.

Ahora, lo que podemos hacer es que voy a navegar hasta HelloStream. Vamos a HelloStream copy, creo, si me va a dejar hacer eso. Déjame renombrarlo a HelloStream 1, ten paciencia conmigo aquí. Ahí vamos. Voy a navegar hasta HelloStream 1, y voy a ejecutar npm install, y luego lo voy a ejecutar. Y luego deberíamos poder ver aparecer una nueva carpeta aquí mismo, que va a ser un punto next. Ahí vamos. Y ahora si vamos a, creo que es aquí, ¿verdad? Servidor, y luego tenemos la carpeta de la aplicación aquí mismo. Déjame ver. Creo que tengo que ejecutar la construcción aquí mismo. Sí, así que déjame ejecutar el npm run build para que podamos verlo realmente en un ejemplo aquí. Sí, ahí vamos. Y sí, también puedo ver que estás pidiendo el enlace del repositorio. Sí, vamos a compartir un enlace. Creo que ya es público, así que mi colega lo pasará al chat, y vamos a tener también el video completo, así como el repositorio y todo lo demás en el foro de Discord más tarde. Creo que va a ser la mejor manera de mantener la comunicación. Creo que alguien de Git Nation, Alexander tal vez, ya ha compartido el foro en la parte superior. Sí, sí, creo que está ahí. Así que ahora tenemos este servidor, y tenemos la aplicación en el servidor porque ahora la hemos construido. Y luego aquí, lo que estamos buscando es, tenemos la page.js. Y una vez más, es bastante difícil de leer, pero si buscamos suspense, puedes ver que se está utilizando un par de veces, y podemos ver el código que se genera aquí mismo. Así que está renderizando los hijos de loading, y luego la segunda vez, va a renderizar una vez que haya terminado de hacer su trabajo. Nos va a devolver los data de la API de Poki. Esa es la idea de esto. Ahí vamos. Así que una vez más, podemos ver un parche de espera. Sí, me gustaría mostrarte el árbol que se está generando. Solo tendría que encontrar dónde está generando ese árbol. Déjame ver. Sí, así que está en el index rsc. Y ahí vamos. Este es el árbol aquí mismo que podemos ver, donde tenemos los dos React suspense. En el React suspense, podemos ver un par de cosas. Podemos ver el número dos, que es el justo React suspense. Podemos ver la devolución aquí mismo, que está renderizando los hijos de loading, que tiene una referencia L3 aquí mismo. Y luego, podemos ver otros hijos aquí mismo. Se menciona muchas veces. Pero tenemos el segundo, donde en realidad está renderizando el contenido real que está volviendo. Ahí vamos. Está aquí mismo. Es bastante fácil notarlo porque esta vez, una vez que lo renderiza, obtenemos la respuesta de la API con el recuento de 64 y todos los resultados aquí mismo. Así es como funciona React suspense. Se envía como un script justo dentro de index.rsc. Y ahora, podemos ejecutar el run dev, ir a localhost 3000, y deberíamos poder ver cómo eso realmente funciona. Ahí vamos. Tenemos bienvenidos a Git Nation. Este es un componente de servidor. Y luego, podemos ver el componente sample suspense aquí mismo. Si recargo, tal vez podamos atraparlo. No, creo que lo guarda en caché. Una vez más, vamos a hablar mucho sobre la caché más adelante. Pero ahora, siempre va a estar aquí, y podemos ver todo el asunto. Y va a ser similar si lo inspeccionamos y vamos a elementos, puedes ver que se nos proporciona aquí mismo en este script, donde lo empuja más tarde. Así que tenemos script.push sample suspense component. Y sí, el código simplemente se nos proporciona aquí. Lo empuja cuando lo recibe. Esa es la idea del streaming, ¿verdad? Veamos. Así que al principio, vemos la carga. Luego, más tarde, vemos index.html, y así es exactamente cómo es el proceso. Déjame volver de este ejemplo. Y una vez más, todos estos ejemplos se te proporcionarán con el código, así como dentro del chat e información futura, tal vez en el readme de cada uno de estos ejemplos. Así que podrás sumergirte en ellos, y seguiré construyendo sobre estos ejemplos también.

También tenemos una pregunta. Así que básicamente, React dispensa algún contenido y muestra marcadores de posición listos en lugar de ellos mientras el fondo intenta prepararlos. Y cuando están listos, React simplemente los reemplaza. Eso es exactamente correcto, Halil. Eso es fenomenal. Se llama streaming. Has clavado el concepto de streaming perfectamente. Transmitimos ese contenido del servidor al cliente. React lo renderiza, lo reemplaza. Y es como si nada más hubiera pasado nunca. Simplemente funciona sin problemas. Así que eso es nuestro streaming SSR, el concepto de versión advanced de SSR. Bastante nuevo. No mucha gente lo conoce todavía. Así que es bastante genial que estés aquí escuchándolo.

Ahora hay dos tipos principales de SSR, regular y streaming. Acabamos de aprender sobre eso, ¿verdad? Dentro de Next.js, estos tipos se desglosan aún más en, por supuesto, ¿por qué tendría que ser dos si puede ser más, una renderización estática, que ocurre durante el tiempo de construcción de una aplicación donde las páginas se renderizan en el servidor en el momento de la construcción. Y es como lo que hemos estado haciendo hasta ahora cuando ejecutamos NPM run build, hasta ahora renderización estática, también conocida como generación de sitios estáticos, es la estrategia predeterminada utilizada en Next.js.

Ahora, para la renderización dinámica, esto renderiza la aplicación para cada usuario en el momento de su solicitud. Así que cada vez que un usuario hace una solicitud, la página se genera y se envía al cliente, dinámica, cada vez. Una pieza notable de innovación es que puedes decidir qué debe ser estático o dinámico renderizado en el diseño de la página a nivel de ruta en la última versión de Next.js. Hacer eso es súper simple. Como puedes ver, todo lo que tenemos que hacer es agregar este tipo de indicador en la página o ruta y Next.js automáticamente mostrará algo diferente. Así que hay este indicador, configuración del segmento de ruta, es solo cuestión de proporcionar la correcta configuración aquí.

Específicamente podemos hablar de cache, sé que ha habido algunas críticas para Next.js por no permitirnos especificar correctamente lo que queremos hacer. ¿Queremos hacer cache? ¿No queremos hacer cache? Creo que están añadiendo continuamente nuevas formas para que podamos modificar la forma en que nuestro contenido se renderiza realmente. Así que puedes elegir si es estático, forzar estático, forzar dinámico, automático, algo bastante genial. En este caso estamos hablando de revalidar. Puedes forzar el cache, puedes simplemente dejarlo en 0 o un número en este caso. Pero sí, puedes decidir forzar el cache si no quieres que tu contenido se actualice. Pero puedes dejarlo en falso si quieres que se revalide para diferentes usuarios. Además, también puedes elegir un término medio, que es mantener el contenido estático por un tiempo y luego cambiarlo después. Esto se conoce como generación estática incremental. Inicialmente, todas las páginas se renderizan estáticamente durante el tiempo de construcción. Después de un temporizador establecido, que podemos personalizar, el servidor vuelve a renderizar las páginas y las sirve al cliente a través de un CDN. Puedes especificar y optar por esta característica utilizando el revalidate de Next.js. Podemos simplemente proporcionar una variable simple de export const revalidate en la parte superior de una ruta específica y puedes establecerlo como un número. Creo que es en segundos. Si estableces algo como 1,200, va a revalidar cada 20 minutos. Depende de cuán dinámica quieras que sea tu aplicación y cuán rápida. Si está en cache, entonces si no necesitas que cambie, es fenomenal. Se renderiza en un instante. Si necesitas obtener nuevos data cada minuto o cada 20 minutos, puedes especificar exactamente eso.

Pasando a otro tema, ¿recuerdas cómo hicimos la obtención de data en los React Server Components? Fue así. Simplemente lo especificas, haces la función async, y luego obtienes algunos data, lo consigues, y lo presentas. Eso es todo. Ahora, ¿qué pasa si hay dos o más solicitudes que tenemos que hacer? Por ejemplo, primero, verificar si un usuario está autenticado, y luego hacer la llamada de data para obtener más información. Una solución a esto es lo que llamamos, otra palabra aquí, obtención de datos secuencial, una situación en la que las solicitudes en una ruta o página dependen entre sí. Va a parecer esto. Imagina que tienes una serie de tareas que quieres completar, como construir una torre de bloques. La obtención de datos secuencial es como hacer una tarea a la vez, donde cada tarea depende de la finalización de la anterior. Es como añadir un bloque y luego esperar a que se asiente antes de hacer el siguiente. Puedes querer comparar esto con hacer promesas. Puedes hacer punto, luego, punto, luego, que es simplemente uno tras otro. También tenemos promesa que todos, que hace todos a la vez. Diría que encadenar las promesas una tras otra es similar a la renderización secuencial. A veces este orden es esencial para casos como los que discutimos anteriormente. Sin embargo, si no tenemos cuidado, podríamos crear involuntariamente una situación en la que tengamos que esperar mucho tiempo antes de empezar la siguiente tarea. Así que mientras que la obtención de datos secuencial puede ser útil para algunas condiciones específicas, puede hacer involuntariamente que las cosas tarden más en terminar. Y este fenómeno, en términos técnicos, también se conoce como cascada.

Entonces, ¿cómo no crear cascadas de solicitudes? Bueno, podría haber un caso en el que queramos hacer múltiples solicitudes que no dependen entre sí. ¿Cómo podemos manejar tal caso sin bloquear la aplicación? Bueno, ahí es donde entra en juego la obtención de datos en paralelo. Como su nombre indica, nos permite hacer múltiples solicitudes en paralelo. Piensa en la obtención de datos en paralelo como tener múltiples ayudantes para hacer las cosas al mismo tiempo. En lugar de hacer una tarea tras otra, todas las tareas comienzan juntas. Es como tener varios amigos que trabajan en diferentes partes del proyecto al mismo tiempo. Aunque podría no ser el mejor ejemplo ya que podríamos saber que cuantos más desarrolladores añadas al proyecto podría terminar tardando más. Pero no pensemos en eso de esta manera ahora. Entonces, ¿cómo podemos hacer eso? Es, diría yo, simple. Sí, hay muchas cosas que podemos hacer en XJS y por eso a mucha gente le gusta. Mira esto. Lo que tenemos aquí es una función async donde tenemos muestra de obtención de datos en paralelo donde obtenemos los parámetros y luego en base a los parámetros que todavía están en el lado del servidor, obtenemos un producto específico ejecutando la función product.findById y pasando el id de los parámetros. Una vez que obtenemos el, solo una vez que obtenemos el producto, ¿verdad?, podemos encontrar las reseñas para ese producto. Técnicamente podríamos mantener las dos cosas al mismo tiempo, ¿verdad? No tienes que esperar a que el producto pueda obtener las reseñas del producto porque solo necesitas el id para poder obtener las reseñas del producto, ¿verdad? Entonces, ¿qué hacemos aquí? Lo encadenamos en un productReviews y obtenemos el await promisehole. Mira, algo similar a lo que te he estado contando es cómo podrías haber estado imaginándolo todo este tiempo. Simplemente lo pones en un promisehole donde obtienes el producto y las reseñas pero es tan genial cómo lo han hecho. Pasas un array de dos llamadas diferentes. ¿Dirías que esto es más JavaScript que Next.js? Supongo que esa es una buena pregunta, ¿verdad? Porque todos hemos estado acostumbrados a los promiseholes y me encantó cuando salió que es tan conveniente poder usarlo aquí mismo dentro de nuestra aplicación Next.js ahora.

Así que ahora empezamos a mostrar ambos una vez que el promisehole termina. Así que esperamos el producto y las reseñas y mostramos ambos una vez que obtenemos los data para ello. Ahora hay otra cosa de la que quiero hablar realmente rápido y se llama precarga de dat

Antes de sumergirnos en el cache, quiero hacer una transición aquí, y quiero hacer una pausa para que todos podamos leer por un segundo. Cubrimos una cantidad excepcional de data e información en esta... No estoy seguro de cuánto tiempo ha pasado. ¿Alrededor de una hora, verdad? Quizás incluso una cantidad inhumana de data que definitivamente no podemos procesar en una hora. Así que si vas a obtener algo de esta masterclass, me gustaría que obtuvieras solo la idea, ¿verdad?, de todo esto. Solo ten en cuenta que existe. Solo ten en cuenta que tal vez cuando estés desarrollando una aplicación en el futuro, recuerda que has oído hablar de esto. Recuerda que existe, y recuerda que Next.js probablemente lo abstrae de una manera que facilita su consumo y su incorporación a tu aplicación. Así que no trates de sentirte mal por no entender o no escuchar correctamente todas las cosas que compartí ahora mismo. Es imposible. Así que mantén la calma al respecto. Ten en cuenta que vas a tener todos estos ejemplos, demostraciones, y todo lo que compartimos en un enlace. Ya lo compartimos en el chat. Lo vamos a compartir varias veces. Vamos a seguir construyendo sobre esos ejemplos y a tomarlo con calma. Solo ten en cuenta que estos conceptos existen y luego utilízalos cuando los necesites yendo a la documentation, ¿verdad? Solo quiero presentarte estos conceptos, ¿verdad? No para enseñártelos ahora mismo, de golpe. Es imposible, especialmente en aplicaciones más grandes. Así que hagamos una pequeña pausa aquí. Siéntete libre de discutirlo en el chat, muy probablemente, y luego podemos tomar quizás un descanso de 10 minutos y luego podemos volver y hablar sobre aún más características nuevas y geniales, continuando con el cache.

Está bien. Sí, como dije, trato de incluir tantos de estos conceptos como sea posible. Mi equipo y yo hemos dedicado mucho tiempo a profundizar en estas características en la alfa y luego en la beta y ahora en la versión estable con acciones de servidor, con cache. Es difícil, ¿verdad? Pero de nuevo, cuanto más sepas al respecto, no quiero darte algunas respuestas definitivas ahora mismo. Quiero presentarte temas y luego podrás profundizar en la documentación, pero quiero que sepas que estas cosas existen. Así que vamos a tomar un pequeño descanso, y luego vamos a profundizar en todo esto.

Está bien, eso es genial. Eso es genial. Sí, volviendo al cache aquí mismo. El cache es un tema que a algunas personas no les gustó cómo lo manejó Next.js. Sí. ¿Eres tal vez uno de esos? Porque Next.js, al parecer, abstrajo demasiado la forma en que manejamos el cache. Algunas personas dicen que preferirían un poco más de capacidad para gestionar qué, cuándo y cómo se almacena en cache. Está bien. Así que ahora vamos a empezar de inmediato con la demo. Y haré todo lo posible para mostrarte que Next.js te da muchas posibilidades para modificar la forma en que se almacenan las cosas en cache, tal vez incluso demasiado. No, la cantidad justa. Pero no muchas personas saben cómo modificarlo todo. Tal vez debería haber sido más obvio en la documentación, pero vamos a repasarlo juntos. Así que comencemos con el siguiente ejemplo aquí mismo. Voy a obtener la carpeta hello-cache aquí mismo, que podemos explorar juntos. Así que voy a pegarla aquí mismo. Y una vez más será una aplicación típica de Next.js. Y queremos asegurarnos, primero veamos qué tenemos aquí. Bueno, voy a ejecutar, voy a navegar a ella, navegar a hello-cache. CD hello-cache. Ahí vamos. Y ejecutar primero NPM install. Así que podemos verlo bien. Y luego lo voy a ejecutar. Y te voy a mostrar un pequeño truco genial que también puedes hacer.

Así que primero, aquí mismo dentro de este hello-cache, hablemos de lo que está haciendo. Aquí tenemos una página de inicio donde obtenemos, una vez más, algunos datos de la API de Poki. Los devolvemos y los convertimos en cadena de texto y los mostramos. Bastante simple. En el diseño, no está pasando nada demasiado interesante. Y tenemos otra obtención aquí mismo, que es un componente, que está haciendo la misma exacta obtención. Podemos mostrarlo aquí mismo. Es exactamente lo mismo que está pasando aquí mismo. Limitar a 10, versión 2, Pokemon, simplemente danos los datos y muéstralos. Pero aquí puedes ver la misma obtención, y luego la está devolviendo. Y ahora mismo, no estamos usando este componente en absoluto. Solo se está importando aquí mismo.

Ahora lo que queremos hacer es queremos habilitar algo de carga aquí mismo. Quiero habilitar opciones adicionales de registro por Next.js. Y hay una bonita página de documentación que se ve así. De nuevo, algo que no mucha gente conoce. Te permite configurar el nivel de registro y si la URL completa está bloqueada en la consola, estamos ejecutando Next.js en modo de desarrollo. Así que lo que podemos hacer es que podemos habilitar esta carga completa de URL en Next.config.js haciendo esta parte de registro aquí mismo. Así que si volvemos y vamos a Next.config aquí mismo, puedes ver que hemos habilitado el registro de la URL completa. Así que lo que voy a hacer ahora es que voy a ejecutar npm run dev para poner en marcha nuestra aplicación. Y en localhost, podemos ver algo que se ve así. Va a ser solo todos los datos que obtenemos de la API de Poki. Y los obtenemos aquí mismo, 200 en 2620 milisegundos. Obtenemos la solicitud aquí mismo, y puedes ver los aciertos y omisiones del cache aquí mismo, lo cual es interesante. Primero que nada, normalmente nunca ves esto. Solo lo estás viendo ahora mismo porque hemos habilitado el registro. Y ahora lo que queremos hacer es eliminar la carpeta Next y luego reiniciarla de nuevo. Vamos a tratar de ver qué rutas tienen diferentes cosas aquí mismo. Y dame solo un momento.

Esta demo es simplemente fenomenal. Tenemos muchas cosas sucediendo. Y como dije, estamos en la vanguardia ahora mismo del cache y de la forma en que Next.js lo maneja. Voy a ser completamente honesto ahora mismo, esta demo fue creada para mí por mi colega, Sujata. Ella también está aquí con nosotros. Así que si me quedo atascado tratando de explicar algunas de estas partes, ella podrá simplemente saltar y ayudarnos también. Esencialmente tenemos esta página Acerca de aquí mismo donde estamos haciendo exactamente lo mismo que estamos haciendo en la página de inicio. Dos de las mismas páginas exactas. Y estamos haciendo, una vez más, la misma llamada exacta. Así que ahora, lo que queremos hacer es tal vez también navegar a esa página para ver qué está pasando. Podemos hacer eso muy rápidamente yendo a Acerca de. Así que déjame abrirlo. Creo que ya lo tengo abierto, debería estar aquí mismo. Ahí vamos, localhost 3000. Y podemos verlo aquí mismo. Y también podemos navegar a forward slash Acerca de. ¿Lo mismo exactamente, verdad? Pero ¿qué pasó aquí mismo? Puedes ver que obtenemos un acierto de cache, lo que significa que encontró el cache existente, y luego lo acertó. Está bien, lo mismo. Y tenemos una omisión una vez más porque también lo omitió. Así que Sujata, que es mi colega aquí mismo, quiero preguntarte, ¿te importaría profundizar un poco en la forma en que acertamos o saltamos elementos específicos?

Sí, claro. Hola a todos. Así que sí, hablando sobre el cache que está ocurriendo aquí. Perdón por la pronunciación si hago que algo suene diferente. Pero sí, hablemos brevemente de esto. Así que lo que estamos demostrando es que en Next.js, en lugar de usar algún estado global, API de contexto o cualquier cosa del Rails toolkit, que convertiría nuestros componentes en componentes de cliente, y no podríamos obtener el beneficio de las RSCs del lado del servidor de la aplicación. Así que lo que hacemos es que simplemente hacemos llamadas de obtención en otras páginas. Así que por ejemplo, estamos haciendo una llamada de obtención en una página y los mismos datos que necesitamos en la página Acerca de simplemente estamos haciendo esa llamada allí. Así que lo que sucede es que la primera vez que visitas la página, el cache será omitido. Esta es la primera vez que hacemos una solicitud a esa URL. Pero la próxima vez que visites cualquier página que esté llamando a la misma URL o haciendo la misma solicitud a esa API de Oak que estamos usando, en lugar de hacer una llamada a esa API de Oak, utilizará los resultados de cache que Next.js ha almacenado para nosotros. Así que si vamos a la carpeta .next allí.

Eso es bastante genial. Entonces, lo que está sucediendo detrás de escena es que Next.js creó un contenedor para la funcionalidad de fetch y Next.js detrás de escena sabe inmediatamente que esta llamada ya se ha hecho, sin importar que la estemos llamando desde una página completamente diferente. Y luego lo golpea y lo obtiene del caché. ¿Es eso correcto?

Sí, eso es completamente correcto. Y eso viene de aquí, fetch cache. Y técnicamente genera este archivo. Y es bastante difícil de ver, pero lo verás usando los servicios de Cloudflare aquí mismo. Ahí vamos. Cloudflare. Podemos darle formato. No estoy seguro de cómo puedo hacer eso. Aquí. Puedes hacer clic derecho y verás un formato. Bueno, ahí vamos. Eso es mucho mejor. Necesitaría configurar el formateador. Pero sí, creo que esto está bien. Ahí vamos. Esto es mucho mejor. Pero ahora, sí, puedes ver que está usando Cloudflare como servidor. Y luego está almacenando en caché las respuestas y enviándolas de vuelta a nosotros. ¿Correcto? Eso es. Si ves el final de esa página, verás la URL que ha sido almacenada en caché. El tiempo de revalidación. Eso es. Y la revalidación está aquí mismo.

Esto es asombroso. Como dije, quería tener a Sujata aquí también. Es tan loco que incluso yo mismo tratando de crear todos estos videos educativos, es tan difícil mantenerse en la vanguardia de la tecnología. Y quería hoy proporcionarte lo último y lo mejor de todo lo que estamos haciendo en este momento. Así que todas estas demostraciones han sido creadas específicamente para ti hoy para poder revisar ellas. Creo que esto me permite ahora volver rápidamente a la presentación aquí mismo y mostrar un poco más. Así que ya hablamos de esto. Tenemos muchas cosas. Queremos almacenar en caché cosas específicas. ¿Correcto? Entonces Sujata, hablamos ahora sobre fetch cache. ¿Queremos seguir hablando de ello o queremos sumergirnos en otros cachés también?

Sí. Quiero decir, la pregunta básica que creo que tendríamos es que podría haber un caso en que queramos buscar o usar fetch todo el tiempo. Sí. Entonces surge la pregunta de qué debemos hacer o cómo almacenamos en caché el contenido o cómo Next.js mide eso si no usamos fetch. Por ejemplo, solo queremos hacer directamente las llamadas TTP dentro de los React components. Así que almacenamos en caché o no. Así que para eso, tenemos nuestra siguiente cosa, que se llama React cache.

Creo que es un acierto. Sí, eso es correcto. Así que hemos visto todo eso. Y es tan fácil porque, una vez más, Next.js lo hace increíble porque no tenemos que hacer absolutamente nada. Simplemente tienes que usar la llamada básica de fetch. Y eso es todo. Funciona de inmediato. Y también puedes establecer un temporizador y decirle que revalide después de un tiempo específico. Así que aquí tenemos tiempo basado. Puedes revalidar las llamadas de fetch después, por ejemplo, esto son 3600 segundos. Así que todavía tienes... Porque algunas personas están confundidas. Piénsalo. Por ejemplo, nunca le dijimos explícitamente a Next.js que almacenara nada en caché. Y aún así, lo hizo. Lo cual tú como desarrollador podrías pensar, ¿por qué estás haciendo cosas por mí? No sé cuándo vas a almacenarlo en caché y cuándo no. ¿Y si quiero obtener mis data frescos? Afortunadamente, todavía podemos revalidar los data después de una cantidad específica de segundos. También podemos revalidarlo bajo demanda. Podemos extender la API de Fetch para decidir la revalidación del caché dependiendo de tus necesidades específicas. Y hay dos formas de hacer esto. La primera es la etiqueta de Revalidación. Así que puedes agregar esta etiqueta de Revalidación a la llamada de Fetch, a las etiquetas de Next, y luego decir qué quieres revalidar. Específicamente una vez que haces esta llamada a la API. Y luego lo usas así. Así que vamos al nuevo servidor. Esta es una acción de servidor donde importamos la etiqueta de Revalidación de Next cache. Y luego una vez que esto sucede, quieres revalidar esa etiqueta específica de publicaciones. Veremos cómo usamos esto en el nuevo servidor muy pronto. Eso es emocionante. Luego también está Revalidate path aquí mismo. Similar a Revalidate tag, pero tenemos que especificar la ruta que queremos revalidar y luego tener data frescos. Así que en este caso, podemos revalidar publicaciones forward slash slug, que sería una ID de publicación específica después de que tal vez cambies los data de la publicación. Y puedes encontrar más formas en las que podemos revalidar páginas, rutas y más en la documentation de Revalidate path en Next.js. Así que ahora hemos aprendido sobre el caché y cómo revalidarlo. Pero puede que todavía tengas una duda. Podrías estar pensando que, ¿puede ser almacenado en caché solo cuando se usa fetch? Eso es lo único que hemos hecho hasta ahora. ¿Y si no queremos usarlo y preferimos hacer llamadas directas a la base de datos en los componentes de servidor de React como este? ¿Dónde está el fetch aquí? En ninguna parte. Estamos usando Prisma, ¿verdad? Para hacer simplemente una búsqueda regular desde la database. Y cualquier otra solución de terceros, podemos usar React cache para almacenar en caché estas solicitudes. Permíteme mostrarte cómo hacer eso en un ejemplo simple. Voy a abrir, una vez más, nuestra base de código aquí mismo, y voy a darnos tal vez el cuarto, creo, o sí, este es el tercero, tal vez, o el cuarto, ejemplo del día. Lo vamos a llamar, hola, React cache porque ya no estamos trabajando solo con fetch cache. Aquí, tenemos nuestra aplicación. Podemos, por supuesto, navegar a ella como antes haciendo cd, y luego navegando a hola, React cache, y ejecutando npm install para comenzar. Aquí mismo, primero visitemos nuestra página como siempre hacemos. Aquí, estamos llamando a dos cosas diferentes, con resultado de caché y sin resultado de caché. Estas son solo algunas funciones de utilidad simples que, si entramos en ellas, generan un número aleatorio y luego, si no lo almacenamos en caché, se verá así.

Simplemente vamos a establecer esta variable a ese número aleatorio específico, o más bien a una declaración de función que va a obtener ese número aleatorio, y luego aquí, almacenamos en caché esa respuesta proveniente de React. Ten en cuenta, esta es una funcionalidad básica de React. Almacenamos en caché esa declaración de función. Luego, los llamamos aquí mismo, y simplemente los mostramos. Número aleatorio en la página de inicio con caché, y sin caché. Veamos un poco cómo funciona eso. Lo mismo aquí. También los estamos llamando en un componente de servidor de muestra. Este es el servidor, y este también es el servidor aquí. Lo estamos llamando en dos lugares diferentes para que podamos ver exactamente cómo va a funcionar, y por qué y dónde estamos viendo este componente del servidor? Va a estar aquí. Lo mostramos una vez normalmente, solo en la página regular, y luego mostramos lo mismo proveniente de un componente de servidor diferente para que podamos ver exactamente cómo va a almacenar en caché los data aquí mismo. También estamos haciendo lo mismo en el about para, una vez más, averiguar cómo está almacenando en caché. Veamos un poco y veamos qué sucede. Voy a ejecutar npm run dev, y lo abriré en localhost 3000, como solemos hacer. Todo debería ser visible aquí. En la página, el número aleatorio en la página de inicio con caché es 91. Dentro del componente, el componente de servidor de muestra, el servidor de muestra aquí, también es 91 con caché. Sin caché, obtenemos 6472. Si actualizamos, vemos un nuevo número con caché, 38 y 38. ¿Qué está pasando? No es un error ni nada, es cómo funciona el caché de React. No almacena los resultados a través de las rutas, pero memoriza las rutas de solicitud que haremos dentro de una página.

Profundicemos un poco más en el tema de la memoización de solicitudes. ¿Qué es la memoización de solicitudes? Bueno, es una táctica en la que si estamos enviando muchas solicitudes a través de varios componentes dentro de una sola página o ruta, algunas de las cuales son idénticas y algunas de las cuales son diferentes, el caché de React asegura que estas solicitudes se memorizan. Esto significa que solo se ejecutan las solicitudes. Si se hacen las mismas solicitudes en diferentes lugares, en lugar de hacer solicitudes para cada una, solo se envía una solicitud y los data se comparten entre los componentes que iniciaron esas solicitudes en esa página.

Una vez más, imagina si tienes ese asistente mágico que puede buscar cosas para ti. Con la magia de React, si pides la misma cosa pero en diferentes partes de tu aplicación, incluso si está en diferentes lugares, no va a buscarlo cada vez. Va a intentar obtenerlo del caché. En términos más sencillos, digamos que tienes tu snack favorito, y si quieres ese snack en tu habitación, tu sala de estar, y la casa de tu amigo, no necesitas ir a la cocina cada vez. React te ayuda a obtener tu snack dondequiera que estés sin tener que buscarlo en la cocina una y otra vez. Esto es útil porque puedes obtener la misma información en diferentes partes de tu aplicación sin preocuparte por hacer viajes innecesarios para obtenerla, lo que hace las cosas más rápidas y más eficientes.

Sin embargo, esto ocurre a nivel de ruta. Para demostrarlo, si creo otra página con llamadas de fetch idénticas, no observaremos el mismo resultado para los data en caché como lo hicimos en la página de inicio. La Optimization solo se aplica a esa ruta en particular y a los componentes dentro de ella. ¿De acuerdo? Entonces, ¿qué pasa si tienes cosas como fetch persistiendo los mismos data en toda la aplicación? Bueno, Next.js te tiene cubierto. Aunque el equipo todavía está trabajando en ello, como en muchas otras cosas, puedes usar algo como caché inestable para almacenar en caché tus solicitudes a través de las rutas, y aquí, podemos saludar o decir hola al caché inestable.

Así que vamos a iniciar rápidamente un nuevo proyecto aquí mismo. Podemos cerrar este. Creo que cubrimos prácticamente todo lo que queríamos con este, ¿verdad, Sujata? La forma en que lo almacena en caché a través de las rutas. Sí, eso es lo principal del caché de React. Eso es todo. Hemos visto primero solo el caché general de fetch, que almacena en caché las solicitudes de fetch. Luego podemos ver, hemos visto el caché de React, que lo almacena en caché a través de las rutas. Y ahora podemos dar la bienvenida al siguiente, que es hola caché inestable. Si puedo ponerlo aquí mismo en la raíz de mi directorio. Ahí vamos. Ese es otro tema en el que podemos profundizar. Así que, como siempre, déjame abrirlo. Quería proporcionarte demos reales, así que tomará un poco de tiempo pero espero que podamos pasar por ello. Ahí vamos. Y queremos ejecutarlo e instalarlo. En los utils aquí mismo, la aplicación sigue siendo muy similar, ¿verdad? Tenemos lo mismo que antes. Solo estamos construyendo sobre el ejemplo anterior, donde tenemos el obtener data con caché, obtener data sin caché. Y luego ahora en los utils, hemos añadido obtener data con caché inestable, donde envolvemos la declaración de función de obtener número aleatorio. Veo un error de tipeo aquí, pero vamos a corregirlo. Vamos a envolverlo con el caché inestable que viene de next forward slash cache. Bastante nuevo, bastante emocionante. Es solo una función simple como puedes ver aquí mismo, pero hace maravillas. Ahora, ¿qué hacemos aquí? Lo estamos añadiendo a nuestras llamadas anteriores. Y de manera similar, lo tenemos en nuestra página de inicio, lo tenemos en nuestra página de servidor de muestra, y también lo tenemos en nuestra página about. Lo mismo que antes. Lo estamos importando en todas partes. Entonces, ¿qué pasa si lo probamos? ¿Qué pasa si ahora ejecuto npm run dev y trato de probarlo? ¿Qué crees que va a pasar? En nuestra página de inicio, obtenemos con caché 22 y por supuesto está almacenado en caché en esa página específica. Con caché inestable, también permanece, en este caso, generado como 75. Así que ahora si recargo una vez más, y si sigo recargando, vas a notar que con caché inestable, permanece como 75. De manera similar si cambiamos a otra ruta aquí mismo, si vamos a forward slash about, vas a ver que con caché inestable es una vez más 75. El mismo resultado que hemos experimentado con Fetch Web API, pero esta vez, es a través de las rutas, no solo en una ruta. Y aunque el nombre de rutas inestables podría sugerir inestabilidad, el equipo de next.js está activamente desarrollándolo y va a ser lanzado muy pronto. Así que una vez más, si vamos a las diapositivas muy rápidamente, ¿puedes usarlo en producción? Ahora mismo, procede bajo tu propio riesgo, ¿verdad? Pero esperemos que pronto, el equipo de next.js lo tenga listo. De hecho, el vicepresidente de Vercel ahora lo usa en su sitio web en producción, y podemos ver el código aquí mismo. Muy genial. Eso es una señal clara de que se está volviendo cada vez más estable y confiable. Pero vamos a finalizar este ejemplo y simplemente redondearlo. ¿Qué hemos visto en esto? ¿Qué significa esto? Tenemos muchas cosas diferentes, pero el caché inestable parece permanecer en toda la aplicación. ¿Es eso bueno? ¿Es malo? ¿Cómo lo modificamos? Entonces, Jada, ¿qué dirías aquí? ¿Cuál es la conclusión de solo fetch? Conocemos fetch. Es solo cuando usamos fetch, y luego tenemos solo el caché y luego el caché inestable. ¿Cuál es la conclusión aquí entre esos dos? Sí, quiero decir, lo primero que debemos entender es que el Caché de React solo almacena en caché la solicitud para esa página o esa ruta que estamos utilizando. Pero lo que obtenemos con el caché inestable es el resultado que obtenemos con cualquier llamada normal de fetch o solicitudes de fetch que hacemos. Así que podría haber un caso en el que lo querríamos, pero de nuevo, también podría haber casos en los que no querríamos estos escenarios. Así que tenemos que entender primero lo que queremos. Así que por ejemplo, quieres construir un sitio web de blog, podrías querer almacenar en caché estas cosas, todas estas cosas. Así que no harías la solicitud al servidor principal una y otra vez, sino que confiarías en las redes CDN de next year. Así es donde puedes usar el caché inestable o el Caché de React. Pero sí, el punto de todo esto es que haciendo esto, no tenemos que usar o gestionar ninguna biblioteca de gestión de estado como API de contexto, Redux toolkit o cualquier cosa. Pero ten en cuenta que no significa que next year's los esté reemplazando, o simplemente les esté diciendo que no los usen en absoluto. Puede haber casos en los que todavía los necesitemos. Sin eso, no podrás avanzar. Si entiendes este mecanismo de caché y sigues haciendo las llamadas, considerando lo que está pasando, entonces estás listo para ir sin la biblioteca de gestión de estado en las aplicaciones de next year. Eso es correcto. Pero dirías que está haciendo un gran progreso al darnos a los desarrolladores más control sobre cómo se maneja el caché, mientras que no lo estaba haciendo tan pronto como salió next year's 13? Sí, estoy de acuerdo. Quiero decir, si tenemos que almacenar en caché algo normalmente sin next year's, es un proceso muy difícil. Tienes que configurar las redes CDM. Tienes que gestionarlas, toda la infraestructura, todo. Pero sí, gracias a next year's y a la infraestructura de Vercel, todo lo que tienes que hacer es centrarte en la lógica de negocio. No tienes que preocuparte por nada más. Solo entiende el concepto y confía en Vercel que manejará todos estos casos por ti. Sí, hace que el desarrollo del TX sea muy bueno. Realmente lo hace. Vamos a resumirlo una vez más. El caché es un mecanismo especial de almacenamiento en memoria utilizado en la informática para almacenar datos de acceso frecuente o recientemente utilizados, permitiendo lanzamientos más rápidos aquí. Va a permitirnos recuperarlo mucho más rápido cuando se necesiten los mismos data de nuevo. Así que next year's tiene soporte incorporado para mecanismos de caché con la ayuda de las características de react. Una vez más, no chocan. No es como decir, ya sabes, react lo tiene todo, o react también lo tiene. Correcto. Se trata de fusionar los dos y permitirnos usarlo con next year's también. Viste que, por ejemplo, para las solicitudes de fetch, next year's simplemente las envuelve. Mientras que para el mecanismo de caché de react, simplemente lo usa directamente desde la importación que viene directamente de react. Y luego para el caché inestable, esa importación viene de next year's puede parecer un poco difícil ahora mismo, pero espero que las cosas sean un poco más fluidas en el futuro. Así que next year's extiende la API web nativa de fetch para almacenar en caché todas las solicitudes de fetch automáticamente. Podemos optar por no utilizar ese almacenamiento automático de solicitudes de fetch proporcionando la funcionalidad de no almacenar.

Entonces, esto es, en primer lugar, un muy buen paso por parte de Next.js, algunas personas lo encontraron molesto porque no sabían cuándo se buscarían las cosas y cuándo no. Pero afortunadamente, ahora también tenemos este cache no store, así como muchas otras opciones. También tenemos otras dos formas de revalidar en Next.js. Tenemos este next revalidate, que es la cantidad de segundos en los que intentará volver a buscarlo. Y luego también tenemos bajo demanda, que es genial. Nos permite revalidar una etiqueta específica como en este caso, donde podemos revalidar la etiqueta de publicaciones y luego recordarla en una acción del servidor. También tenemos un revalidate path aquí mismo, donde va a revalidar una llamada a un camino específico. También podemos usar el caché de react para almacenar en caché cualquier solución de terceros como Prisma o cualquier llamada que no esté relacionada con fetch. Y podemos usar el caché de Next para almacenar en caché los data en toda la aplicación. Ten en cuenta que la revalidación de discuss no está limitada a fetch web API. Puedes usar las mismas técnicas de revalidación de caché basadas en tiempo y bajo demanda con el caché de react o el caché inestable de Next.js. Y hay dos estrategias poderosas que nos ayudan a optimizar la obtención de data y reducir el tamaño del paquete de javascript. Existe el caché de data aquí mismo que viene de next cache, y está la memoización de solicitudes utilizando el caché de solicitudes. Así que se trata de averiguar cómo usar todo esto junto lo que nos permitirá realmente no estar molestos por el hecho de que Next.js está almacenando en caché algunas cosas que no queremos. Pero más bien usar el caché como una forma de optimizar la obtención de data de nuestras aplicaciones de Next.js y react.

Para ser completamente honesto, en este momento está un poco por todas partes, la forma en que ellos envuelven el fetch, a lo que no estamos acostumbrados, ¿verdad? Porque usamos fetch todos los días. Y no asumiríamos que este fetch que estamos llamando es diferente del fetch regular de JavaScript, ¿verdad? Eso es una cosa. Y luego también el hecho de que tenemos que llamar al cache inestable de next o al cache de react de react. En este momento, no me gusta cómo está estructurado actualmente. Pero esperemos que las cosas estén bien, las cosas se simplificarán un poco más con el cache en el futuro.

Así que aunque exploramos o realmente lo usamos antes de explicarlo, quiero hablar un poco más sobre esto correctamente. ¿Recuerdas cuando usamos el servidor de usuarios en lugar de utils antes para demostrar el cache? Quiero preguntarles cuántos de ustedes han usado el servidor de usuarios antes? ¿O acciones del servidor o con los próximos años en general? ¿Lo has usado? Bueno, eso es interesante. El servidor de usuarios es una directiva similar al cliente de usuarios. Y puedo ver más noes que síes. Pero podrías haber tenido una corazonada de lo que esto está a punto de simbolizar. Es algo sobre las cosas del servidor, ¿verdad? Normalmente, se conocen como acciones de react, o acciones del servidor de react. Estas son acciones asíncronas simples que se ejecutan en el servidor. Eso es. Pero, ¿por qué necesitamos acciones del servidor? Y hablemos un poco más sobre ellas. Así que una vez más para explicar, usamos la directiva del usuario, la añadimos a un archivo típico de JavaScript, y todo el código que está allí, puedes escribirlo como código regular de JavaScript. Pero se va a renderizar en el servidor. Eso es. ¿Tiene sentido? Así que te permite proporcionar un código de JavaScript más simple, pero lo ejecutas directamente en el servidor. Pero la pregunta es, ¿por qué necesitaríamos hacer eso? Así que no diría que es un reemplazo, sino que es una opción para hacer mutaciones sobre los manejadores de rutas tradicionales. Podemos usar estas acciones del servidor tanto en componentes del servidor como del cliente, lo que las convierte en una característica útil para usar. Aunque Vercel podría estar inclinado a mostrar el uso de esta característica para envíos de formularios o mutaciones, también podemos usarlas para consultar cosas. Si aún no estás convencido, veamos una demostración rápida y veremos cuán útiles y prácticas son al construir una aplicación.

Podemos crear y usar acciones del servidor de dos maneras. En componentes del servidor donde podemos agregar la directiva aquí mismo, usar la directiva del servidor en la parte superior de un componente del servidor, dentro de cualquier componente de React para el caso, y podemos hacerlo asíncrono de esta manera para convertirlo en una acción del servidor. Así que este es un componente de servidor típico donde puedes crear una nueva función asíncrona create donde usas el servidor. El código dentro de aquí se va a renderizar en el servidor, por supuesto. ¿Por qué te estoy mostrando esto? Porque también podemos usarlos dentro de los componentes del cliente, que es lo que los hace especiales. La forma de usar acciones del servidor dentro de los componentes del cliente es un poco diferente. Dentro de lo que hicimos en el componente del servidor, ahora tenemos que crear un nuevo archivo, declarar todo dentro de él como use server y luego importar estas funciones dentro de los componentes del cliente de esta manera, donde tenemos un nuevo archivo, use server, create y remove, y luego podemos llamarlos cuando los necesitemos, ya sea ese componente del cliente o del servidor. Como en este caso, como puedes ver, estamos importando create de acciones y sabemos que es un componente del servidor. En este caso, creo que olvidé ponerlo en la parte superior pero debería ir sin decir, ¿verdad? Estamos usando el estado aquí, lo que significa que este formulario es un componente del lado del cliente. Pero la clave aquí es que todavía podemos usar la acción del servidor aquí mismo, ¿de acuerdo? Así que tenemos el await create y llamamos a la acción del servidor, el handle submit, y luego tenemos el resto del formulario, ¿verdad? Lo que esto nos permite hacer básicamente es bastante loco. Nos permite hacer una llamada del lado del servidor dentro de un componente del cliente. ¿Está claro hasta ahora? No quiero proceder si este concepto no está claro aquí. Es un poco contraintuitivo porque aunque tenemos un componente del cliente y todo este código aquí es del cliente, ten en cuenta que estamos modificando los data, ¿verdad? Estamos modificando el formulario, los campos y todo. Aún así, podemos llamar a una acción del servidor justo dentro de él. ¿Tiene sentido? Bueno, sí, lo cual es genial. Ahora podrías pensar que es genial, podrías pensar que es innecesario, pero vamos a explorar por qué podríamos necesitar hacer eso. Eso nos permitiría no crear ninguna API adicional para realizar cualquier acción normal de CRUD. En este caso, las acciones del servidor te tienen cubierto. Next.js ha hecho las cosas tan simples de hacer. Pero podrías pensar, ¿cómo funcionan? ¿Y cómo podemos llamar a un componente del servidor, o lo siento, a una función del servidor dentro de un componente del cliente? Piensa, ¿cómo es posible? Bueno, no hay ciencia de cohetes aquí. Las acciones del servidor que usamos en los componentes del cliente básicamente se convierten en una solicitud POST por Next.js para nosotros, ¿de acuerdo? Cualquier tipo de acciones del servidor, ya sea que obtengamos alguna información o agreguemos algunos data a la database, la actualicemos, la eliminemos, Next.js llama a nuestro servidor a través de una solicitud POST, pero eso es solo para acciones del servidor dentro de los componentes del cliente. Así que Next.js una vez más lo abstrae y hace una solicitud POST del servidor para nosotros desde el componente del cliente, por lo que todavía está en el servidor. Y puedo ver una pregunta de Halil aquí mismo sobre el concepto de usar el servidor de usuarios. Es para acciones del servidor, eso es correcto, y es para diferenciar entre el código del lado del cliente y del servidor. Sí, eso es totalmente correcto. Así que usamos la directiva del servidor de usuarios como usaríamos la directiva del cliente de usuarios. Lo ponemos en la parte superior del archivo, y lo que escribimos allí se va a ejecutar en el servidor. Volviendo a nuestro ejemplo con el formulario aquí mismo, si tengo que retroceder mucho, pero si no ponemos la directiva del servidor de usuarios aquí mismo, se renderizaría en el lado del cliente. Creo que anticipé tu pregunta aquí, pero ¿no son por defecto archivos del lado del servidor? ¿Tenemos que especificarlo? Bueno, Halil, si no tuvieras esta directiva del servidor de usuarios aquí mismo en estas dos acciones del servidor, y luego si las llamaras aquí mismo dentro de tu handle submit, ¿dónde sería llamado? ¿Qué es este código? ¿Es del lado del cliente o del servidor, verdad? Así que por defecto, no sería del lado del servidor, porque estamos dentro de un componente del lado del cliente llamado formulario. ¿Tiene sentido? Sí, me gustaría agregar algo aquí. Así que inicialmente esta era la architecture de React. Inicialmente, querían separar el lado del cliente y del servidor a través de la architecture basada en archivos. Así que si escribes dentro de un nombre que esto es un servidor dot ts o js y eso data como un componente del servidor. Pero luego estas banderas comenzaron como una forma más iniciativa de escribir código del lado del servidor y del cliente. Por supuesto, para RSC, no tienes que especificar estos porque eso es lo que Next.js usa por defecto. Pero para cualquier cosa que quieras hacer en el lado del servidor, solo usa esta bandera. Así que incluso si usas esto para componentes RSC, creo que deberían funcionar tal como están, porque ya los están usando detrás de escena. Exactamente, exactamente. Así que en casos en los que, si fueras a usar esto dentro de un componente del servidor, entonces Halil tendría razón. Sería en el servidor por defecto. Pero si esto te permite llamarlo dentro de un componente del lado del cliente también. Así que exactamente. Sí, dijiste que es como tener la herramienta en los data. Así que lo juegas allí si usas el servidor de usuarios. Pero si no lo especificas obtienes la herramienta y la juegas en el lado del cliente. Eso es totalmente correcto. Sí. Así que estoy realmente feliz de que eso tenga sentido ahora. Así que permíteme volver rápidamente a donde estábamos, que está aquí mismo. Obteniendo algunos data, subiéndolos, borrándolos. Y sí, Next.js hace una solicitud POST aquí mismo. Déjame ver. Así que para los componentes del servidor, todo está en el servidor. Y acabamos de terminar cómo se hacen las cosas en el lado del cliente, ¿verdad? Pero ahora queremos discutir cómo se hacen las cosas en el lado del servidor. Para los componentes del servidor, todo está en el servidor. Así que el componente y la función del servidor y todo se ejecuta allí. Y luego obtenemos el HTML como una respuesta transmitida. Así que vamos a crear una pequeña aplicación para ver las acciones del servidor en demo. Que es donde, una vez más, vamos a volver a nuestro código y crear una nueva carpeta aquí mismo. Se llamará Hello Server Actions ya que estamos conociéndolos. Una vez más queremos cd.., cd en hello server actions y ejecutar npm install. Y veamos qué tenemos en la tienda aquí. Crearemos un formulario interactivo completo del lado del servidor usando HTML que funciona incluso si JavaScript está deshabilitado. Sí, eso es correcto. Lo tenemos aquí mismo. Es solo un formulario regular de HTML donde tenemos una acción de handleSubmit y tenemos dos entradas diferentes y un botón de Enviar. No puede ser más simple que eso, ¿verdad? Una vez que llamamos al handleSubmit, vamos a llamar a esta función asíncrona helloSubmit que va a tomar los data del formulario, mira esto, tiene la directiva del servidor de usuarios, y luego obtenemos los data, los formamos en un objeto, y simplemente los registramos en la consola. No hacemos ninguna operación de DB aquí, pero podrías si quisieras.

Ahora, esto funciona incluso si JavaScript está deshabilitado porque todo esto está sucediendo en el formulario del lado del cliente justo aquí. De hecho, podemos probarlo. Para mostrar si un proceso de envío de formulario o no permitir que el usuario siga haciendo clic en el botón del formulario mientras se está procesando, podemos mostrar el estado del formulario o deshabilitar el botón mientras se está realizando una solicitud. Para hacer eso, vamos a otra página y creamos el mismo formulario aquí. Tenemos el interactivo y tenemos el normal, ¿verdad? En este caso, queremos ir a, veamos el normal, aquí tenemos el estado de carga, como puedes notar, creamos un formulario con dos campos de entrada y un botón de envío. Y cuando se envía el formulario, se llamará al botón de manejo. Podemos usar los estados o usar los data del formulario para obtener los valores del formulario como hacemos aquí, y eso es todo. Ejemplo similar al que tuvimos antes, pero ahora estamos modificando los estados de carga así como los estados de error y el estado deshabilitado, ¿verdad? Para estos, por supuesto, tenemos que usar el estado. Y por supuesto, tenemos que hacer el componente, el componente use client en ese caso. Esto, por supuesto, no funcionaría si deshabilitamos JavaScript, ¿verdad? Porque no sería capaz de obtener todos estos valores, estados de carga y más. Y finalmente, tenemos el tercer ejemplo, que es el ejemplo interactivo aquí mismo. Y creo que me perdí de mostrar la acción TS aquí mismo en el normal donde simplemente enviamos el formulario, que es una acción del servidor que envía el formulario aquí mismo. Profundicemos un poco más en esto, Sujata. ¿Cómo explicarías la forma en que lo estamos usando aquí, el handle submit? Sí. ¿Podrías volver al archivo de la página principal? Por supuesto. Sí. Aquí, si te das cuenta, no estamos haciendo ningún tipo de cosas del lado del servidor o, lo siento, del cliente. Es puramente un formulario del lado del servidor. E incluso si deshabilitas JavaScript, debería funcionar. Sí, podemos probarlo, ¿verdad? Sí, podemos probarlo. Sí. Solo para mostrarlo, creo que este es un muy buen ejemplo para explicar cómo funcionan las cosas del lado del cliente y del servidor. Así que si vas aquí mismo, y si solo vamos a inspeccionar, creo que deberíamos poder simplemente probarlo y enviarlo. Así que hagamos esto, creo que estamos cons logging it. Ahí vamos. Podemos verlo aquí mismo. Lo que podría hacer es que también podría deshabilitar JavaScript. Creo que tengo que ir aquí, ¿verdad? Sujata, ¿sabes dónde está? Sí, preferencias. Aquí, si te desplazas hacia abajo, debería haber una opción para deshabilitar JavaScript. Sí, no uso eso demasiado. Déjame pasar por eso. Creo que debería estar en algún lugar aquí. ¿Está todo el camino hacia abajo? Sí, todo el camino hacia abajo. Vale, ahí vamos. Y luego deshabilita JavaScript. Ahí vamos. No uso esto muy a menudo. Creo que ninguno de ustedes tal vez lo hace. O tal vez tu jefe te ha hecho probar tus aplicaciones web, incluso si JavaScript está deshabilitado, lo cual no sucede a menudo hoy en día. Pero aún así, es bueno comprobarlo. Si lo hago, no creo que tenga que recargar. Pero puedo, supongo. Así que si recargo, JavaScript está definitivamente deshabilitado. Y ahora puedo hacer una prueba. Y deberías poder ver que se procesa normalmente, incluso sin JavaScript. Ahora, por otro lado, si vamos a la segunda página, que es la normal aquí, así que eso va a ser normal, la forma en que estamos acostumbrados a hacer las cosas ahora. Aquí, deberíamos tener algunos estados deshabilitados y estados de carga también. Y si hago lo mismo una vez más, vemos que se está enviando, lo cual es bastante genial. Y no podemos volver a hacer clic en él si lo está enviando. Algo genial, ¿verdad, como interactividad? Pero si deshabilito JavaScript, no creo que haya hecho demasiado. Comprobémoslo una vez más. Sí, no hizo nada. No lo envió porque no puede sin JavaScript. No sabe si este botón está deshabilitado o no. Y no puede llamar a esto aquí mismo, que es handle submit sin JavaScript porque está usando estados, por supuesto, en este caso. Lo que podemos hacer es, oh, tienes razón. También podemos volver atrás y puedo comprobar el código del lado del cliente aquí mismo también porque estamos en el lado del cliente después de todo. Si vuelvo aquí, y si voy a Next.js, si voy a forward slash normal, y si abro el elemento de inspección aquí mismo, voy a la consola, y hago esto. No, nada. Y luego incluso si vamos a nuestro, una vez más, tengo que deshabilitar aquí también, preferencias, deshabilitar JavaScript. No estoy seguro si tengo que recargar. Solo voy a hacer eso de todos modos para estar seguro. Y si ahora lo escribo, no, absolutamente nada está sucediendo. No obtenemos absolutamente nada en la consola del cliente también. Así que simplemente detiene el funcionamiento de nuestra aplicación. Ahora quiero también- Sí, hay una razón para eso. Sí. Solo para aclarar la pregunta, es porque estamos usando ese console log del lado del servidor. Así que nunca irá al lado del cliente. Eso es correcto. Está sucediendo aquí mismo. Y luego usamos el handle submit, y usamos el submit form. Y el submit form está usando la directiva use server. Así que esa es la razón, intentamos enviarlo al servidor. Esa es la idea. Y esto entonces lo impide de suceder, y esto lo impedirá de mostrarse en el lado del cliente. Por otro lado, estamos llegando al último ejemplo, que es la aplicación interactiva aquí mismo. Así que estamos bajo server actions app interactive, donde tenemos una página aquí mismo. Vamos a explicarlo. Así que esta es una demostración de cómo hacer la carga y el manejo de errores con acciones del servidor dentro de un formulario. Tenemos una funció

O más bien usando el estado del formulario proveniente de React DOM, que está pendiente. Y luego si está pendiente, está deshabilitado, y en base a eso, podemos establecer el envío o está enviando. Así que estamos usando un componente del cliente dentro de un archivo del servidor, que es un formulario, y este formulario está usando la directiva del usuario para enviarlo de vuelta al formulario. ¿Hay algo que te gustaría agregar con este ejemplo, Sujata?

Sí, solo hablaría un poco sobre ese botón de componente personalizado. El estado del formulario que estamos viendo allí es un nuevo tipo de libro proporcionado por React básicamente, que sigue las pistas del último formulario que estás enviando. Y dependiendo de eso, muestra el estado, si el formulario ha sido enviado, exitoso, sin éxito y todo. Y lo obtenemos por ese pendiente que estamos usando dentro de ese archivo de botón. Muy genial. Pero incluso si no lo usáramos, podríamos simplemente establecer un campo de estado de uso, ¿verdad? ¿O en ese caso, tendríamos que convertir nuestro formulario en un formulario del lado del cliente real, verdad?

Sí. Y eso es lo que hicimos con la ruta normal, o la página normal. Y luego no funcionó sin JavaScript. Sí, podemos probar esto ahora. Mientras que en este caso, usando el React dom, usando el estado del formulario aquí, si nosotros volvemos a nuestra aplicación actual, déjame abrirlo aquí mismo. Y si vamos a, creo que es interactivo, mismo formulario, ¿verdad? Pero ahora si lo ingresamos, y si lo hago así, enviando, vimos el estado, ¿verdad? Viste el estado. Y si volvemos aquí a nuestro código, puedes ver que realmente lo envió, nada loco, ¿verdad? Pero si voy aquí, y si vamos a nuestras preferencias y desactivamos JavaScript aquí, ahí vamos. Recarga la página, y luego prueba desactivado. Digamos, disabledjs.gmail.com. Y si hago clic en enviar. Vale. No ves el estado de carga, pero lo que sí vemos aquí es el nuevo mensaje. Así que incluso con el deshabilitado, lo pasamos a nuestro servidor. Esa es la idea. Y así es como podemos usar todos estos diferentes estados de React, y cómo podemos usar los componentes del servidor. ¿Vale? De manera similar, podemos hacer cosas similares con la gestión de errores, ¿verdad? Estamos usando otro gancho especial del formulario de React llamado estado del formulario de uso, que es lo que hemos visto aquí mismo. No es solo para estados dependientes. Nos permite manejar la gestión de errores también. Puedo sacar rápidamente nuestro formulario de uso aquí mismo, proveniente de los documentos oficiales de React. Puedes ver eso, creo, no estoy seguro si está listo todavía. No, no lo está. Puedes ver que todavía está en proceso de llegar allí, pero nos permite, muy pronto lo verás en toda la página, ¿verdad? Nos permite obtener el estado y la última acción del formulario de ese gancho específico, y luego podemos usarlo, o del formulario, lo siento, y luego podemos usarlo y basándonos en él, podemos hacer algunos cambios futuros aquí mismo. ¿Vale? Creo que eso es más o menos todo cuando se trata de este ejemplo de acciones del servidor. Déjame ver rápidamente. Hemos usado solo un pequeño ejemplo aquí, pero es una característica tan poderosa, y eres absolutamente libre de hacer cualquier tipo de escenarios complejos usando estas acciones del servidor. Para mostrarte lo que quiero decir, déjame abrir el repositorio de mi curso de Next.js. En este curso, cubrimos consultas, y mutaciones complejas, y muchas otras cosas. Este es el repositorio que tengo aquí mismo. Déjame abrirlo aquí mismo, para que puedas verlo. Aquí vamos. Vamos a donde estamos llamando a estas acciones del servidor. Creo que puedo presionar el punto, y lo abrirá directamente en nuestro editor aquí mismo. De esa manera, podremos ver más fácilmente qué está pasando. Nos adentramos en tareas y recomendaciones de búsqueda, o realizamos búsquedas globales. Muchas cosas estarán sucediendo aquí. Vamos a sumergirnos en nuestras acciones de lib, y puedes ver que para todos estos diferentes tipos de acciones, he creado una nueva página, y usamos la directiva del servidor de uso en la parte superior. Este es un ejemplo de producción de una forma adecuada de usar acciones del servidor. Estas son acciones del servidor bastante pesadas. Como puedes ver, llamamos a la función exportAsync crear servidor. Nos conectamos a nuestra base de datos, porque es una arquitectura sin servidor. Obtenemos los parámetros. Hacemos una modificación a la base de datos, y luego revalidamos la ruta. Estamos usando un par de conceptos que discutimos hasta ahora. Cosas bastante geniales. La forma en que lo usamos, por supuesto, es veamos dónde, crear respuesta. Lo llamamos aquí mismo. Dentro del archivo de respuesta, que convenientemente en este caso, es un componente de uso del cliente, pero podemos llamar a la respuesta de creación, o obtener respuesta, o cualquier otra acción del servidor asíncrona que hayamos creado. Ese es el poder de estas acciones del servidor. Ahora, volviendo rápidamente a nuestra base de código, o a nuestras diapositivas aquí mismo, cosas bastante geniales lo que Next.js nos permite hacer con esas. Hubo un par de preocupaciones o problemas sobre el uso de acciones del servidor. Afortunadamente, las acciones del servidor, en primer lugar, la primera preocupación era que no eran estables, pero luego se volvieron estables a partir de Next.js 14. Hay un par de cosas. Déjame ver dónde estoy bien con las diapositivas. Este meme fue el meme más grande de la conferencia Next.js 14. Estaba en tendencia en todo Twitter y Reddit, donde tenemos una función de marcador que devuelve un botón, y dentro de un botón, usamos una acción de formulario que llama a SQL directamente dentro de él, directamente dentro del código del lado del cliente. Algunas personas se confundieron, pensando que SQL ahora está directamente dentro de JSX. Algunos incluso recordaron sus días de PHP y comenzaron a burlarse de él. Como mencioné anteriormente, no es código real que está dentro del componente, incluso si parece que lo está. Next.js lo convertirá en una solicitud POST detrás de escena. Cuando se trata de seguridad, puedes usar cualquier cosa dentro de una acción del servidor para verificar la entrada primero antes de hacer operaciones de DB reales. Aquí tengo un ejemplo incluso de hacer eso. Estamos haciendo un ejemplo donde verificamos el esquema del nombre y el correo electrónico, y solo si validamos los campos y si son seguros para analizar, solo entonces podemos hacer cualquier llamada, ¿verdad? Así que todavía puedes hacerlos seguros. También puedes agregar tantas medidas de seguridad como quieras para hacerlo seguro. Está completamente en tus manos. Y mientras que las acciones del servidor podrían ser algo genial para probar, y lo son, también hay algunas desventajas. En primer lugar, no puedes usar acciones del servidor para el desarrollo multiplataforma, donde necesitas el mismo back end o la misma API en diferentes ecosistemas, como móviles o escritorios. Los puntos finales de las acciones del servidor no pueden exponerse por ahora. Así que no es como si estuvieras creando diferentes puntos finales de API que puedes reutilizar en diferentes aplicaciones de front-end. Las acciones del servidor también pueden usarse para escenarios como webhooks o sockets, porque en estos casos necesitas un servidor siempre escuchando actualizaciones de eventos, que las acciones del servidor no admiten ya que son una parte integral del servidor y no están expuestas. Además, probar podría sentirse desafiante con las acciones del servidor porque no puedes usar herramientas como Hostman y probar tiene que hacerse directamente. Por el lado positivo, mejora la seguridad ya que tu API no está expuest

Pero antes de continuar, quiero darles un poco más de tiempo para hacer una pausa. Así que vamos a hacer una pausa de nuevo durante unos 10 minutos, de 5 a 10 minutos, y luego volveremos para terminar con Edge y Node Runtimes.

Solo una breve introducción. No quiero profundizar demasiado en ello porque sé que es imposible para ustedes mantener su entusiasmo, en primer lugar, si tenían alguno al principio, pero para mantener su enfoque durante dos a tres horas. Estas masterclasses son geniales, especialmente si se extienden durante todo el día. Pero así, es muy difícil asimilar todo, por eso, de nuevo, quiero enfatizar el punto de revisar estos ejemplos y revisar la presentación también.

Así que voy a compartir con ustedes, muy probablemente, un enlace a Figma a toda esta presentación que pueden visitar más tarde. Vamos a hablar sobre Edge versus Node Runtimes. Así que solo se trata de averiguar, una vez que hacemos ping a nuestros servidores, a qué servidor vamos a hacer ping, qué tan lejos de nosotros está y cuánto tiempo tardará la respuesta.

Es agradable verlos a todos ustedes. Los veo también en las cámaras ahora. Y me alegra que estén de vuelta conmigo ahora. ¿Todos me escuchan bien? ¿Listos para escuchar, listos para continuar? Sí, señor. Increíble. Increíble. Genial, chicos. Así que después de dos horas y media, chicos, pensé que esto iba a llevar un poco menos, pero ustedes están todavía aquí. Una vez más, ahora que reviso este material, es casi como si fuera incomprensible en una sola sesión. Así que me disculpo de antemano y ahora por llenarlo de tanta información, pero solo quería poner todo aquí. Puedo enviarles la presentación. También puedo enviarles los ejemplos. Así que pueden revisarlos más tarde y hacer preguntas desde Discord. Así que solo quería proporcionar tanto como fuera posible aquí.

Dicho esto, quiero hablar sobre edge versus node run times en Next.js. Pero específicamente aquí, quiero profundizar en otro ejemplo de código. Así que lo que podemos hacer aquí es que voy a proporcionarles otra pequeña carpeta, que podemos abrir aquí mismo. Ahí vamos. Se llama hello-edge y podemos, una vez más, sumergirnos en ella haciendo cd en hello-edge y ejecutando npm install. O tal vez sé que Yarn es más popular hoy en día. Podría pasar a Yarn muy pronto. Pero veamos qué tenemos aquí. Tenemos una página y esta página es solo una página típica de Next.js. No la cambié demasiado. Pero en lo que podemos profundizar más es en la carpeta API. Así que ahora no estamos hablando de acciones del servidor. Estamos hablando de los puntos finales de la API de Next.js y la forma de exponerlos. Y puedo ver a Aquiles diciendo que es bueno escuchar sobre todas estas cosas diferentes. Y ahora podemos elegir en qué temas queremos profundizar, lo cual es bueno. Me alegra mucho que lo veas de esa manera. Veamos el nodo aquí mismo. Esta es una ruta de API típica, route.js bajo una carpeta específica, donde importamos la respuesta de Next.js creamos una función de exportación asíncrona get, y luego retrasamos deliberadamente la respuesta por un segundo. Ese es el primer ejemplo. El segundo es obtenerlo del ejemplo de edge. De nuevo, exactamente lo mismo. Pero lo único que tienes que hacer es exportar const runtime edge. Una vez más, Next.js hace que sea tan interesante y tan simple modificar un factor tan grande como este, como cambiar el runtime, simplemente ejecutando export const runtime, y luego modificar lo. Vale. Y luego finalmente, tenemos un nodo dinámico, en el que vamos a profundizar más. De nuevo, solo otra pequeña bandera que añades old force dynamic en la bandera dinámica aquí mismo. Así que ahora definitivamente querríamos desplegar esta aplicación. Déjame ver si puedo sacar rápidamente una foto de un despliegue de esta aplicación. Creo que puedo conseguirlo aquí mismo. Ahí vamos. Deberías poder verlo si puedo arrastrar y soltar rápidamente. Ahí vamos. Así es, si despliegas tu aplicación, así es como se verá en Vercel. Puedes ver que tenemos Next.js, puedes ver los activos estáticos aquí mismo, y puedes ver diferentes funciones. Específicamente, si tu API se despliega en edge, vas a obtener esta marca de edge, este icono de edge aquí mismo. Vale. Ahora, no expliqué nada sobre por qué podríamos querer usar diferentes tiempos de ejecución y cómo funcionan realmente. Así que vamos a profundizar un poco más en eso. Lo que podría querer hacer es, déjame primero sacar mi presentación aquí mismo, y luego sumergirme en eso directamente desde el ejemplo. Hablamos de muchas estrategias de renderizado, ¿verdad? Hablamos de estático, dinámico. También tuvimos los entornos, el servidor, el cliente, el nodo, el borde, muchas cosas estaban sucediendo durante estas dos horas y media, tres horas. Y muchas cosas están sucediendo en Next.js también. Pero específicamente, podemos ver que cuando hablamos de tiempos de ejecución, tienen algo que ver con el servidor. ¿Dónde está apuntando este servidor? ¿Está apuntando a node o está apuntando a edge? Y déjame contarte un poco más sobre ambos.

En este caso, el tiempo de ejecución de Edge es como tener una mini computadora cerca de donde estás o donde están tus dispositivos. Así que en lugar de hacer todo en una computadora grande y lejana, hace algunas tareas cerca. Esto hace que las cosas sean más rápidas

Y luego la dependencia de la red. Dado que los runtimes de Edge están distribuidos globalmente, dependen de las condiciones de la red y pueden surgir problemas en las interrupciones de la red. Mientras que las limitaciones del runtime de Node runtime son posibles arranques en frío porque las implementaciones serverless de Node.js pueden tener tiempos de arranque en frío, causando un ligero retraso cuando una función es invocada por primera vez. El consumo de recursos, donde Node.js es un consumo de recursos ligero, todavía puede ser una consideración, especialmente en escenarios con recursos limitados. Y finalmente, menos ideal para ultra baja latencia. Donde necesitas ultra baja latencia, la naturaleza centralizada del runtime de Node.js puede introducir algo de latencia en comparación con los runtimes de Edge. Así que lo hemos descubierto. Ambos tienen sus ventajas y desventajas. Y si tengo que sugerir algo, entonces sugeriría hacer cosas dependiendo de tus necesidades. Vercel, que ha construido su propio runtime de Edge, comparte una agradable diferencia entre todas estas características y qué características soportan Edge y Node en las aplicaciones de Next.js. Así que aquí podemos ver que de nuevo, tienes que averiguarlo por tu cuenta, dependiendo de qué características necesitas. ¿Estás preocupado por la security? Entonces podrías querer usar la seguridad exterior alta en los entornos de Edge. ¿Estás preocupado por la latencia? Entonces y si necesitas realmente baja latencia, puedes obtener baja latencia en Edge. Pero por otro lado, si miramos, digamos, los paquetes de NPM, todos son soportados aquí, pero sólo un subconjunto más pequeño de ellos es soportado en Edge. Así que depende de lo que necesites. Y también el renderizado estático no es soportado en Edge, mientras que sí lo es en el entorno de Node. Una vez más, depende exactamente de lo que necesites. Así que entendamos qué son las funciones de Edge y serverless y cuándo usarlas. Una función de Edge es un fragmento de código que se ejecuta en el servidor en el borde de la red, más cerca del usuario. Es inteligente y responde rápidamente. Hace el trabajo cerca de ti, haciendo las cosas más rápidas. Y especialmente para aplicaciones que necesitan acciones inmediatas como manejar solicitudes de sitios web o gestionar data de dispositivos cercanos. Hay muchas cosas sucediendo aquí mismo. Y una vez más, puedes comparar las funciones de Edge con las funciones serverless, de manera similar a cómo comparamos los runtimes juntos. Y muchos de ustedes que trabajan con AWS pueden comparar esto con las funciones Lambda también, ya que también son serverless. Es una consideración completamente válida para hacer y una comparación para hacer también. No quiero profundizar demasiado en esto. Tendrás las diapositivas. Vamos a proporcionar muy probablemente el guión también y mucha información diferente sobre esto. Así que definitivamente es algo que puedes leer más en las diapositivas aquí mismo. Sé que nos estamos acercando a las tres horas ya, y no quiero tomar las tres horas completas y tal vez más que eso, si nos sumergimos demasiado en todo esto. Espero que estés bien con que yo haga eso. Pero una vez más, ambos tienen sus propios beneficios y ventajas y desventajas. Tienes que pensar en lo que exactamente necesitas, ¿verdad? Siguiendo adelante, tenemos que entender cómo podemos cambiar el runtime en Next.js. Déjame ver si puedo hacer eso aquí. Ya lo vimos, en un ejemplo rápido. Es sólo cuestión de cambiar esa exportación const runtime, lo que me lleva de vuelta a mi ejemplo que hemos visto previamente, que está funcionando aquí mismo. Si puedo sacarlo, ahí vamos, por qué decidiríamos usar cuál y cómo podemos notar las diferencias? Si puedo sacar rápidamente una respuesta o solicitud de postman que he hecho, podemos verla aquí mismo. Ahí vamos. Podemos ver que si hacemos un hola desde el runtime de Node, tardó unos 2.76 segundos en devolvernos los data. Si revisamos el mismo ejemplo llamando a la misma función que tenemos en nuestro ejemplo desde el runtime de Edge, va a tomar, hagan sus apuestas ahora si quieren, pero va a tomar unos 1.8 segundos, que es un segundo menos, que es una gran diferencia que tenemos aquí mismo. ¿Qué más podríamos cubrir aquí mismo? Déjame ver. En este caso, se prefiere Edge, por supuesto, si funciona con todos los demás parámetros que quieres que tenga tu aplicación porque está ubicado en un servidor que está cerca de mí. Eso es. Por otro lado, el runtime de Node que hemos visto aquí mismo, que tarda 2.7 segundos está ubicado en un servidor utilizado por Vercel en el despliegue, que podría estar lejos en comparación con el otro runtime de Edge. Eso está bien. Vamos a abrir rápidamente esto aquí mismo. Volver a la presentación. La pregunta es, ¿deberíamos usar Edge sobre Node? Lo hace obvio. Va a tomar un segundo menos. La respuesta a esa pregunta no es en absoluto. Edge también tiene sus propias limitaciones. Estas incluyen rápido, pero no infinito. Las funciones de Edge necesitan responder inicialmente en 25 segundos. Son como ayudantes rápidos, pero no pueden tardar para siempre en hacer su trabajo. En este caso, tarda más de 25 segundos. Van a expirar. Tienes que vigilar el tamaño porque estas funciones pueden manejar hasta 4 megabytes de data, incluyendo todo el código. Es como tener una mochila pequeña, mete lo que necesitas, pero no todo. También, ten en cuenta la distancia. Si tu fuente de data está lejos de donde funciona la función de Edge, podría tardar un poco más. Es como pedirle a un amigo que haga algo, pero primero necesita viajar un poco. Puedes ajustar la configuración para reducir ese tiempo de viaje. Finalmente, no todos los trucos están permitidos. Algunos trucos geniales como los que sabe JavaScript, las funciones de Edge podrían no saber. Es como tener una caja de herramientas especial donde no están todas las herramientas. Puedes revisar una lista de herramientas que discutimos antes. Alguna funcionalidad limitada de la API. Veamos. Eso está claro. De nuevo, ¿cuándo deberíamos considerar usar Edge sobre el runtime de Node? Esa es una pregunta. Una vez más, volvemos a que depende. Depende de lo que necesites. Aquí hay algunas preguntas que me hago a mí mismo. ¿Cuál es la naturaleza de tu característica? ¿Es una tarea sensible a la latencia? Si no lo es, simplemente usa un runtime de Node.js o funciones serverless. Funciona igual de bien. Si es una tarea sensible a la latencia, ¿está cruzando las limitaciones de Edge? ¿Necesitas usar algunas APIs a las que las funciones de Edge no tienen acceso? Si es así, entonces vuelve a usar el runtime de Node.js. Si no es así, usa el runtime de Edge o las funciones de Edge. Siempre recuerda revisar el caso de uso específico dependiendo de las restricciones y dependiendo de lo que quieras hacer para tomar una decisión de desarrollo informada. Aquí hay algunos ejemplos de casos de uso de runtimes de Edge. Quiero preguntarte, tal vez. Déjame hacer eso primero. ¿Tienes un ejemplo de dónde podrías querer usar runtimes de Edge en lugar de Node? Un ejemplo son... Sí. La mensajería instantánea es un gran ejemplo. Creo que la misma idea son las notificaciones o los mensajes en vivo. Eso es realmente genial. Las funciones de Edge pueden ser utilizadas para empujar notificaciones en tiempo real o mensajes basados en su ubicación proporcionando actualizaciones instantáneas sin depender de servidores centralizados.

Genial. Gran trabajo. También authentication y autorización. El manejo de la autenticación de usuario en Edge puede reducir la latencia en los procesos de inicio de sesión, mejorando la experiencia de inicio de sesión, que tenemos que hacer tan a menudo. Y también los servicios de geolocalización de los que hablamos aquí. Implementación de servicios basados en ubicación como el seguimiento de geolocalización o recomendaciones locales procesando los datos de ubicación data en Edge. Y hay muchos casos de uso similares. Las Edge functions también se utilizan a menudo en las CDN para entregar contenido web como imágenes, video, scripts desde servidores más cercanos a los usuarios. CDN, ¿verdad? Ahora que hablas de ello, es bastante similar a lo que hemos estado explicando o describiendo las Edge functions. Esto reduce los tiempos de carga de los sitios web, mejorando la experiencia general del user experience. Eso es algo que ya aprendimos. Eso es todo. Runtimes de Edge versus Node, funciones de Edge versus serverless, cuándo usarlos, cómo usarlos, y todo lo demás. Y Halil, veo que tienes una pregunta más, y es, ¿cómo podemos habilitar Edge? Y tu pregunta es totalmente correcta. Simplemente añadimos runtime Edge, donde estás llamando a esa solicitud. Y eso es todo. Eso hace inmediatamente que tu llamada se base en los puntos finales de Edge aquí mismo. Export const runtime es Edge, y simplemente funciona de inmediato. Una cosa más de la que quiero hablar es que ahora que estamos en la parte final de esta masterclass, espero que hayas adquirido mucho conocimiento y al menos una pequeña parte de lo que estabas buscando. Usar todas estas características que hemos aprendido es increíble. Pero si la gente no lo ve, entonces no hay necesidad de usar esas características después de todo. Es algo típico que el desarrollo a veces es la parte fácil, pero el marketing es la difícil, ¿verdad? Construimos estos sitios web para que la gente los use. Así que es nuestra responsabilidad encontrar una solución de una manera que nos va a dar mucho tráfico en nuestro sitio y hacerlo notorio en un mar de diferentes sitios web en línea, ¿verdad? Y hay muchas formas de hacer eso a través de la forma no desarrolladora, es decir, que tu empresa o tus equipos pueden crear anuncios, memes divertidos, o mucho contenido social y mantenerse activos en todos ellos. Pero este es un tráfico no orgánico, lo que significa que tienes que pagar para obtener algo de tráfico. Por otro lado, el tráfico orgánico es lo que nosotros como desarrolladores podemos hacer dentro de nuestro código donde los rastreadores podrán indexarlos correctamente en los motores de búsqueda. Y creo que puedes ver hacia dónde voy con esto. El último tema de la masterclass de hoy es SEO, ¿verdad? ¿Cómo podemos impresionar a diferentes gatos exigentes aquí para visitar tu sitio web? Bueno, imagina que tu gato es internet, y sólo presta atención a los juguetes más brillantes, más interesantes, que son los sitios web. Así que si SEO es tu forma de hacer de tu sitio web el juguete de gato más cool y brillante de la sala, podemos usar los trucos correctos, que son las palabras clave, organizar las cosas de manera ordenada en la estructura del sitio y asegurarnos de que tu gato disfruta jugando con él, que es la user experience. Y cuanto mejor hagas esto, más tu gato o el motor de búsqueda mostrará tus juguetes impresionantes a otros usuarios, resultando en más personas que lo usan. Por supuesto, este es un tema completo y una masterclass por sí misma, y no necesariamente totalmente relacionada con lo que estamos hablando, que es Next.js, pero hay muchas formas de cómo podemos trabajar con esos en Next.js. Así que sólo quiero repasar rápidamente esto. Puedes mejorar SEO mejorando las palabras clave, ¿verdad? Asegurándote de que están etiquetadas correctamente y rastreadas por los sitios web. Puedes mejorar la calidad del contenido de tus sitios web creando imanes de alta calidad para los usuarios. También puedes escribir mejores meta tags en tus sitios web, o mejorar la estructura de tu sitio web también. Eso ayuda con SEO también. Una estructura bien organizada ayuda bastante. Puedes mejorar la velocidad de tu sitio, que es otra cosa, para tener carriles exprés para visitar tu sitio web, porque los usuarios no quieren esperar más. Se ha demostrado que Google clasifica los sitios web con tiempos de velocidad más altos o tiempos de carga, más altos en la lista que otros. Backlinks también. Necesitamos poner muchos backlinks y necesitamos limpiar nuestras URLs, pero hay muchas cosas que hemos aprendido hasta ahora. Pero, ¿cómo podemos realmente añadir esos metadatos a nuestra aplicación? Eso es algo que queremos discutir más a fondo en Next.js específicamente, ¿verdad? Quiero saltarme esta parte. Puedes leerlo más tarde. La mayoría de ustedes saben qué es SEO y qué pueden hacer, pero ¿cómo podemos hacer esto en Next.js? Hay dos formas. Podemos hacerlo usando la configuración, o vamos a profundizar un poco en la parte de configuración. Podemos hacerlo creando tanto objetos de metadatos estáticos como dinámicos usando la API de metadatos de Next.js. Podemos hacerlo estáticamente, así, donde simplemente podemos escribir export const metadata js mastery, y luego escribir una descripción y eso se añadirá a los metadatos de tu sitio. Es estático. Cualquier contenido dentro del título aquí se añadirá a la etiqueta de título HTML y la descripción se convertirá en la etiqueta meta. Así que la salida anterior simplemente devolverá esto. Título en el meta con la descripción. Una forma bastante cool y fácil de añadir metadatos. También tenemos metadatos dinámicos. Si hay sitios web generados dinámicamente o rutas dinámicas que queremos que los motores de búsqueda indexen, que es una buena práctica, podemos usar la función generate metadata de Next.js para producir metadatos específicamente adaptados a estas páginas. Por ejemplo, para mostrarte, he implementado esta estrategia en el sitio web de JavaScript master para recursos, donde alojamos diferentes recursos de los que la gente puede aprender. Puedes ver diferentes títulos y descripciones. Si haces clic en uno de estos recurso

Permíteme revisar rápidamente los comentarios. Sí. Entonces, Jada compartió muy convenientemente el repositorio de GitHub también. Así que en este repositorio de GitHub, podemos repasar todos los ejemplos muy bien. Lo vamos a vincular a Discord también, para que puedas reabrirlos, probarlos. Los ejemplos son increíblemente mínimos, lo que debería permitirte tomar lo que necesitas e implementarlos en tus propios proyectos.

Sobre este tema, quiero agradecer también a Sujata por estar aquí, respondiendo algunas preguntas. Quería tenerla. Ella es parte de un equipo, y pudo responder algunas de tus preguntas en el chat así como unirse a la llamada. Así que sí. Muchas gracias también a Sujata. Sí, Simon, buscaremos la forma de proporcionarte las diapositivas también. Podrían ser un par de gigabytes incluso cuando están comprimidas porque hay muchas diapositivas, pero podríamos compartir un enlace de Figma a esas diapositivas también en Discord. Cada pedazo de información que pueda conseguir para ustedes, lo prepararé, y lo dejaré en este enlace en Discord. Solo para no perderlo, quiero copiarlo, y lo voy a dejar aquí mismo. Déjame ver. Ahí vamos. Lo voy a pegar en el chat aquí mismo. Así que una vez más, si alguien no puede encontrarlo, lo tienes. Permíteme ir a tus comentarios. Puedo ver muchas palabras geniales, la gente dice que les gusta la masterclass. Estoy muy contento de escuchar eso. Quiero agradecerte, no a mí por hacer esto, sino a ti por estar aquí y realmente dedicar tres horas de tu viernes hoy para estar conmigo y aprender sobre Next.js. Espero ver algunos sitios web geniales y fenomenales que vas a crear con Next.js. No sitios web, aplicaciones web dedicadas completas para el caso. Muchas gracias por las amables palabras.

Sobre el tema de un poco de quiénes somos y qué hacemos, si no lo sabes, puedo compartir quizás un poco más sobre eso. Creo que lo tenemos aquí. Empezamos a hacer Next.js hace mucho tiempo, desde el 13 o 12, estamos en alfa, llegan nuevas características. De hecho, he creado un curso sobre el tema también. Está en jsmastery.pro, justo aquí. Intentamos hacerlo solo en el mejor curso de Next.js que hay. Al igual que con la masterclass, nos adentramos profundamente en algunas partes y lo hacemos en un ejemplo también. La premisa del curso, y esto no es solo yo vendiéndolo, esto es yo extendiendo la masterclass también y hablando sobre la idea y el proceso de creación del curso. La idea era modificar completamente tu mentalidad para escribir código de Next.js porque Next.js 12 y antes es completamente diferente de Next.js 13 y 14. ¿Por qué? Porque no es solo como escribir el buen viejo código de React. Aportó muchas diferencias a la forma en que escribimos React con estos errores de hidratación, el uso del servidor, las acciones del servidor, los datos obsoletos, la obtención de datos en diferentes partes, edge versus no runtimes, importaciones dinámicas. No puedes simplemente saltar a ello como si estuvieras usando React. Eso es lo que hicimos, de hecho. Construí toda nuestra plataforma de cursos, nuestras páginas de destino y todo, y terminamos convirtiéndolo en un lío del lado del cliente. Pero ahora, afortunadamente, hemos aprendido cómo hacerlo y si te dedicas a este enfoque, puedes tener un rendimiento fenomenal debido a todos los beneficios que proporciona. Si estás interesado, en el curso, nos adentramos en deep dive en todas estas conferencias con grandes diapositivas, similares a las que has visto. Nos adentramos en la construcción y despliegue de una aplicación de stack overflow, que vamos a construir desde cero para poder internalizar esos procesos, y luego lecciones activas que te permiten realmente asegurarte de que no solo sigues, sino que realmente construyes en la práctica basándote en las tareas que te damos, por ejemplo, creando el filtrado, o la búsqueda capacidades y mucho más, todo mientras construyes esta aplicación de stack overflow. Queríamos hacer algo que fuera bastante interesante, donde tienes operaciones CRUD, tienes seguimiento, gustos, comentarios, comentarios anidados, chat GPT, respuestas generadas por IA, lo que sea, está ahí. Está pasando bastante. Pero por otro lado, durante mucho tiempo, solo hemos estado haciendo YouTube. Durante unos cinco años o incluso más, he estado produciendo solo contenido educativo gratuito en YouTube. Permíteme salir de esto, para no tener ningún audio sucediendo. Lo hacemos durante mucho tiempo. Cada dos semanas, lanzamos un nuevo video, y la mayoría de los recientes han sido exactamente sobre Next 13 y 14. Por ejemplo, construyendo aplicaciones de E-commerce, usando acciones de servidor, este es un gran video que hemos creado específicamente sobre acciones de servidor, portafolio, aplicaciones sociales, lo que sea está ahí. Eso es lo que hemos estado haciendo durante los últimos cinco años. Nos adentramos en Next.js como si las acciones del servidor todavía estuvieran en alfa, y tratamos de pasar por el proceso de prueba y error de averiguarlo por nuestra cuenta. Nuestro curso completo de Next.js es uno de los cursos de Next.js de más rápido crecimiento en YouTube en este momento, y siéntete libre de consumirlo, pero más que eso, quiero invitarte a usar ese servidor de Discord que te mostré, el foro, para hacer cualquier pregunta, y yo y Sujata te responderemos directamente si podemos ayudarte de alguna otra manera. Recientemente, también hemos comenzado un programa de bootcamp llamado la Experiencia de Masterclass de JSM, donde realmente tratamos de ayudar a las personas a pasar de posiciones junior a intermedias o senior. No estoy seguro de dónde estás ahora en tu trayectoria de desarrollador. ¿Te importaría decírmelo? Puedes hacer, digamos, desempleado, junior, intermedio, senior. Puedes escribirlo en los comentarios, solo para averiguar quién estaba escuchando esta masterclass hoy. Interesante. Puedo ver junior, pero luego puedo ver un par de seniors también, jefe de ingeniería también bien, Philippe, eso es genial. Bueno, principalmente senior e intermedio, lo cual es interesante escuchar. Desde tu perspectiva, ¿sabías sobre la mayoría de estas cosas de Next.js, y cómo las encontraste? Permíteme preguntarte, permíteme preguntarte esto. ¿Cómo crees que cambiará el panorama del desarrollo web y el desarrollo de React específicamente ahora que Next.js está introduciendo todas estas características e incorporándolas en la parte superior de React? Si alguien quisiera iniciar la conversación, y tal vez incluso en tu micrófono, especialmente los seniors, ¿cómo crees que cambiará el panorama del desarrollo web? ¿Estás acogiendo estos cambios con los brazos abiertos, o crees que Next.js todavía tiene un largo camino por recorrer? Bueno, puedo ver a algunas personas sugiriendo que empujen a las nuevas características, especialmente cuando se actualiza a React 18. Será masivo. Solo tengo el miedo de estar atado a Vercel. Ese es un punto realmente bueno que muchas otras personas también hacen. Aunque, sabes, eso es bueno, eso es bueno en realidad. Pero sí, Next.js te permite salir de Vercel, pero lo hacen tan conveniente para quedarte con Vercel que necesariamente no quieres moverte, ¿verdad? Pero entiendo tu preocupación. Muchas gracias, chicos, por estar aquí. Veo que algunas personas tienen que irse. Hemos llegado a nuestro límite de tiempo también. Han sido una audiencia fenomenal, pero silenciosa. Espero que hayas podido aprender mucho, y espero verte quizás, no sé, en persona la próxima vez en la conferencia de Git Nation, o una de las conferencias, o te veo en internet. También puedes agregarme en LinkedIn. Estoy feliz de charlar e intercambiar algunos pensamientos también. Pero primero, te veré en Discord en el foro. Podemos mantener la conversación allí. Muchas gracias y que tengas un maravilloso día. Adiós a todos.