Masterclass de Serverless para Desarrolladores de React

Me gustaría comenzar con... así que solo una descripción general para ustedes, el plan es construir un proyecto, un proyecto de código abierto. Este proyecto no me beneficiará a mí ni a mi empresa de ninguna manera. Es solo para aprender juntos. Y es una masterclass. Con masterclass, me refiero a que estamos trabajando, pero también estamos haciendo cosas interactivas. No es como una charla de tres horas en la que apagas tu video y te quedas dormido y luego vuelves al final para decir, wow, buen trabajo. Es decir, está mal nombrado. Es una mentira, eso es lo que dice Wikimedia. Y la presunción es que es una mentira porque en realidad hay servidores. Así que no es sin servidores. Pero en realidad, serverless se llama así porque para ti como desarrollador, es serverless. No eres tú quien administra los servidores. No estás manteniendo los servidores. No estás escalando los servidores. No estás implementando estrategias de conmutación por error para los servidores. Así que para el desarrollador, es serverless en el sentido de que nunca tocas un servidor. En cambio, ¿a qué tienes acceso? Tienes acceso a una API. Literalmente una API, una interfaz de plataforma de aplicaciones, una interfaz hacia el servidor de otra persona. Eso es todo. ¿Cómo se conecta con React? React es un nivel de abstracción sobre el DOM imperativo del navegador, el modelo de objeto del documento. Como React es simplemente un conjunto de funciones que tienen estado y se mapean a elementos en tu navegador. Serverless es similar porque serverless no es más que una abstracción. Los servidores y su complejidad se abstraen. Puedes colocar React como JSX en JavaScript para modelar el DOM. También hay formas de modelar servidores sin tener que lidiar con ellos realmente.

Excelente. Según lo que querías aprender, Matt. Mencionaste que querías aprender estrategias, recetas y libros de cocina sobre cómo construir con serverless. Creo que eso es realmente útil. Porque quería hacer esta masterclass de una manera en la que puedas elegir tu propia aventura. Y generalmente hay dos formas en las que esto puede ir. Necesitaré que prestes atención aquí. Porque esto afectará literalmente toda la masterclass. Obtendrás una masterclass muy diferente si te equivocas. Puede ser... Miramos serverless desde adentro. Así que construimos, mantenemos, aprovisionamos y escalamos servidores. Y así entendemos serverless de esa manera al crear servidores y hacer el trabajo que haría AWS. O utilizamos soluciones serverless existentes y las componemos juntas en una aplicación React. Esta última opción está definitivamente más centrada en React, menos enfocada en la infraestructura del backend. Y en mi opinión, te dará habilidades más transferibles y útiles en el mundo moderno de front-end de React. Porque la forma en que las personas construyen aplicaciones hoy en día es, por ejemplo, si estás construyendo una aplicación React, probablemente te conectarías a Auth0 para la autenticación. Usarías algún tipo de base de datos serverless, como Zada. Compondrías diferentes proveedores serverless. Y luego tendrías tu aplicación React renderizada por el servidor o renderizada de forma serverless en su propia forma. Entonces hay estrategias de renderizado y cosas que React puede hablar que te ayudarían de manera más significativa. El otro enfoque es más información sobre cómo funcionan las cosas. Pero probablemente nunca lo usarás profesionalmente porque hay personas que trabajan en AWS y eso es su trabajo a tiempo completo, ¿de acuerdo? Entonces, si está claro, elige tu propia aventura escribiendo en el chat uno para el serverless detrás de escena y dos para componer cosas serverless en React.

¡Maldición, unánime! Genial, bien. Eso está, bueno, estoy viendo demasiados. Sí. ¿Podrías repetir las opciones, por favor? Es un poco confuso. Sí, no hay problema. La opción uno es usar cosas como Docker y containers y construir nuestro propio, como, una especie de plataforma como servicio para personas con pocos recursos, donde básicamente recreamos AWS para comprender la complejidad de los servidores y su aprovisionamiento, escalado, etc. En comparación, la opción número dos es simplemente construir una aplicación React y componer múltiples soluciones serverless. Aunque lo repetí, siento que la opción dos es, con mucho, la más común y es con la que seguiremos adelante. Excelente.

Para hacer esto, aquí está el proyecto. Una vez más, es altamente colaborativo. Además, creo que este proyecto tiene 16 o más características. Permítanme compartir mi pantalla, en realidad. Y hacer esto... Ahora que tenemos una dirección, vamos a hacer la masterclass completa. Por cierto, siéntanse libres de interrumpir esta masterclass en cualquier momento. Tengo tendencia a hablar mucho porque primero soy orador, segundo instructor de masterclass. Así que si quieres interrumpir, hay una buena posibilidad de que ni siquiera veas el chat o tu mano levantada ahora que estoy compartiendo mi pantalla. Así que abre tu micrófono y habla. No te silenciaré. Quiero escucharte. Lo siento, Ritwick, eres la minoría. No haremos eso, pero haré esa otra masterclass, en un segundo, en otro lugar, tal vez. Genial.

Así que este es todo mi escritorio. Espero que no haya nada confidencial aquí. El proyecto, vamos a abrir eso. En realidad, es un repositorio de GitHub, así que si vamos a mi GitHub, esto debería estar subido. Tu paso cero es clonar este repositorio. Entonces, es tagesq.io/barra invertida serverless masterclass. Querrás hacer un fork y clonarlo para comenzar. De acuerdo, eso es lo que harás. Me pregunto si puedo hacer que todos colaboren aquí. Eso sería genial. Porque entonces no tendrías que... Tal vez puedas dejar un enlace en el chat. Claro. Sí, espero que no tengas que hacer un fork. Sería genial si pudieras simplemente... pero no creo que GitHub lo permita. Sí, déjame hacer eso. ¿Cómo vuelvo al... ah, chat. Excelente. Esto es lo que vas a hacer fork y lo que vas a clonar. Ahora tenemos, efectivamente, 20, 21, tenemos, como, dos horas y media. ¿Qué estamos construyendo? Querrás ver mi pantalla para esto. STRIPE Home, ¿alguien ha oído hablar de STRIPE Home? Si lo has hecho, levanta la mano. De acuerdo, bien. Genial. Estamos a la vanguardia. STRIPE Home es una herramienta increíble para empresas de cualquier tamaño para conocer a sus equipos, colegas, amigos. Es realmente genial, es solo un portal donde puedes ver a las personas que se unen al equipo, quién cumple años, puedes ver un calendario compartido. Es realmente agradable. Este es nuestro proyecto porque no es de código abierto y eso me molesta. Y solía trabajar en Spotify. Spotify tiene más de 5,000 personas. Y algo como esto te ayudaría a conocer a 5,000 personas mucho mejor que Slack o Confluence. Si has usado Confluence, lo siento. Entonces, el proyecto es que construiremos esto pero con tecnologías serverless. Nuevamente, es de código abierto. Así que no gano nada con esto, tú no ganas nada con esto. Solo estamos construyendo. Si no te sientes cómodo construyendo un proyecto colaborativo, no tienes que hacerlo. Algunas personas se preguntan, ¿vas a monetizar esto? No, tiene licencia MIT y así sucesivamente, pero es solo para aprender. Con eso, esta es la pila en la que estoy pensando. Si hay alguna objeción, esta masterclass es para que aprendas cosas. Y si estás aburrido de Tailwind o quieres usar Chakra UI o algo más, ahora es el momento de interrumpirme y proponer alternativas o algo más. Se trata de aprender cosas que hemos visto en Twitter pero tal vez no hemos tenido la oportunidad de usar. Y sé que es difícil encontrar tiempo en tu vida diaria para jugar y no quieres hacer estas cosas los fines de semana. Así que ahora es el momento de jugar con cosas geniales. De acuerdo, genial, no veo objeciones a esto. Esto es increíble. Si las hay, el chat es tu mejor amigo. De hecho, estoy mirando el chat. Bien, estas son las características del producto categorizadas por lo que se necesita y lo que es solo diversión y lo que tal vez sea demasiado complejo. Si llegamos hasta aquí, estaré realmente impresionado para ser honesto contigo. No creo que vayamos a hacer eso especialmente dado el tiempo. Pero es un proyecto open-source. Así que si quieres seguir aprendiendo y seguir jugando después de la masterclass, sé mi invitado. Pero comenzaremos aquí, agregaremos registro e inicio de sesión. Para algo como esto, probablemente necesitarías autenticación, ¿verdad? Así que haremos registro e inicio de sesión de un usuario, la capacidad de cargar una imagen de perfil, y que nos cuenten sobre ellos mismos. Anton, ¿qué pasa? Estaba a punto de preguntar, ¿después lo implementaremos en algún lugar serverless, verdad? Todo el proyecto es serverless. Sí, todo se compone de muchos proveedores serverless, exactamente. Ajá, de acuerdo. Genial. Sí, así que si puedes bajar la mano, sería genial. Sí, esa es una gran pregunta. Tal vez debería haber delineado qué proveedores serverless estaríamos usando. Entonces, en términos de serverless, ya sabes qué, es una masterclass, vamos a editar el archivo leeme aquí mismo. Así que tal vez vayamos aquí, los proveedores serverless. Y lo que haremos es alojamiento en...

Si tienen opiniones diferentes, ahora es el momento. Estoy pensando en alojarlo en Vercel, una de mis plataformas serverless favoritas en todo el mundo, y una abstracción encima de AWS. Así que si quieres usar AWS, genial, pero potencialmente innecesario porque Vercel es como una capa más agradable en AWS y no requiere tarjeta de crédito. Así que para la masterclass, probablemente sea mejor que pongas tu tarjeta de crédito en AWS y demás. Nuevamente, todo esto es interrumpible y personalizable y tenemos tiempo, de acuerdo.

Lo alojaremos en Vercel, el almacén de datos es, por supuesto, Zada porque trabajo allí y lo conozco mejor que cualquier otro almacén de datos. Creo que eso es todo, realmente, quiero decir, esos son los únicos servidores que necesitamos, un enrutador, así que un enrutador del lado del cliente/servidor, eso es Vercel y un lugar para almacenar nuestros datos. Si hay algo más, lo agregaremos a esta lista. Así que ahora voy a, sí Arslan.

Hey, soy nuevo en serverless, así que me preguntaba, como parte de esta masterclass, ¿podemos cubrir cómo depurarías diferentes códigos serverless? Normalmente en una API REST, simplemente lanzas el depurador y tratas de averiguar dónde se están rompiendo las cosas. Pero no tiene sentido para mí cómo funcionaría eso en serverless. Sí, definitivamente, dedicaremos tiempo, porque con serverless, generalmente necesitas configurar algo llamado registro de eventos. Porque en realidad no quieres, como, los registros son costosos, hay toneladas de cadenas de transmisión, y los proveedores no quieren acumular tanta información. Así que sí, configuraremos un registro de eventos y todo eso. Julio, Julio, Julio? ¿Qué pasa? Hola, ¿qué tal? Así que en realidad es una pregunta, ya que estás trabajando con Vercel, y vi Next.js en el readme, ¿tiene alguna relación Next.js con Serverless real o es algo diferente? Esa es una gran pregunta. Sí, Next.js es un React serverless. Espera, ¿qué? Eso es tan lindo, por cierto. Sí, Next.js es un framework React serverless. Esto es diferente, de alguna manera, comparable a Remix, porque ambos tienen, como, Remix te obliga a tener un servidor, y se renderiza completamente en el servidor, pero Next no lo hace. Entonces puedes generar un sitio estático con Next y implementarlo en un CDN serverless, una red de entrega de contenido, donde sirves contenido estático, o Next también puede renderizar contenido en el servidor para ti, y esto es algo que me emociona mostrarte cómo Vercel lo hará. Entonces sí, Next definitivamente, no voy a intentar decir Clement, lo siento. Sí, ¿qué pasa? Levantaste la mano, Clement. Vas a decir algo, ¿o fue un marcado accidental? ¿Dónde está el botón? Oh, okay, bueno, ¿qué pasa Oscar? La pregunta que tengo es, ¿vas a hablar un poco sobre Edge, como Cloudfarer o explicar un poco? Sí, definitivamente. Me encanta que lo mencionaste. Gracias. Muchas gracias, sí. Vercel Edge functions, son geniales. Increíble. Bien, me gusta esto. Me encanta la colaboración desde el principio, y estoy realmente emocionado por el tiempo que vamos a pasar juntos. Recuerdo que al comenzar esto, estaba un poco nervioso. Pensé, mierda, ¿estaré hablando con un montón de bots con la cámara encendida? Y sí, pero está bien. De acuerdo, genial, déjame ajustar el readme. Sí, siéntete libre de levantar la mano, a menos que haya algo que quieras. Eso funciona. ¿Es Clement? Sí, lo siento. Sí, mi Mac no estaba funcionando. Solo una pregunta, ¿cuál sería el mejor uso para serverless? ¿Es algo donde no tienes mucho tráfico? ¿Entonces la mitad del tiempo no se usa? Sí, esa es una buena pregunta. Voy a responder tu pregunta dibujando diagramas. Siéntete libre de ver mi pantalla. Entonces tradicionalmente, ¿verdad? Si tienes un sitio, como una aplicación React, lo que sea, generalmente tendrás, ¿por qué esta línea es punteada? De acuerdo, generalmente tendrás tu aplicación React en tu computadora. Así que tu computadora. Y lo que harás es subir esto en algún lugar para que todos puedan acceder. Y cómo lo harás es usando AWS, Vercel, lo que sea. Llamémoslo Cloud, el CDN Cloud. Un CDN significa una red de entrega de contenido. Su único trabajo es alojar archivos estáticos, HTML, CSS, JavaScript. Entonces en tu sitio, tienes un paso de construcción, ¿verdad? Harás algo como NPM Build o algo así. Y obtendrás activos estáticos. Entonces obtendrás algo de HTML, CSS, lo que sea. Esto es lo que sucede en tu computadora. Y luego, por cierto, si usaste, si alguna vez has usado Vercel en tu vida, esto es lo que hacen. Entonces, como Next Build, simplemente ejecuta esto, obtiene activos estáticos. Lo envías al CDN Cloud, ¿de acuerdo? Esta es una configuración serverless. En una configuración con servidor, tendrías que mantener el CDN. Y tendrías que mantener la complejidad en todo el mundo. ¿Cómo se distribuye? Entonces, si este es el mundo aquí, dibujemos el mundo. Así que aquí está Norteamérica, Sudamérica, Canadá, Europa, Australia. Wow, es increíble. Entonces si este es el mundo, ¿verdad? Querrás tener tu CDN aquí. Querrás tenerlo en varios lugares, este de EE. UU., oeste de EE. UU., Australia, Europa, Sudamérica, tal vez Canadá. Esto es muy importante. Y a estos se les llama puntos de presencia o POP. Es muy importante tener muchos POP porque si alguien aquí en EE. UU. quiere tu sitio, lo obtendrá muy rápido desde este punto de presencia. Pero si no tienes este punto de presencia, entonces tienen que ir todo el camino aquí a Europa. Y esta latencia es larga. Es muy lenta. Nadie quiere esperar eso. De hecho, hay evidencia empírica de que si alguien tiene que esperar más de cierto número de milisegundos, simplemente no te darán dinero. Por lo tanto, tener múltiples puntos de presencia es muy importante en una red de cloud con servidor. Y si no usas serverless, tendrías que administrar toda esta mierda tú mismo. Literalmente tendrías que crear servidores y poner una configuración idéntica en ellos en múltiples partes del mundo, y luego instalar software de monitoreo para lidiar con ellos. Y también tendrías que configurar algo llamado Conmutación por error regional donde, por ejemplo, alguien intenta comunicarse con este punto de presencia, pero no está disponible, como si estuviera roto, entonces automáticamente esta solicitud se redirigiría a otro punto de presencia disponible o al nodo raíz. Así que todo esto es como una completa mierda de servidor de la que Vercel y AWS y Heroku y todos los demás nos salvan. Pequeña pregunta, por lo que entiendo, las redes de entrega de contenido aparecieron mucho antes que el cloud, bueno, serverless y son totalmente separadas. Entonces podemos tener, no un serverless, pero aún tener un CDN. Sí y no. Entonces, serverless por definición es que no administras servidores. Entonces, si estás usando un CDN, eso se puede considerar serverless porque estás usando, por ejemplo, Akamai, el CDN más famoso, estás usando sus servidores. No administras los servidores. Por lo tanto, es serverless. Oh, lo siento, no borré mi mano, pero básicamente si tengo toda la administración hecha en mi servidor y expongo eso como una oferta pública, expongo eso como un servicio, básicamente desde el punto de vista de cualquier otra persona, sigue siendo una tecnología serverless, supongo. Usemos otro ejemplo que no sea el CDN porque eso puede ser confuso porque los CDNs existían antes de que serverless tuviera éxito. Entonces digamos que tienes un sitio. Llamémoslo, ¿por qué es verde esto? Lo siento, tengo algo con los colores. Hagamos que eso sea blanco de nuevo. Entonces tienes un sitio, este es tu sitio y cada sitio generalmente necesita data, ¿de acuerdo? Entonces decides, hey, quiero una base de datos y eso está bien, pero tu sitio necesita una forma de interactuar con la base de datos. Entonces necesitas una API. No voy a hablar de cómo se implementa tu sitio.

Puedes alojarlo tú mismo, puedes usar un CDN o lo que sea, pero tu sitio llamará a una API. Tu API interactuará con una base de datos. Esto es muy común. Con el tiempo, tu base de datos necesitará escalar. Digamos que tu aplicación se vuelve muy exitosa, muy popular. Aquí hay dos, en realidad cambiemos el color aquí a rojo. Las cosas en rojo son servidores que mantienes en una configuración no serverless. Entonces tendrás que mantener un servidor de API. ¿Cómo se ve un servidor de API? Si alguna vez has escrito express, vamos, index.js, ¿verdad? Entonces harás algo como require express. Oh, acabo de obtener GitHub Go Pilot. Esto es genial. Express y luego harás const app, ¿verdad? Y este es el servidor de API más básico, app.listen 3000. Entonces este es un servidor. Y en tu API, podrías hacer algo como app.use slash mi endpoint. Y puedes verificar la autenticación. Esto es sudo código, por cierto. Y luego, si está autenticado, o más bien si no está autenticado, entonces puedes res.status. Esto es, bienvenidos todos, esto es Zata. Me gusta la imagen de Joseph porque esa es la reacción que espero que todos tengan en Zata. Entonces, en Zata, tenemos esta noción de espacios de trabajo, que es como una organización de GitHub. Y estos son bases de datos. Entonces, estas bases de datos se ejecutan en la Organización de Zata. Estos son en realidad nuestros sistemas de producción que dependen de ellos. Por ejemplo, esta base de datos de blog aquí. Y esto es importante porque lo vamos a usar. Así que es importante dedicar al menos dos minutos para mostrarte cómo funciona. Esta base de datos de blog, si vamos a las publicaciones, literalmente ejecuta nuestro blog de producción. Entonces, si voy a Zata.ios slash blog, todo el contenido aquí, esto es una aplicación XJS, y utiliza como una base de datos serverless, un backend serverless, utiliza Zata. Entonces estas publicaciones son estas publicaciones. Pero notarás que el orden no es correcto. Esto comienza con JSConf Budapest, esto comienza con JAMstack. Eso se debe a que esta es una consulta personalizada. Entonces, si ordenamos por fecha descendente, ahora debería coincidir. Y cómo consultamos esto en el frontend es haciendo clic en Obtener fragmento de código aquí. Y obtenemos un código en un lenguaje que nos gusta, como JavaScript, copiar, pegar. Y eso es nuestro frontend. Así es como queremos que sea la experiencia de desarrollo. Además, hacemos que el esquema de tu base de datos y tus tablas y demás sean bastante fáciles. Entonces, como puedes ver aquí, tenemos autores, publicaciones y personas. Y las publicaciones dependen de los autores a través de esa columna allí. Así que simplemente tratamos de resolver muchas de las mierdas de la base de datos para que realmente puedas construir un blog y tus sitios web. Y te lo estoy mostrando porque es bastante importante a medida que obtienes acceso y construimos un producto. Entonces, ¿cómo te damos acceso? La lista de permitidos está en una base de datos llamada beta allow. He ocultado los correos electrónicos. Oh, está bien. La clave de API dura solo 10 minutos. No te preocupes por eso. En realidad, aquí dice si lees un poco. A continuación se muestra un token de acceso temporal que expirará después de 10 minutos. Es solo para obtener algo rápidamente. Pero gracias. Aprecio que estés pendiente. Así que he ocultado las direcciones de correo electrónico porque no queremos filtrar eso. De acuerdo. Tenemos nuestra pieza de base de datos configurada. Creo que sería genial si usamos una única base de datos colaborativa. Genial. Veo muchos pulgares arriba. No veo problemas. Esto es exactamente lo que quería. ¿No es mucho más fácil trabajar con una base de datos así? No estoy escribiendo maldito SQL. Me detendré aquí. Pequeña pregunta. En realidad, está solicitando algún tipo de espacio de trabajo y no veo ninguna forma de iniciar sesión o algo así. Está bien. Si has iniciado sesión, sí, deberías ver crear un espacio de trabajo. Un espacio de trabajo es como una empresa. Es como un equipo. Entonces hay un equipo de ejemplos de Zata al que te invitaré en solo un minuto. Tengo tus direcciones de correo electrónico. Entonces lo que vas a hacer es recibir un correo electrónico para unirte a mi espacio de trabajo. Les digo que es una empresa de experiencia de desarrollo. Como si tuviéramos un trabajo y ese es experiencia de desarrollo. Como si volvemos a esta mierda que dibujé. Tomamos la experiencia de desarrollo de todas estas cosas y las ocultamos detrás de REST y te brindamos comodidad. Entonces, Zata se trata de comodidad. Si te vas con algo, eso es lo que quiero que te lleves. Todos estamos en la misma organización ahora. Entonces creemos una base de datos. Esta será la base de datos para nuestro proyecto. Aprecio tus bases de datos de prueba aquí. Si quieres, siéntete libre de eliminarlas o déjalas. Realmente no nos importa. Agregaré una. La llamaremos, cómo deberíamos llamarla, nombrar cosas, llamémosla home. Entonces tenemos la base de datos home. Confirma que todos tienen la base de datos home. Y eres el propietario, así que deberías poder ingresar a esta base de datos y explorar. Notarás que tengo una característica que tú no tienes, SDK Playground. Hablaremos más sobre eso en un momento.

Pero lo que queremos, volvamos a nuestra misión. Queremos construir Stripe Home. Y si volvemos a nuestro repositorio de GitHub, github.com, en lugar de github.dev. Estas son las características que necesitamos. Alguien debe poder registrarse o iniciar sesión, crear un perfil de usuario, administrar equipos y asignar un usuario a un equipo. Eso es básico para algo como Stripe Home. ¿Cómo podemos hacer eso desde una perspectiva de modelado de datos? Deshagámonos de esto. Necesitaremos crear una tabla de usuarios y luego una tabla de equipos que se relacione con ella. Entonces, alguien, quien sea, espera, tal vez debería elegir a alguien. De lo contrario, todos intentarán hacerlo al mismo tiempo y será un desastre. Arsalan, ¿puedes crear una tabla de usuarios y luego definir un esquema razonable para algo como Stripe Home? La interfaz de usuario debería actualizarse automáticamente si cambias la visibilidad. No deberías tener que volver a cargar la página tampoco. Para ser justos, nunca hemos probado realmente características colaborativas como esta. Así que realmente no sé cómo va a ir, pero si haces una tabla en el home, sí, genial, veo usuarios. Hay una columna de ID. Esto va bien. Y tal vez agreguemos algunas columnas. Entonces, ¿qué necesita un usuario? Necesita una dirección de correo electrónico, un nombre de visualización. Ahora eso es bueno, excelente participación. Gracias. Siento que estoy hablando con seres humanos y no bots. Esto es muy valioso. De acuerdo, hemos identificado el equipo. El equipo es realmente importante. Eso es genial. Pero hagamos el equipo al final. ¿Cómo se ve la tabla? Así que mi interfaz de usuario, oh, genial. El equipo es una clave externa. Eso significa clave externa. Sí, esto es bueno. Tan bueno. Entonces, Avatar, agreguemos uno para la URL del avatar. Arsalan está al volante, así que solo te estoy diciendo lo que veo en el chat, ¿de acuerdo? Genial. Entonces, URL del avatar, el equipo es una clave externa. Ahora, llegaremos a eso en un minuto. Tengamos un apodo, ¿por qué no? Tengamos algunos pronombres. Oh, usaste kebab case para la URL del avatar. Me gusta. Sí, en lugar de género, hagamos pronombres porque importan cuando te diriges a alguien mucho más que el género, aunque el género es importante. Genial. Creo que tenemos suficiente. Nombre, correo electrónico, edad, URL del avatar, apodo, pronombres. Esto es genial. De acuerdo, tenemos usuarios. Ahora hagamos otra tabla. Voy a hacer que Tristan haga eso. Si estás en la misma base de datos, Tristan, puedes agregar otra tabla para equipos, y los equipos, creo, son muy simples. Solo tienen un nombre. Tal vez puedan tener un avatar, pero eso, no sé, tengo un equipo de frontend. Eso es realmente todo. Una descripción si quieres ser más detallado, como texto largo, pero...

De acuerdo, genial. Sí, nuestra recarga en tiempo real en vivo es un poco inestable, pero te veo agregando columnas allí. Me encanta esto. Sí, definir el modelo de datos es realmente importante, porque no queremos arruinar esto. Puede ser costoso cambiar, pero con Zara no lo es, y hablaré de eso en un momento. Los usuarios tienen un ID único. Ese es un detalle interno, no deberías preocuparte por eso. Pero también puedes establecer el ID como quieras, siempre y cuando sea único. Ahora, si agregamos, vayamos a usuarios. Queremos registrarnos, ¿de acuerdo? Ahora comenzaremos a escribir código de React. Creo que hemos definido suficiente modelo de datos para comenzar a hacer algo de trabajo de React con Zada. De acuerdo, lo que vamos a hacer es crear una página de inicio de sesión y luego almacenar usuarios en Zada. De acuerdo, abriremos Visual Studio Code. Y para comenzar, antes de hacer cualquier cosa, necesito instalar, no necesito, pero es cómodo para mí instalar la CLI de Zara, que será como mi mejor amigo mientras trabajo con ella aquí en mi aplicación de Next JS con datos. Arsalan, preguntaste sobre cosas de TypeScript. Esta es la respuesta a eso.

Entonces, lo que voy a hacer es, también lo pondré en el chat, pero estoy ejecutando un comando curl para instalar la CLI de Zada. Pero lo que estoy a punto de mostrarte cambiará. Vamos a hacer npm install global y todo esto. Esto es solo para la versión beta privada para no arruinar el ecosistema de npm. Así es como se instala la CLI de Zada. Debes ejecutar eso en tu terminal y verás algo como esto. Zada se instaló correctamente en donde sea. Si hiciste eso, siéntete libre de reaccionar con un emoji para que sepa que tuviste éxito. Si necesitas ayuda, estoy aquí para eso.

Ahora tengo la CLI de Zada y puedo hacer cosas como Zada help. Esto me permite hacer todo lo que hice en la interfaz web, lo puedo hacer aquí en la CLI. Es un poco más cómodo, ¿vale? Para empezar, necesitaremos hacer Zada Auth login. Te pedirá que introduzcas tu clave de API. Puedes obtener una clave de API siguiéndome. Entonces, si vas a tu interfaz de Zada, si haces clic en ti mismo aquí y vas a Configuración de la cuenta, tengo demasiadas claves de API, pero deberías poder agregar una. Permíteme eliminar mi clave de CLI. Agregaré una clave llamada CLI. Esta es la clave, esta es mi clave, está bien. La revocaré después. Lo que voy a hacer es copiarla aquí y luego pegarla en la CLI. Y dice, bien, estás autenticado. De acuerdo, si autenticaste correctamente la CLI, me gustaría saberlo si reaccionas con un emoji o escribes algo en el chat. Incluso podría ser, wow, esto es increíble, en el chat, eso sería genial. Oh mira, es data del cliente. De acuerdo, bien, genial. Oh, certificado expirado, ¿qué demonios? Clement, ¿usas Windows? Charles, si necesitas Windows, vamos aquí a la documentación. Y para la CLI, creo que hay algunos comandos de Windows allí también, déjame conseguir eso para ti. Windows, algo con IWR e IEXL pegado aquí. No, yo uso Mac. De acuerdo, alguien preguntaba por Windows, entonces. Sí, Charles, tienes problemas, eso es interesante. ¿Alguien más tiene ese problema con los circuitos SSL? De acuerdo, ¿puedes ejecutarlo de nuevo? Lo siento, puedo quedarme sin ideas si eso persiste porque eso significaría que Zara.io tendría problemas de SSL, lo cual no tenemos. ¿Puedo acceder a esto? Oh mierda, tal vez puedas hacer eso. Solo puedes descargar el archivo shell y luego ejecutarlo arrastrándolo a tu terminal. Ahora tienes la CLI. ¿Qué podemos hacer con la CLI? ¿Eso fue importante? Sí, es importante. Mírame y sígueme. La suposición aquí es que ya has autorizado Zara. Entonces, esto es lo que vas a hacer. Vas a hacer Zara in it, en la raíz de esto. Y te preguntará, elige un espacio de trabajo. Voy a elegir Zara learning. ¿Alguien puede compartir el enlace de GitHub? Puedo compartir el enlace de GitHub del taller. Es este, de acuerdo. Entonces ahora te preguntará a qué database quieres acceder y puedes crear uno nuevo o elegir uno. Así que vamos a usar el que acabo de crear, que se llama Home, creo. Sí, Home. ¿Quieres instalar? Mira, Arsalan, este es tu momento aquí. ¿Quieres instalar el SDK de TypeScript y el generador de código? La respuesta es sí. Y ahora instalará cosas en nuestro paquete de nodos que nos permitirán consultar Zata de manera cómoda, ¿vale? Hasta ahora todo bien. Qué demonios. De acuerdo, tienes, mira esto, tienes un guion en tu clave porque los nombres de columna están un poco desordenados. Así que tendremos que arreglar eso. Para ser justos, nunca, realmente no he, eso es una buena prueba. Tienes avatar-guion URL. Eso es un problema. Así que vamos a arreglarlo y ponerlo en camel case o guión bajo o lo que sea. Renombra la columna a avatar. Usemos camel case. De acuerdo, lo ejecutaremos de nuevo. Entonces, Zata init, el directorio Zata ya existe. Entonces, esto, si haces LS aquí, introduce una carpeta en tu proyecto. Eliminaremos esa carpeta y ejecutaremos Zata init de nuevo. Si no puedes seguir, interrumpe el chat, para eso estoy aquí. Entonces ahora, ¿qué espacio de trabajo, qué empresa, qué equipo? Zata learning, qué database, es home. ¿Quieres instalar? Mira, Arsalan, este es tu momento aquí. ¿Quieres instalar el SDK de TypeScript y el generador de código? La respuesta es sí. Y ahora está haciendo su trabajo y estamos listos. Entonces, ¿qué acaba de pasar? Si hago LS, ha hecho algo de trabajo. Ha creado un directorio Zata para mí y ha creado un directorio SRC para mí o ha puesto algo en mi directorio SRC. Veamos el directorio Zata primero. Entonces, en realidad, hagamos esto en Visual Studio Code. Entonces, Zata, ha creado un schema.JSON y un config.JSON. El schema.JSON es en realidad mi database representado como código. Así que si pliego esto, lo que puedo ver son las tablas. Tengo dos tablas, usuarios y equipos como las hicimos. Esto no es nada nuevo. Solo lo hemos descargado y alguna configuración, como este es el nombre de la database, este es el ID del espacio de trabajo y así sucesivamente. Nunca lo tocarás. Esto es solo para cosas internas. Y también hay un archivo zata.ts. Y estas son cosas completamente seguras en cuanto a tipos, lo cual es bastante emocionante. ¿Qué podemos hacer con esto? Podemos consultar Zata de una manera realmente segura en cuanto a tipos. Esto es lo que quería mostrarte. Este es nuestro proyecto, de todos modos hemos terminado con la configuración. Entonces, si quiero consultar mi lista de equipos de Zata, ¿cómo puedo hacerlo? Crea un nuevo archivo. ¿Ejecutar qué? Clement? ¿Ambos están en Windows? Ah, esto es algo de Windows.

Y probablemente, no te bloqueará el uso de Zata, solo bloqueará tu pieza de generación de código. Sí, sí. Exactamente. Permíteme darte el archivo TS. Lo siento, arreglaremos el Generador de Código de Windows. Pero déjame dártelo por ahora. Así que paste bin. Y seguiré dándotelo a medida que avancemos. Aquí tienes tu archivo TS. Quieres ponerlo en tu src/zata.ts, ¿de acuerdo? Genial.

Entonces, ¿qué podemos hacer ahora que todo está configurado? Si vamos a Source, creamos un nuevo archivo, pages/API/teams.ts. Esta es una ruta de API de Next.js. Es una función sin servidor. Es lo mismo que Cloudflare Workers. Tal vez hayas oído hablar de ello. Es una función que se ejecuta en un proveedor de funciones sin servidor como AWS Lambda, Cloudflare Workers, etc. Entonces diremos handler o llamémoslo función. ¿Es función una palabra reservada? Sí lo es. De acuerdo, handler. Es un controlador de API de Next. Es una función asíncrona que recibe una solicitud y una respuesta. Haremos que sea la exportación predeterminada. Y en esta función, podemos consultar Zadda. ¿Cómo consultamos Zadda? Necesitamos un cliente de Zadda. Así que haremos cliente = new ZaddaClient. Como puedes ver, no está aquí porque necesitamos importarlo. Así que importaremos esto desde...Zadda. ¿Cuál es la exportación? ZaddaClient. ¿De acuerdo? Y todo es TypeScript. Como puedes ver, estoy autocompletando. Estoy navegando con la tecla Tab. Así es como se hace en TypeScript. Ahora puedo instanciar ese nuevo ZaddaClient sin argumentos. Y ahora puedo consultar... Mira, es pages/API/teams. Así que voy a consultar los equipos. Así que haré const data y esperaré a que el cliente... ¡Wow! No lo esperaba... Acabo de obtener copilot hoy. No estaba preparado para esto. Cliente... Esto está realmente mal, pero Cliente.db... Y tengo esto de Zadda. Estas son mis tablas. Es genial que pueda hacer esto. Hay un TypeError en... ¿En serio? ¿Dónde? Esto es bueno saberlo. Podría tomar una captura de pantalla para más tarde. Se esperaban de cero a dos argumentos, pero se obtuvieron tres. ¿Dónde en el mundo hay tres argumentos? Claramente hay dos argumentos. Maldición. Si alguien puede decirme por qué dice tres arg... Ah, argumentos para super. Ya veo. Sí, esto, no sé. Veamos si funciona. Teams.getAll. Esta forma segura de tipo desde Codegen es cómo interactuamos con la tabla que acabamos de crear. Así que hemos creado algunos equipos, imagino, ¿verdad? Echemos un vistazo. Teams. Sí, tenemos algunos equipos aquí. Así que consultaremos esto. Diremos res.endData. Espero que diga registros. Ah, tal vez no. Sí, es seguro en cuanto a tipos. De acuerdo, data será simplemente un array. Veamos qué sucede. Tenemos esto. Ejecutemos nuestro servidor. Así que son ocho páginas. Así que es API/teams donde queremos ir. API/teams. 404. De acuerdo. ¿Cómo estás 404? Acabo de crearte. ¿Qué? De acuerdo. ¿Estoy? Solo voy a hacer un puerto reactivo y ver qué sucede. Creo que como una buena depuración comp. De acuerdo, probemos esto. Sí, todo es 404, lo que me dice que mi next.js no está realmente. Oh, cierto, tengo que estar en SRC. Ah, no estaba en SRC, perfecto. Ahora debería tenerlo, de acuerdo, está funcionando. Así que API/teams, se requieren opciones, URL de la base de datos y clave de API. De acuerdo, eso está bien. Deberíamos tenerlos aquí, aquí. Pero en realidad están aquí, creo. Están en config. De acuerdo, así que URL de la base de datos.

De acuerdo, vamos a obtener, así que necesitamos dos opciones. Una es la URL de la database, vamos, database, espera. Sí, URL y clave de API. Ambos los podemos obtener desde la interfaz web. Así que si voy aquí, comienzo a aprender, así que si vas a configuración, tendrás tu URL de la database. Esta es tu URL de la database. Esto está dedicado solo para tu database. Así que este es tu ID de espacio de trabajo, nombre de la database y rama de la database. Llegaremos a eso. Sí, Zada es como un repositorio Git y realmente puedes ramificar tu database para agregar funciones. Así que comenzaremos con esto. Nuestra database se llama home. Si alguien tiene la televisión encendida, agradecería que la silenciaras. Y esta es la rama principal de la database. Y la clave de API es la que generamos. En realidad, no es porque generamos una clave de CLI. Hagamos otra solo para nuestra aplicación. La llamaremos home app. Esta la guardaremos en un archivo .env. Entonces, .env zada-api-key es esto y lo leeremos aquí. La clave de API de Zada es, podría simplemente poner una cadena, pero en realidad no es muy seguro. ¿Por qué te quejas? Cliente. ¿Qué te pasa? Creo que tal vez sea solo mi cosa de TypeScript. Mi configuración de TS tenía algunos problemas. La resolución del módulo debe ser node. Es extraño que generen algo diferente. Guardar. ¿Estás bien? Sí, todo está bien. Es la URL de la database, amo TypeScript, perfecto. De acuerdo, estamos bien. Reiniciemos el servidor para obtener el .env, y aquí dice, loaded.env. Bien, eso es importante. Ahora volvamos y obtengamos el nombre de la rama, identificador no válido. Creo que en realidad inferimos el nombre de la rama. Perdóname, y aquí. De acuerdo, perfecto. Así que estamos obteniendo data, pero no podemos enviar data a través de la red HTTP. Tenemos que convertirlo en una cadena, ahí vamos. Así que estábamos obteniendo, ¿qué diablos es esto? Así que estamos obteniendo esto directamente de Zara utilizando un cliente seguro en cuanto a tipos. Así que si no tengo una tabla llamada, buena, Nada. Si no tengo una tabla llamada Teams, voy a tener problemas, o al menos debería si la generación de tipos funcionó. Espera, punto, sí, teams dot get all. Siguiente, esto es demasiado bueno. Realmente no sé por qué hace eso. Pero lo que también podemos hacer es filtrar aquí, así que puedo filtrar por mi equipo específico. En realidad, usemos parámetros de consulta para eso. Así que agregaremos un parámetro de consulta, filter, rec dot query. Y podemos hacer eso. Así que filtraremos donde el nombre comienza con, o contiene, el nombre contiene el filtro. ¿Qué quieres? Le diremos a TypeScript que esto es una cadena. De acuerdo, así que ahora deberíamos obtener todos los equipos, si... O ningún equipo, claro. Tal vez deberíamos deshacernos de esto. Así que nuestros filtros son un poco exclusivos, me gusta. De acuerdo, hasta ahora, podemos obtener una lista de equipos. Escribamos algo de React. Porque ahora voy a hacer commit y push de esto, por cierto, solo para que puedas hacer pull y tener el código. Recapitulemos. Estos son generados automáticamente por Zata. Esto fue generado automáticamente por Next.js. Creamos esta ruta. Podemos eliminar esta. Esto fue generado automáticamente. Esto fue automáticamente. Así que es solo un montón de cosas generadas automáticamente. Solo estoy haciendo push a main, espero que esté bien. ¿Debería hacer push a main? Sí, está bien. Agregar archivos generados automáticamente. Agregaré todo excepto la ruta de los equipos. Y ahora agregaré la ruta de los equipos en un commit separado. De acuerdo, haré push de eso. Deberías poder hacer pull para estar donde estamos. Genial. Ahora que tenemos una lista de equipos, paso uno, nos queda solo una hora, pero el objetivo es aprender. No se trata de terminar el proyecto. Me alegra que tengamos suficiente. Nuevamente, siéntete libre de interrumpirme con preguntas, con comentarios, con lo que sea, chat. Así que registrarse e iniciar sesión. Tenemos una lista de equipos. Gestionar equipos está un poco más abajo, pero ahora que tenemos una lista de equipos, podemos crear un formulario de registro y pedirle al usuario que elija un equipo.

De acuerdo. ¿Cómo lo haremos? Podemos omitir la parte de tailwind, por cierto, por cuestiones de tiempo. Y simplemente usaremos una interfaz de usuario fea. Así que comencemos con un formulario de registro. Crearemos páginas. Crearemos signup.tsx. Este es un componente React que interactuará con Zada. Clásico, clásico React. Crearemos un formulario con una etiqueta para tu nombre. ¿Cuál es nuestro, cuál es nuestro, necesito recordar el esquema de nuestra tabla. Podría ver el código también, pero prefiero verlo aquí. De acuerdo, así que nombre, correo electrónico, edad. Entonces, ¿qué deberíamos solicitar para el registro? Esa es una buena pregunta. Podemos solicitar todo. Será rápido. Tipo de entrada para este texto.

¿Alguien tiene VSCode Live Share? Si lo tienes, puedes venir a escribir código conmigo aquí. Te enviaré una invitación en un minuto. Luego podemos paralelizar las tareas.

De acuerdo. ¿Copiar de nuevo, qué? De acuerdo. Si estás trabajando en el proyecto, puedes crear este formulario conmigo. De lo contrario, podría ser un poco aburrido. Así que crearé las columnas y no te molestaré. El nombre es obligatorio, por supuesto. De acuerdo. Deberíamos agregarlo. Sí, gracias. Eso es exactamente lo que iba a hacer. Entonces tenemos nombre, correo electrónico, edad, URL de avatar, apodo, pronombres, equipo. El correo electrónico no tomará mucho tiempo, creo. Sí. Ali, bienvenido. Siéntete libre de ajustar las columnas aquí. De acuerdo, apodo, pronombres, ¿y cuál era el último? Equipo. De acuerdo, la edad es un número, la foto es un archivo. El apodo es texto, los pronombres son texto y el equipo es un select. ¿Quién quiere? Alguien, no tener, puedes reemplazar eso con un select con algunas opciones. ¿Por qué no? ¿No tienes permisos de lectura o escritura, qué? Eso es una tontería. No eres completamente de solo lectura, hombre. Mira, dice en mi pantalla lectura, escritura. Lectura, escritura, así es Ali. Julio, ¿estás... Esto es genial, ¿ves? Muy bien. Bien. Podemos agregar algunos valores codificados. Pero el objetivo es obtener los equipos de Zara y mostrarlos aquí. Esto es genial, excepto por la lectura, escritura. Chanimo desde Windows, él tiene Windows, eso será lo mejor. De acuerdo, mientras alguien crea las opciones, quiero que alguien escriba un useEffect que obtenga los equipos desde nuestro nuevo punto de API. Sí, si agregas un useEffect y luego un useState para almacenar los equipos, eso sería de gran ayuda. Sí, si alguien quiere agregar un useState con los equipos justo encima del useEffect, eso estaría genial. Perfecto. Lo estás haciendo muy bien. Esto es bueno, así es como escribo las aplicaciones React con A. ¿Cuál es el nombre del módulo? Esto es bueno, es una buena pregunta. De acuerdo, ¿por qué estoy siguiendo a Julio? ¿Puedo dejar de hacerlo? Oh, mierda. Lo siento, Julio, te eliminé accidentalmente. Tal vez puedas unirte de nuevo, fue un accidente. Pensé que dejaría de seguirte. En cambio, simplemente te cancelé. Cultura de cancelación, eso está un poco jodido. De acuerdo, la cultura de cancelación no está jodida. De hecho, cancelarte es jodido. De todos modos, sí, gracias, Sr. Organi. De acuerdo, esto es lo que vamos a hacer. Entonces, primero necesitamos un estado para almacenar los equipos. Equipos, setEquipos. Y usaremos useState. Es un array vacío al principio, pero será un array de equipos. Así que necesitamos definir un tipo. ¿Por qué diablos hay dos importaciones separadas? De acuerdo, necesitamos un tipo para nuestros equipos. Nuestros equipos tienen un ID y un nombre. ¿Por qué no usar el, qué? Oh, eso es muy inteligente. Eso es muy inteligente, mierda. Este tipo es un genio. Importa el tipo de Zara. Muy bien, hay un equipo. Wow. ¿Qué es equipo? ¿Nombre y foto? Oye, eso no está bien. En realidad, sí, pero también tiene un ID. Así que haremos equipo. No sé por qué el tipo gen no incluye eso, pero es equipo y un ID. De acuerdo, genial. Ahora fetchTeams async exactamente. ¿Qué va a pasar? Necesitamos obtener datos de api/teams. ¿Ves, creamos esta función, verdad? Y obtendremos un json. Y luego estableceremos los equipos. Eso es todo lo que haremos. En realidad, no necesitamos nada de esto. Por cierto, no puedes acceder a la API de Zada desde el lado del cliente. Puedes hacerlo, pero no deberías. ¿Puedes decirme por qué? Probablemente expongas tu clave privada, que es una clave pública. Tu clave de API, sí, exactamente. Si consultas a Zara desde aquí, lo que sucederá es que puedes inspeccionar las DevTools en la red, mirar la cabecera de autorización y estás jodido. Te permitiremos usar claves de solo lectura, pero en general no quieres incluir cosas seguras desde el lado del cliente. Es solo un entorno hostil, pero con Next.js esto es fácil. Tenemos esto. Además, eres el primero en el mundo en saberlo. En realidad, estamos trabajando en un gancho useZada que puedes usar desde el lado del cliente. Pero cuando ejecutas npm run build, lo que sucederá es que tomamos el gancho useZada, desplegamos un CloudFlare worker que obtiene datos de Zada y tu aplicación no obtiene datos de Zada desde el lado del cliente. Simplemente obtiene una función serverless que creamos en tiempo de construcción, ¿de acuerdo? Esto es genial. Gracias a quien estaba escribiendo esto, Nadev o Julio, creo. Gracias por volver, por cierto. El equipo es un objeto.

Así que quieres hacer team.id. Y luego haremos, sí, puedes completar eso. Entonces team.name, supongo, ¿verdad? Team.name, genial. Esto se ve genial. Todo use React Query, me encanta. Guardar. Teóricamente esto parece que va a funcionar. Si quieres, mira mi pantalla ahora mismo porque lo voy a ejecutar, o ya se está ejecutando. ¿Qué es? Registrarse, ¿verdad? Registrarse. Alguien arregle esto. Y luego creo que si guardas, mi página debería recargarse automáticamente. Joder, eso es genial. ¡Wow! Esto es lo más genial que he visto en mi vida. No estoy tocando mi computadora. Fin de archivo inesperado. ¿Olvidaste el nombre? Registrarse, exportar por defecto, registrarse. No estoy tocando, esto es tan genial. ¿Qué pasó aquí en el chat? Visual Studio Live Share, Live Share, este. ¿Por qué no está? Supongo que se guardó parcialmente. Está un poco jodido. De acuerdo, genial, funciona. Ese es el formulario más feo que he visto en mi jodida vida. Necesitamos, no puedo. Tal vez no usemos Tailwind, pero necesito CSS. Esto es, no puedo funcionar de otra manera. Usaremos CSS, solo haremos SRC main.CSS, algo así. TSX y luego Next.js tiene algún tipo de cosa global de aplicación con guión bajo. Esto no es parte de la masterclass, simplemente no puedo trabajar con algo tan feo, perdón. Pegar, e importaremos el CSS aquí. Ahí vamos. Sí. De acuerdo, tengo que, lo siento por esa interrupción. Es muy importante. Y luego exportaremos por defecto. Wow, alguien ya lo hizo, gracias. De acuerdo, tenemos CSS, gracias a Dios. Formulario, display grid. Mucho mejor. De acuerdo, eso es genial. Y luego también etiqueta, ¿verdad? Queremos que la etiqueta sea un flexbox. Display flex, gap, no sé, ocho píxeles. Oh, eso es, hombre, mucho mejor. Nuestro formulario no tiene un botón de envío. ¿Alguien puede agregar esto, por favor? ¿Por qué? ¿Algo en el chat? De acuerdo, arreglé Next.js para ganar. Una interfaz de usuario increíble, es la interfaz de usuario más increíble. Gracias, Julio, esto es súper útil. De acuerdo, bien, llámalo registrarse en su lugar. Genial, tenemos un bonito formulario. Es un poco feo. Tal vez, ya sabes, ancho máximo, 640px, margen cero, o 64px, auto, ah, mucho mejor. Ahora, estoy improvisando mucho. De acuerdo, bien, board, última cosa, promesa. Oh, gracias a Dios. De acuerdo, sí, Dave, ¿estoy? No veo una solicitud para que te unas al Live Share. Por cierto, si quieres cambiar el CSS o cualquier cosa en tiempo real, siéntete libre. No hay problema, pero tal vez no arruines la sintaxis. Sí, te dejaré ser muy creativo. Pero ten en cuenta que estamos construyendo una aplicación aquí, ¿de acuerdo? Así que tal vez no nos volvamos demasiado locos. Wow, Sofia. Ni siquiera conozco esta fuente. ¿Quién pidió el Live Share? Dave, tú, no he visto una solicitud tuya, pero si quieres el enlace aquí. ¿Se ve bien? Está bien por ahora. ¿Qué demonios es el botón de registro? ¿Por qué? De acuerdo, de todos modos, se ve bien. Podemos volver a ello. Lo que quiero que notes es el equipo de Ali, tenemos los equipos de Zara, si miras este píxel jodido, como un destello, ¿lo ves? Eso es asqueroso, lo odio. Estamos a punto de hablar de, así que recapitulemos un poco lo que hemos hecho. Tenemos... Oh, estás tratando de arreglar el destello. De acuerdo, te dejaré hacerlo. Esto es realmente importante para la masterclass. De acuerdo, buen intento. Ahora, si recargo... En realidad no puedo culparte por eso, pero puedo. A veces hay un destello. Como, si recargo aquí, hay un destello y no es realmente amigable. Sí, eso está bien. Pero espera, espera, tengo otra opción. Veamos el código fuente y busquemos el equipo de Ali. Y no lo entiendo porque esa mierda no me llega estáticamente. Buen intento, pero no. Estamos a punto de... Así que recapitulemos y luego hablemos de una estrategia realmente importante para trabajar con aplicaciones serverless. ¿Qué hemos hecho hasta ahora? Hemos creado una base de datos. La hemos consultado. Hemos obtenido acceso a ella. Y hemos hecho mucho desde el lado de la base de datos. Desde el lado de serverless. De hecho, hemos creado una función serverless aquí con el Zada Client. Y en realidad estamos consultando una base de datos. Así que tenemos una API.

Volviendo a ese diagrama aquí, ya tenemos una API que ya está siendo manejada por nosotros. Así que esta cosa del servidor de API. Cuando implementemos esto, nuestra cosa que obtiene data de Zada se implementará en Next en las funciones serverless de Vercel. Nuestra base de datos, el Redis, el Kafka, la búsqueda, todo esto proviene de Zada. Permíteme delinear con colores un poco. El verde es Vercel. El rojo es Zada. Y ya tenemos todo eso. Esta masterclass ha sido realmente intensa en el lado serverless, presentándote a Zada y a Next.js y Vercel, si aún no los conocías. Pero también vamos a implementar esto. Usaremos Vercel. En realidad lo implementaremos solo por diversión. Sí. No sé si escuchas la sirena. Lo siento. Lo implementaremos en mi equipo. ¿Quieres vincularlo a un proyecto existente? No. El nombre de mi proyecto es serverlessworkshop. El código está aquí. Ahora, algo así como el CLI de Zada, el CLI de Vercel es muy similar. Cada herramienta serverless hará algo así. Estas configuraciones se ven bien, así que ahora se está implementando nuestra cosa. Si todo va bien, simplemente funcionará, pero probablemente no funcione porque no hemos configurado las variables de entorno en la nube. Exactamente. Buen descubrimiento. Así que hagámoslo. Luego tendremos una configuración completamente serverless. Pero me pregunto, ¿qué? Interesante. Probablemente la compilación falló porque no tenemos las variables secretas configuradas, puedes verificarlo. Si vamos a funciones, la implementación falló sin ningún mensaje. Vamos al registro. Es este error de tipo. Genial. Vamos a solucionarlo. ¿Entonces me estás diciendo que no quieres eso? De acuerdo. Genial. O tal vez simplemente optemos por no hacerlo. No estoy seguro si es necesario o no. Implementemos esto nuevamente en producción de inmediato. Lo que estamos haciendo ahora es implementar una aplicación React en una configuración serverless. El sitio estático se encuentra en Vercel CDN. Las funciones se ejecutan en AWS Lambda, que Vercel utiliza en segundo plano. Claro, sí. No hay problema, Arsalan. Y la base de datos, por supuesto, se encuentra en Zada. Estas son nuestras tres cosas diferentes serverless que estamos uniendo. Y después de esto, veremos, y esto es realmente importante para ti y tu trabajo, creo que vamos a ver cómo obtener datos de manera responsable con React. Eso significa sin contenido parpadeante. No si, no equipos, entonces null. Como, obtendremos data de una manera que sea una buena experiencia de usuario. La compilación se realizó correctamente, se implementó. Esto está bien. Si vamos a registrarse, deberíamos tener nuestro formulario. De acuerdo, y en realidad obtiene datos de Zada. ¡Joder, ni siquiera sé cómo, probablemente esté hablando con localhost. Y eso, confirmemos, slash equipos, ¿dónde está? ¡Oh wow, maldición! Eso es de otro nivel de Vercel. Variables de entorno, simplemente en la nube. Es la primera vez que veo eso, joder. De acuerdo, está funcionando. Incluso implementado aquí, puedes tener el enlace si quieres. Lo hicieron colaborativamente, felicidades. Y lo que estamos haciendo es unir la API de Zada junto con las funciones serverless de Next y el CDN de Vercel. Pero el problema es especialmente que verás esto más ahora que está implementado en la red, si limitamos nuestra conexión a algo como 3G lento y recargamos esto, vamos a tener un mal momento. Porque la página se carga, pero luego está vacía. Mira esta mierda, está vacía por un tiempo. Solo porque estoy esperando los equipos, y ahora cuando obtengo los equipos, algo aparece. Esto no es ideal. ¿Cómo podemos solucionarlo? Podemos solucionarlo con enfoques de renderizado del lado del servidor en React. Me disculpo si me estoy moviendo un poco rápido, pero tenemos mucho terreno que cubrir. Y quiero que aprendas estas cosas porque son realmente importantes para serverless. Ahora, cuando estás construyendo aplicaciones en React que unen proveedores serverless, hay una gran probabilidad de que estés haciendo muchas operaciones de red, estarás haciendo muchas solicitudes a diferentes proveedores, ¿de acuerdo? Como obtener equipos, este es un ejemplo, hay una buena probabilidad de que estés obteniendo data todo el tiempo. Veremos cómo obtener data de la mejor manera. Esto no me gusta porque solo hay una pantalla en blanco de algo cargando. Y esto es una mierda. Así que solucionémoslo en localhost. Lo haremos utilizando el renderizado del lado del servidor. El renderizado del lado del servidor es bastante genial porque si miras mi pantalla nuevamente o sigues el código en vivo, en lugar de utilizar una ruta de API adicional como esta para los equipos, podemos colocar el código en nuestro propio componente React. Entonces, cualquier página en pages nos permite exportar otra función llamada getServerSideProps. Y su tipo también es getServerSideProps. Es una función asíncrona que nos permite... Wow, Copilot es increíble. Eso nos permite hacer cosas en el lado del servidor y luego pasarlas como props al lado del cliente. Entonces, lo que realmente vamos a hacer es que esta ruta de API, en realidad no necesitamos que sea una ruta de API. Podemos venir aquí a nuestra página de registro y simplemente pegar el código aquí y tomar este body del controlador y ponerlo dentro de getServerSideProps. Entendido, Dave. Ahora nuestro getServerSideProps puede obtener algunas cosas, pero no tenemos un rec, excepto que sí, es un argumento. Rec, creo que la consulta tal vez sea su propio argumento. Sí, consulta. De acuerdo, gracias. En realidad podemos simplemente deshacernos de eso.

Y ahora, en lugar de res.end, necesitamos pasarlo como props a nuestro componente. Pero si nos desplazamos hacia arriba, ¿qué tipo de props espera nuestro componente? Definámoslo. ¿Qué props tenemos? Tenemos equipos, básicamente es este tipo aquí. Entonces, ya no necesitamos el estado porque las props vienen del lado del servidor. No necesitamos toda esta mierda. Mira, oof, se vuelve mucho más simple, oh mierda, ¿necesitamos handle submit, verdad? De acuerdo, tal vez más tarde. Pero no necesitamos todo esto de carga lenta perezosa, lo que sea. Los equipos todavía están ahí, pero vienen de las props. Entonces, ahora este es un componente de función que tiene props y las props son equipos. Ahora, también podemos decirle que queremos estas props. Podemos decirle a getServerSideProps que espere esas props. Y luego, cuando retornemos, retornaremos que nuestras props son, que nuestras props son equipos. Los equipos son data. De acuerdo, esto se ve bien. ¿Todos pudieron seguir eso? Si no, hay un chat, estoy aquí. Genial. Por qué, esto está mal, solo es punto punto barra. Perfecto. Podemos eliminar el estado y los efectos y guardar. También podemos eliminar completamente esta ruta de API. No la necesitamos. Se vuelve mucho más simple.

De acuerdo. Y ahora volvamos aquí, recarguemos. Maté los hosts locales, así que iniciaremos el host local de nuevo. Y ahora, esto proviene del servidor y es jodidamente instantáneo, es el servidor finalizado. Y el beneficio de esto es que es aún mejor para SEO y cosas así porque el equipo de Ali ahora forma parte del marcado HTML generado. Como puedo ver, está todo ahí así que está listo para usarse de inmediato. Esto es muy importante, alguien arruinó el select. ¿Hiciste un map sin una clave? Deberías avergonzarte. Oye, esto no es un taller básico de React, ¿de acuerdo? Hay un ID. Vamos. Quien haya hecho eso, arréglalo. Entonces, ¿qué acabamos de hacer? ¿Hicimos que las cosas fueran más rápidas? En teoría, pero no realmente. Oh, alguien lo arregló. Gracias. Oh, de acuerdo. Las cosas están sucediendo aquí. Tal vez eso sea Julio. Eso es genial. Gracias, Julio. Perfecto, bien. Entonces, aquí está la pregunta. Pasamos de renderizado del lado del cliente a renderizado del lado del servidor, ¿de acuerdo? ¿Hicimos que las cosas fueran más rápidas? ¿Quién puede decirme la respuesta a esto? Si quieres desactivar tu micrófono, sí o no. No, no, nadie sabe. ¿Qué fue eso? En cierta medida, porque ahora todo sucede en servidores potentes. No en el navegador, pero no mucho. Sí, exactamente. En muchos casos, muchos equipos piensan que el renderizado del lado del servidor hará que tu aplicación sea más rápida. No lo hace. Mueves el spinner del navegador a tu servidor. Si tu servidor está en una red con internet más rápido, entonces ese viaje de ida y vuelta a Zara será más rápido, pero en realidad solo estás moviendo spinners y en algunos casos, el navegador es en realidad más rápido porque puedes usar el almacenamiento en caché de HTTP. De acuerdo, esa es una respuesta muy buena. Pero en realidad, cuando tenemos llamadas épicas desde el lado del servidor, generalmente tenemos nuestra API en el lado del servidor y la misma infraestructura también. Entonces, en realidad estamos beneficiándonos de reducir las latencias de estas solicitudes. Sí, de manera tradicional, sí, pero en serverless, por definición no tienes tus servidores en la misma red, ¿verdad? Así que sí, escucho eso. Hay algo de lo que debes ser consciente al hacer este tipo de trabajo con serverless, el servidor está fuera de tu, se llama VPC o tu Nube Privada Virtual. Y tendrás que tener eso en cuenta también. De acuerdo, hasta ahora todo bien. Implementemos esto ahora en producción en Vercel dash dash prod y lo haré, wow, mira qué colaborativo. Haremos commit a estos cambios y los subiremos para que puedas descargarlos. Me gusta que estemos progresando muy bien aquí. Oye, gracias a todos, por cierto, por su participación. Esto es muy divertido. De acuerdo, digamos ahora obtener equipos con SSR. Boom, push, ¿cómo va nuestra implementación? De acuerdo, implementado en producción nuevamente, vamos a verificar. Ahora, cuando recargamos, incluso en una conexión 3G lenta, no terminaremos en esta extraña pantalla en blanco que está obteniendo porque la obtención ocurre en el servidor. Entonces, cuando lo cargamos, es inmediatamente el equipo de Ali aquí. Estamos listos, nuevamente, es una recarga completa. Y así que hay algo que decir aquí porque te pregunté si esto hizo que las cosas fueran más rápidas. La respuesta es en cierta medida, probablemente no, pero también en cierta medida, probablemente sí, porque en la experiencia de usuario percibida, eso es lo que el usuario ve, ven cosas que son inmediatamente utilizables. Y eso es muy importante. Echemos un vistazo a algunos números de latencia aquí. ¿Cuánto tiempo tarda esto en cargarse? Lo que podemos ver es, desde el inicio hasta el final, siete, ¿qué? 7.9 minutos es una tontería, recarguemos esto. ¿Cuánto tiempo tarda esto? Desde el inicio hasta el final, 5.83 segundos en una conexión 3G lenta. Sí. Eso termina con las solicitudes de red, y la carga completa de la página es de 5.88 segundos con el renderizado del lado del servidor. Ten en cuenta que cuando trabajas en un entorno serverless, siempre tendrás que obtener datos de esta manera y tomar decisiones en tus aplicaciones React sobre cómo obtenerlos. Esto está bien. Creo que seis segundos es un poco lento. ¿Qué otra estrategia de carga podemos usar con serverless React y deberíamos usar? Entonces, para resumir, el renderizado del lado del cliente es genial, pero probablemente sea más lento porque dependes de la red de tu usuario, y también más lento porque cargas algo vacío primero y luego hay un spinner. No es tan bueno para la optimización de motores de búsqueda porque básicamente tienes un esqueleto que los motores de búsqueda ven. Entonces, debido a eso, cambiamos al renderizado del lado del servidor. Se llama renderizado del lado del servidor, pero lo estamos haciendo de manera serverless porque lo implementamos en la plataforma serverless de Vercel, como podemos ver aquí. Y el beneficio de eso es que el spinner se mueve al servidor. Entonces, el servidor de Vercel, no nuestro servidor, sigue siendo serverless. La obtención ocurre en su lado, y probablemente sea más rápido porque su red está diseñada para ser rápida. Además, estoy bastante seguro de que Zata y Vercel están en la misma red, probablemente por eso es instantáneo.

Entonces, ¿cuál es el beneficio? Es más rápido y también es más rápido en la experiencia de usuario percibida, y el contenido es más comercializable para los motores de búsqueda. Puedes ver el código fuente y tienes más palabras. No es solo un esqueleto, genial. ¿Podemos hacerlo mejor? ¿Podemos hacerlo mejor que los 5.88 segundos? La respuesta para este tipo de contenido es sí. En lugar de renderizado en el servidor, aún podemos construir aplicaciones React serverless utilizando renderizado estático. Esto es lo que hace Gatsby. Esto es algo que Remix no te ofrece en absoluto, y para hacer esto de forma estática, es un cambio muy pequeño. En lugar de getServerSideProps, lo cambiamos a getStaticProps, y solo por el hecho de que esta función se exporta, Next.js sabe que debe generar un sitio estático en lugar de una función serverless. Por cierto, lo que desplegamos en Vercel es literalmente una función serverless. Es una aplicación express que responde con el marcado html, ¿de acuerdo? Pero supongo, ¿podemos hacer una llamada y obtener antes de la generación? Sí. Creo que hay otra función que tiene como hidratación, ¿verdad? No, está todo aquí. getStaticProps es algo que hará una solicitud de red a Zada en este caso, obtendrá una lista de equipos. Cuando la solicitud de red finalice, luego pasará las props al componente y continuará construyendo el sitio. Entonces, ¿se deshace, verdad? Entonces, si agrego después de eso, como un equipo, no estará allí hasta mi próximo despliegue. Así que hagamos esto primero. Ya que ya no estamos en el lado del servidor, no tenemos acceso a los parámetros de consulta. Por lo tanto, no podemos filtrar. Este es uno de los compromisos entre estático y servidor. También las cookies, cualquier cosa de la cadena de consulta o cookies o encabezados, ya no los obtienes. Entonces no podemos filtrar. Probablemente sea lo mejor, se vuelve un poco más simple. Y ahora, guarda. Veamos qué, no quiero ejecutar eso. Así que volvamos aquí. ¿Cuál era el local host? Registrarse. De acuerdo. Vamos a yarn next dev. ¿Y qué va a cambiar aquí? Literalmente nada. Desde una experiencia de desarrollo local, no cambia nada. De hecho, podemos probar esto. Alguien está intentando hacer scripting entre sitios, te veo. Buen intento, pero no. Así que volvamos y, como React no permite, tienes que usar dangerously set HTML para eso. De todos modos. Así que probémoslo. Tienes el control de Live Share. En realidad puedes cambiar el código para usar dangerously set HTML. Entonces lo que voy a hacer es agregar un registro. Queso. Y ahora si vuelvo a mi aplicación aquí en local host, cuando recargo la página, aunque sea un sitio estático, se reconstruye estáticamente. O al menos debería. ¿Guardé algo obsoleto? ¿Algo en caché, algo? Sí, queso. Así que no reinicié mi servidor de desarrollo. No reconstruí el sitio. Es solo cuando recargas, cada vez que presiono el botón de recarga, Next JS hace una llamada a Zara y me da una página HTML estática localmente. Es como si estuviera ejecutando los componentes nuevamente y nuevamente, cada vez que lo refrescas. Sí. Entonces ejecuta la función nuevamente. Alguien volvió a arruinar el select, ¿en serio? Pensé que lo arreglamos. ¿Por qué? ¿Por qué harías eso? ¿Alguien deshizo la corrección? De todos modos, lo arreglé por ti. Me alegra que alguien haya aprendido algo en esta masterclass para poner claves en todas partes. Lo aprendieron por vergüenza. Estoy bromeando, no los juzgo. A veces también olvido las claves. De acuerdo, bien. Hasta ahora, todo bien. Así es como funciona localmente. Vamos a desplegar esto ahora en Vercel y ver qué sucede. De hecho, lo interesante aquí será ver los registros de construcción. Así que si inspeccionamos la construcción, esto es bastante genial. Así que si voy aquí, eso se está construyendo, en realidad veremos que hace una solicitud a Zata y luego genera archivos estáticos. ¿Ibas a decir algo, Charles? ¿No? De acuerdo. Supongo que esto sería lo más rápido. ¿Adivinaste esto? Sí, recuerdo que la última vez fueron seis segundos. Veamos. Oh, ¿lo tengo abierto en algún lugar? Este. Sí, aquí están las herramientas de desarrollo. Lo mantendré abierto. Haré una prueba en una nueva pestaña. Veamos qué sucedió. Así que notas que /signup usa SSG, generación de sitio estático. Es HTML más JSON. Y cuando llamas a Zata y obtienes props estáticas, lo que realmente hace es obtener las props como JSON y las almacena en el marcado final. Así que estamos aquí. Vamos a visitar el sitio desplegado y es /signup. Esto es un HTML estático ahora. Es simplemente rápido. Como, joder. Ni siquiera... Sí, probémoslo rápidamente aquí en la red solo para confirmar. Es una recarga completa. Sí, 2.14 segundos, oh, mierda. De acuerdo, en realidad no es... Es como 0.02 segundos más rápido. Intentémoslo de nuevo. Esta vez tal vez cuando esté en caché. Es más o menos lo mismo. Esto es realmente interesante. Tienes la caché desactivada. Probablemente por eso.

Hagámoslo aquí. Bien, estoy... Sí, 2.18. Exactamente, 2.18 segundos. Así que es un tercio de la velocidad. Creo que si deshabilitas la caché en el otro, será lo mismo. Bueno, ahora es un poco difícil... Volvamos a la configuración predeterminada. Es la caché del navegador. ¿Recibe lo mismo, verdad? Sí, sí, tienes razón. ¿Estoy en... De acuerdo, así que estoy en una conexión 3G lenta en ambos. Simplemente no limitemos la conexión y veamos qué sucede. Así que aquí, aquí. De acuerdo, son alrededor de 20 milisegundos o 10, 16 milisegundos, por así decirlo. Sí, no es realmente tan importante, pero creo que a medida que agregas más, se acumula porque la complejidad es mayor. Pero, ¿cuál es el compromiso aquí? El otro aspecto es, esto sería, esta demostración, lo que sea que estemos haciendo aquí sería mucho más rápido o más significativo si no estuviéramos en Europa. De hecho, si hay alguien aquí en Nueva York, eso sería genial porque así... Estaría muy interesado en escuchar tu historia si te sientes cómodo compartiéndola. Tal vez no. Pero ahora la fuente es la misma. Cuando intentas comparar las pestañas. Sí, la fuente es exactamente la misma. Pero, ¿quién está aquí desde Oriente Medio? ¿Puedes decir tu nombre? Sí, soy Nadav. ¿Puedes decirlo de nuevo? Nadav, como dijiste, Nadav. Nadav, sí, sí. Nadav, sí. Entonces, Nadav, en Oriente Medio tendrás más dificultades para acceder a las funciones serverless. Por lo tanto, el renderizado en el servidor en comparación con el estático. Y luego- Oh, puedes probarlo. ¿Podrías compartir el enlace? Sí, hagámoslo. Creo que esto es renderizado en el servidor. Así que te enviaré este. Boop, boop, boop. SSR es esto, y el estático es esto. Así que mi hipótesis, solo por el enfoque serverless, es que el renderizado en el servidor será un poco más lento, probablemente no de manera significativa, porque al final del día, es una página simple, pero aún notablemente más lento, porque- Oh, tenemos buena conexión aquí. Sí, en línea, pero oh. Sí, no se trata de... Lo sé, crecí en Oriente Medio, por cierto, en Catali. Pero el problema es que con SSR, esto es importante para serverless, es importante que sepas dónde está el servidor. Si usas el renderizado en el lado del servidor en la aplicación Next.js implementada en VRSL, tu aplicación renderizada en el servidor se servirá desde US East, siempre. Por lo tanto, cuanto más lejos estés de US East, más lento será. Y no hay forma de evitarlo. Entonces, si estás en Australia, tendrás problemas. La función serverless, exactamente. Por otro lado, el estático es aproximadamente un cuarto del tiempo, tal vez incluso menos. El estático es como 75 milisegundos. Sí, lo mismo aquí. Y el SSR es de 352 milisegundos. ¡Maldición! ¿Escuchaste eso? Entonces, aquí es donde, nuevamente, querías recetas, querías ideas para obtener datos de forma serverless. Serverless, te encontrarías con serverless al tener que saber dónde está el servidor. Así que, hey, ¿puedes escribir los números? Oh, espera, lo siento. No deshabilitaste la caché antes. Así que solo veamos. Está bien. ¿Puedes escribir los números en el chat? Claro. Gracias. Esto es lo que está sucediendo. Para el renderizado en el servidor, si estás en Oriente Medio, si estás en Australia, tienes que hacer una solicitud hasta Nueva York o US East, donde sea que esté el centro de datos. Para el estático, tendrás que hacer una solicitud al nodo CDN más cercano, tu punto de presencia más cercano. Por diseño, el estático es mucho más rápido, eso es más de 100 milisegundos de diferencia en un DAV. Vaya. Y más de 300 milisegundos en el otro caso, sí. El estático siempre es más rápido que el SSR porque los CDN están distribuidos globalmente y los tiempos de ejecución de las funciones serverless no lo están. Esto está cambiando. Vercel tiene una nueva oferta llamada Edge Functions. Cloudflare tiene, tienen workers que están distribuidos globalmente. Así que esto no es, esta es una decisión que tendrás que tomar cuando trabajes con aplicaciones React y serverless es dónde está el servidor y si está distribuido globalmente. De acuerdo. Es realmente importante que lo sepas. Quiero decir, viendo estos números, voy a tomar una foto de esto, esto es realmente importante, pero aquí está lo interesante, el tiempo de ejecución de la función serverless de Vercel, donde ocurre tu SSR, y Zadah están en regiones muy cercanas. Entonces, Nadav, por ejemplo, viniendo de Oriente Medio, lo que tu aplicación está haciendo es que estás hablando con Vercel, Vercel está llamando a Zadah y luego tu página vuelve a ti. La llamada de Vercel a Zadah es rápida porque Zadah y Vercel están cerca. ¿Lo entiendes? El próximo año hay planes para distribuir Zadah globalmente también. Entonces, no importa desde dónde llames, será rápido. Bien. Esto es algo en lo que tendrás que pensar cuando construyas aplicaciones React con serverless porque ahora, digamos que agregamos autenticación con un servicio como Auth0, tendríamos que elegir qué host de Auth0 usar. Auth0 sería aún más complicado debido al GDPR. ¿Dónde almacenamos las direcciones de correo electrónico? Si tienes clientes en Europa, tu servidor debe estar en Europa. Su servidor debe estar en Europa. Y las personas que se encuentren a distancias geográficas tendrán mala suerte. Hasta ahora ha sido bueno. Continuemos. Ahora esto está implementado como un sitio estático. Agreguemos otro equipo. Llamémoslo Nadav en honor a Oriente Medio. Pero, ¿no estamos un poco limitados en SSD, supongo? Sí, cuéntame más, ¿por qué? Sí, como simplemente eliminaste los patrones de seguridad. Sí, lo estamos. Pero en este caso no necesitamos programas de consulta.

Pero sí, no tienes acceso a programas de consulta, no tienes acceso a cookies, no tienes acceso a encabezados HTTP si haces SSG. Así que estamos muy limitados. Es un intercambio. Obtienes velocidad pero no obtienes cosas como cookies y encabezados.

Y luego estamos como, ¿qué pasa con los blogs estáticos, verdad? El sitio que no cambia esto. Pensarías, sí, estás llevando a la siguiente sección. Permíteme responder esto de una manera larga mostrándote algunas cosas.

Ahora estoy agregando un equipo. Creé el equipo de Nadav. Voy a mi cosa renderizada en el servidor, recargo, no lo veo. Podría recargar 100,000 veces, nunca lo veré porque es un sitio estático, como solo HTML. No tiene forma de saber, como, hey, hay nuevos datos. Y esto es más o menos lo que estabas diciendo, como, entonces SSG es genial para blogs estáticos y cosas así. Pero se vuelve un lío cuando los datos cambian. Si sabes cómo solucionar esto y obtener los beneficios de rendimiento de SSG, ponlo en el chat. Es como, sí, ¿por qué no dijo que sí? Y si no sabes la respuesta, ¿por qué quieres ponerla ahí? Siento que esa es una respuesta que necesito saber. Esa es una respuesta que quiero saber.

Espera, veamos qué sucede cuando paso a la siguiente diapositiva. Resulta que tengo un bucle de tiempo de ejecución. Así que eso mata todos mis datos. Entonces voy a decir cómo construir a un servidor. Sí, puedes ver que hay un nuevo bucle allí, como para verificar los datos y los cambios de uso, y sigo ejecutando el ISR. ¿Puedes cambiarle el nombre de nuevo a la función de borde? Sí, sí, llegaremos a eso. Alguien, si tu micrófono no está destinado a estar encendido, es posible que lo estés usando. Julio, ¿te sientes cómodo convirtiendo esto en una página ISR o debería hacerlo yo? Sí, en realidad no lo recuerdo. Está bien, aquí, así es como lo hacemos. Todavía usamos getstaticprops, pero agregamos una cosa, que es vamos aquí, gracias a TypeScript, revalidate, true. Eso es todo, ahora es oficialmente ISR. Si implementamos esto, tomará unos segundos. Pero ahora lo que va a suceder es cada vez que visites la página, se ejecutará esta función. Hará una solicitud, obtendrá nuevas props, reconstruirá la página en segundo plano. Y la próxima persona que acceda a la página obtendrá los últimos datos. Utiliza un mecanismo llamado aquí, déjame mostrarte, web.dev obsoleto pero revalida, se inspiró en esto. Si no lo has hecho- ¿Tiene un tiempo de espera? Si lo configuras en true, el tiempo de espera es inmediato, pero podrías hacerlo como- Trescientos milisegundos si quieres. Yo lo pongo en true, quiero decir. Ya sabes. Eso es en realidad 300 segundos. Milisegundos. No puedes decirle que se actualice cada 300, ¿son segundos o minutos? Son segundos, los milisegundos no tienen sentido. Sí, tienes razón. Se inspiró en este obsoleto pero revalida, que en sí mismo es un gran mecanismo de caché. Cómo funciona es que si hay una respuesta obsoleta aceptable, la obtienes de inmediato. Mientras tanto, el navegador envía una solicitud para obtener más información en segundo plano. Esto aplicado a serverless es lo que se llama ISR. Así que se ha implementado y ahora se reconstruye el sitio. Así que deberíamos tener un equipo de AWS. Increíble. Pero es un sitio estático. Así que agreguemos otro. Hagamos un Guillermo, si puedo escribir. Entonces ahora lo que va a suceder es que recargo la página así. Ahora no lo tenemos. Porque lo que sucedió fue que enviamos una solicitud a Zata. La página se cargó. Enviamos una solicitud a Zata. Estamos obteniendo las cosas, se está reconstruyendo. Y si recargamos, si alguien viene ahora nuevamente al sitio, entonces obtienen los últimos datos y tenemos cosas. Eso no se suponía que... Deberíamos tener a Guillermo en algún momento si realmente se implementó, que parecía que sí. Sí. Tal vez solo está tardando un poco. Podemos ir a inspeccionar. Veamos qué está sucediendo aquí. Así que la implementación de producción tiene funciones. Registrarse. Vamos a solicitarlo. Genial. Literalmente no está sucediendo nada. Por cierto, esto es por qué fue lento para ti porque esta función se llama desde Washington, DC. Entonces, si estás en Oriente Medio, estás un poco jodido. De acuerdo, ¿qué está pasando? ¿Por qué no veo? Eso no está sucediendo como quiero que suceda. No lo sé. ¿Alguien tiene alguna idea? Intenta con Cognito. Lo siento, ¿qué? ¿Agregaste a Guillermo, o solo escribiste su nombre? No, lo agregué aquí mismo. Oh, está bien. Debería estar debajo, en realidad, vayamos a localhost y probémoslo. No voy a reconstruir el sitio. Eso lo sé con certeza. Estoy seguro de que solo hay algunas solicitudes de red que están tardando. Vamos a localhost. Intenta con Cognito. Sí. Tal vez esté en caché. No creo, tal vez esté relacionado. ¿No? ¿Lo mismo? Tal vez podamos cambiar revalidate a uno. Pero esto es realmente inusual. También para mí no veo a Guillermo Tagliati. No hay problema.

Vamos a reconstruir el sitio y luego agregaremos otro. Pero revalidar uno debería darnos, a menos que estemos almacenando en caché cosas en el cliente de Zara, lo cual podríamos estar haciendo, pero generalmente eso es inesperado. Por cierto, así es como construimos nuestra documentación. Entonces, la documentación es completamente ISR. Y parte de esto, así que todo esto viene directamente de GitHub, ni siquiera escribimos esto. Lo que significa que siempre está actualizado con el código, por lo general, es bastante genial.

Bien, entonces el sitio debería reconstruirse y deberíamos ver a Guillermo, porque se está reconstruyendo. Sí, lo vemos. Pero probemos el ISR y agreguemos otro. Lo agregué completamente. Quiero que SSR haga las cosas de SSR o ISR. Sí, esto es interesante. No tengo idea de qué está pasando. Creo que tal vez, no usemos- No veo la verdadera cosa. Quiero decir, miro la documentación y no especifican el verdadero. Sí, acabo de implementarlo con uno. Pero creo que podría ser solo para descartar el SDK de Zadar, hagamos esto y copiemos el fragmento de código desde el propio navegador. En lugar de registrar el resultado en la consola, simplemente lo asignaremos a una constante- Creo que es records igual. Entonces, esperar, ¿verdad? Creo que solo probemos este fragmento aquí en el navegador para ver si funciona. Y estamos usando una clave de API temporal. Solo quiero descartar, el, cómo se dice, el cliente de Zadar podría ser eso. Todavía está en beta. Bien, tenemos meta, tenemos records y records son nuestros equipos. Entonces, sí, esto se ve bien. ¿Funciona en localhost? Haz tu next dev. ¿Estoy incluso instanciando el cliente de Zadar? No necesito esto. Bien. Entonces, sí, está funcionando. Estoy recuperando. Todo está bien. Así que, implementaremos esto ahora solo para ver qué sucede. Porque fetch, quiero decir, fetch solo debería obtener. No estamos haciendo nada. No estamos haciendo ningún almacenamiento en caché. Esto se ve exactamente como lo que quieres. Entonces, nuestro nuevo sitio aquí, tendremos, ups, lo siento por eso. Tendremos a Khaled, y luego probaremos ISR. ¿Estoy usando la URL correcta? Eso es bueno. Oye, David, gracias por estar aquí, hombre. Espero que hayas disfrutado de la masterclass. Bien, en este punto tenemos a Khaled, es perfecto. Agreguemos a Gabe. Entonces, si actualizamos, se reconstruye en segundo plano. Actualizamos de nuevo. Sí, ahora tenemos a Gabe. Entonces, bueno, no hay un cliente que lo arruine, pero ISR funciona. Es solo que nuestro SDK almacena en caché cosas, supongo. Genial, espero que eso lo aclare.

Bien, tenemos esto, y podemos obtener data de múltiples formas, teniendo en cuenta la latencia. Creo que lo más importante que debes considerar cuando estás construyendo aplicaciones React, por cierto, siéntete libre de agregar equipos en Zadah, y luego actualizaré la página y se regenerará con ISR. Entonces, agregué a Khaled y Gabe, pero si quieres, siéntete libre de jugar tanto como quieras, y al final actualizaré el formulario aquí. Entonces, ¿qué hemos visto? Hemos visto funciones serverless, hemos visto múltiples estrategias de recuperación de React, creo que para mí personalmente, lo más valioso que he visto son los números de SSG versus SSR versus renderizado del lado del cliente. Gracias por compartir eso, aquellos de ustedes en el Medio Oriente, es bastante importante, pero eso es esencialmente, mi batería está a punto de agotarse, pero tengo un cable en algún lugar, está bien. Esa es la esencia de la aplicación. Trabajando con serverless. Ahora, si quisiéramos agregar autenticación, autorización, ¿cómo lo haríamos? Usaríamos un proveedor serverless, probablemente el más famoso es Auth0, y te brindan una API completa que implementa OAuth. Lo conectaríamos aquí en nuestra aplicación, y tendríamos Auth. Entonces, la idea es, volviendo al diagrama, esto es de Vercel, esto es de Zada, y si tenemos otro color, vamos a copiar, sí, vamos a copiar esto aquí. Ah, es hora de conseguir mi cable. Permíteme avisarle a mi esposa. ¿Puedo conseguir el cable, por favor? Lo tienes. Tan increíble tener una esposa. Es como un sistema de entrega de cables. Y más. Enfócate en el más. Sí. Gracias. Entonces, enchufemos esto. Oye, no hay problema Jose, te aprecio. Entonces, si quisiéramos hacer autenticación, esto se convertiría en solo otro servicio que no gestionamos. Permíteme escribir eso correctamente. Cambiemos el color solo por consistencia, ¿verdad? Y luego nuestra aplicación, nuestro sitio en realidad hablaría con eso. Entiendes la idea, esto es la esencia de serverless. Entonces estamos obteniendo Zada desde la API solo porque no queremos filtrar la clave. Pero por ejemplo, con Auth0, es posible que se te permita obtener directamente desde tu cliente o quien sea, pero mi sitio en sí es bastante liviano y sin estado. Quiero mostrarte dos cosas más antes de terminar y luego podemos dar por terminado el día. Zada es genial porque es rápido. Oh, ¿agregaste algunas cosas? Vamos a recargar aquí. Bien, se está reconstruyendo en segundo plano. Deberías ver que Carla y Gabe se reconstruyen. Tenemos Team Vikings y Null, así que funciona. ISR, no hice nada. Por eso ISR es genial. También deberías tenerlo si quieres visitar. Bien, quería mostrarte un par de cosas más y luego podemos dar por terminado. Número uno, bajo una bandera de características en Zada, puedes acceder yendo a /flags y habilitándolo para ti mismo. Esto desaparecerá, así que no te acostumbres. Pero si habilitas el playground, puedes consultar directamente Zada desde aquí en una interfaz de estilo Visual Studio Code. Entonces puedes hacer cosas como zada.db.users.getall o .teams.getall.

Y en realidad usamos esto internamente mucho. Así que si vamos a nuestro blog aquí, a veces, ya sabes, solo para tener una competencia o algo así, vamos aquí y en contra de la producción data, literalmente puedo filtrar donde el nombre del autor es el mío y ver cuántas publicaciones de blog escribí. En realidad es una clave de API global, lo siento. Clave de API de Zada, sí. Y así escribí dos publicaciones de blog, puedo ver cuántas escribió mi CEO, y también son dos.

¿Qué estás usando para el Editor de Código en Zada? Sí, se llama el Editor Monaco. En realidad es el mismo editor de Visual Studio Code, es de código abierto de Microsoft y es esto, eso es una lección para ti. Así que también podemos hacer esto con Zada, esto es seguro en cuanto a tipos, así que si ves mi pantalla y arruino el nombre de la columna, es como que no puedes hacer esta consulta. Es bastante cómodo de usar y luego, por supuesto, si obtengo esta consulta aquí, puedo ir a mi aplicación, pegar el código y simplemente funciona.

Eso es una cosa, la otra cosa es que todo lo que hicimos con la CLI y la interfaz web, para Zada como una base de datos serverless, en realidad también podemos hacerlo desde Visual Studio Code aquí. Así como te mostré la interfaz web y eso, realmente no tuve que hacerlo. Así que si vamos a Zada learning, también hay bases de datos tuyas y si miramos la base de datos principal, podemos ver los equipos, por ejemplo, que hiciste y esa es la versión JSON de tus equipos de todos modos y creo que la etiqueta de script de alguien está arruinando Visual Studio Code. Buen trabajo, tu cross site scripting realmente funcionó pero no en nuestra interfaz. También podemos insertar registros así que puedo agregar un usuario directamente aquí. Así que agregaré a alguien de 23 años llamado tú y puedo insertarlo directamente desde aquí y luego puedo si veo usuarios, puedo abrirlo en Zara. ¿Se insertó siquiera? Mierda, no ves nada. Esa extensión de Visual Studio Code es muy experimental así que ni siquiera la enviamos todavía. De hecho, tienes que construirla desde el código fuente. Viste por qué. Esas son dos cosas.

Lo último es que la base de datos es completamente ramificable lo cual creemos que es realmente genial porque con el tiempo querrás hacer cambios en tus datos y realmente no quieres hacerlo de manera insegura. Así que si vamos a esta base de datos principal y en nuestra lista de características de la que en realidad no obtuvimos nada aquí, tal vez queramos notas de reuniones. Quieres agregar eso como una tabla. Podemos hacerlo de manera insegura arruinando la rama principal o podemos hacerlo de manera segura creando otra rama. Cómo hacemos eso es aquí si estamos en este proyecto. Lo siento, lo que puedo hacer es obtener el estado. Puedo crear una nueva rama. Así que crearé una nueva rama, llámala reuniones, ¿de acuerdo? Y en las notas de reuniones, si vuelvo a mi código, lo que puedo hacer es, no guardar. Lo que puedo hacer es ir a mi carpeta de Zada y cambiar el esquema. Así que schema.json. Aquí ya hay dos tablas. Solo haré otra tabla. Diré que tengo una tabla cuyo nombre es notas de reuniones. Esto es JSON con opiniones. Y las columnas son un arreglo de columnas, ¿verdad? Así que las columnas tienen un nombre, que es texto y un tipo, que es cadena. Y te ofrecemos autocompletado donde puedas. Eso básicamente coincide con cada columna que tenemos aquí. Así que eso se ve bien. No estoy seguro de por qué está en rojo. Necesita dos puntos. ¿Por qué? Ah, lo tengo. Así que hice una nueva tabla notas de reuniones y estoy en una nueva rama reuniones. Así que aquí, si ejecuto Zada deploy, dice, mira, tu base de datos no tiene una rama llamada reuniones. ¿Quieres comenzar una nueva rama? Sí. ¿Desde qué rama debería bifurcar la nueva rama? Principal. Y ahora hemos literalmente creado una nueva rama de base de datos. Dice, así que para esta rama reuniones, ¿quieres agregar otra tabla notas de reuniones, sí o no? Sí. Así que ahora realmente tenemos otra rama llamada reuniones. Podemos verla en la interfaz web y esta rama tiene una tabla adicional completa. Así que la rama principal sigue segura. Mis usuarios la están usando, está bien. Pero si quiero experimentar, voy a esta rama, tengo notas de reuniones, puedo trabajar toda mi característica en esta rama. Y en algún momento cuando la fusiono con la principal, es simplemente una fusión sin tiempo de inactividad, ¿de acuerdo? Y así también hacemos que las bases de datos sean mucho más seguras porque si alguna vez has tenido que migrar una base de datos en producción con cientos de usuarios, es un poco aterrador.

Esa es una buena pregunta, Nadav. Las migraciones de datos son realmente geniales. Se manejan para tus usuarios. No hay tiempo de inactividad percibido. Este es realmente el beneficio de tener una base de datos sin servidor, ¿verdad? Porque interactúas con una API. Así que gestionamos las migraciones y demás. Entonces, cómo funciona es, si tienes una base de datos enorme, cuando llega una solicitud a nuestra API, sabemos, porque ejecutamos los servidores, sabemos, eh, un servidor está en ejecución y hay una migración en progreso, ¿qué hacemos? Y tomamos decisiones al respecto. A veces podemos crear un clon de tu base de datos y enviarlo a ambas bases de datos, una con el esquema más nuevo, otra con el anterior, y así sucesivamente. Esa es una gran pregunta. Las alternativas a Zada, personalmente no conozco ninguna otra base de datos sin servidor centrada en la experiencia del desarrollador. Como una base de datos sin servidor que me brinde esta interfaz con el cliente de TypeScript, el playground, la extensión de VS Code, nada. No hay alternativa para eso. Pero hay algunas que se centran en la experiencia del desarrollador, ¿verdad? Probablemente la alternativa más cercana sea Superbase. Tal vez hayas oído hablar de ellos como un Firebase de código abierto. Te brindan una base de datos Postgres alojada. Sí, Firebase, creo, no sé, creo que Firebase no es de código abierto, pero Firebase o Superbase es probablemente lo más parecido porque simplemente obtienes una base de datos alojada. Los compromisos, por supuesto, son con eso, es muy opinado, es como Postgres. Así que tienes que saber SQL y tienes que pensar en eso. Tampoco te brinda una búsqueda. Oh, mierda, ni siquiera hablamos de eso. Permíteme compartir mi pantalla, pero por favor sigue haciendo preguntas porque no nos queda mucho tiempo y realmente quiero que obtengas algo de esta charla, de este taller. Creo que Ali tiene un punto válido. ¿Qué fue eso? Ali tenía una pregunta, puedes verlo en el chat. Oh, ¿cómo, Ali, ISR es muy genial, pero algunos usuarios obtendrán datos obsoletos, puede ser un poco extraña la experiencia del usuario ya que no verán el tema más nuevo sin actualizar. ¿Solucionar esto, agregarías lógica para cargar una lista más actualizada después de la carga inicial de la página, sí, exactamente, eso es exactamente lo que haríamos porque entonces tu sitio estático aún se sirve, pero aún harías otra solicitud, no te cuesta nada, especialmente si es pazada, estás bien, puedes hacer tantas solicitudes como quieras. Exactamente, eso es bueno, eso es, has respondido tu propia pregunta. Sí, especialmente por esto, como el select tiene opciones, ¿verdad?, así que ni siquiera ves un destello ni nada. En algunos casos, si es un blog y tus datos están realmente obsoletos, entonces verás un destello de contenido tal vez, pero de lo contrario, no. Usar SWR e ISR es una de las mejores ideas que tendrás, especialmente porque ambos provienen de Vercel, por lo que pueden ajustar los detalles y demás. Lo último que quería mostrarte, y ninguna otra compañía lo hace, es que obtienes un motor de búsqueda completo de inmediato. Como puedes buscar, no sé, ¿cuál es la API? No sé, ¿son objetos en tecnología? Ni siquiera sé cómo hacer esto. Hola, ¿qué quieres? ¿Funciona esto? ¿No es cómo buscar una función? ¿Es db.search? Supongo que es, ¿sabes qué? Lo intenté. Punto, ah, oh, está bien. Sin servidor. Wow, estoy sorprendido por esto mismo. Podemos buscar en todas las tablas y columnas la palabra sin servidor, y obtenemos todos estos resultados. Podemos buscar en todas o por tabla. Entonces el nombre de la tabla es simplemente, por ejemplo, Opciones de Publicaciones, y tenemos tablas, y esto es una matriz de tablas, y también podemos especificar la tolerancia. Oh, así que si es una coincidencia aproximada, aún obtendremos resultados y así sucesivamente. Oh, lo siento, solo esto, supongo. Cuatro, entre 0 y 2, está bien, 1. Sí, motor de búsqueda completo, base de datos completa. Este diagrama, exactamente, ¿dónde está? Este aquí. Sí, todo esto. El rojo es base de datos, Kafka, motor de búsqueda, todo está hecho. El objetivo es si quieres construir una aplicación, cualquier aplicación, una aplicación de citas, una aplicación de música, lo que sea que necesite una base de datos, simplemente todo es instantáneo. Obtienes herramientas agradables y cómodas y desaparecen, y creo que hemos explorado eso hoy. Sí, con un minuto para ir, creo que lo dejaremos aquí, cualquier comentario, pregunta, comentario, elogio previo. Solo tengo una última cosa allí, si puedes explicar por favor lo de las funciones de borde. Sí, bien, sí, ¿cuál era tu pregunta al respecto? Es difícil, no puedo entender las funciones de borde. ¿Qué hacemos exactamente? Era como desde servidores regionales, ¿verdad? Sí, sabes cómo un CDN es una red distribuida globalmente de servidores estáticos que te brinda HTML, ¿verdad? Gracias por los comentarios, todos. Lo aprecio mucho. Gracias, si te gustó, tuitea. Apreciaría solo un agradecimiento o algo en Twitter, para poder seguirte también. Sí, Taimur, es como un CDN que sirve contenido desde una computadora estática cerca de ti. Las funciones de borde son lo mismo. Es una computadora cerca de ti que puede ejecutar tu función sin servidor. Eso es, funciones de borde, mientras que ahora la alternativa a las funciones de borde es que todo se ejecuta en EE. UU. Este, Washington DC. Sí, las funciones de borde son ejecuciones de funciones distribuidas globalmente.