1. Introducción a Durable Objects
Vamos a empezar. Gracias, Kevin, por esta maravillosa introducción. Hoy no vamos a hacer diapositivas. Vamos a hacer codificación en vivo. Así que hoy quiero hablarles de algo llamado Durable Objects, que es un mal nombre para algo realmente genial. ¿Puedo ver un show de manos? ¿Quién aquí antes de venir a esta charla ha oído hablar de lo que son los Durable Objects? Tenemos unas 10 manos. Y mantén la mano levantada si realmente has ejecutado Durable Objects en producción.
Vamos a empezar. Gracias, Kevin, por esta maravillosa introducción. Es un trabajo ingrato ser un MC. ¿Podemos tener un aplauso para Kevin y los MCs también? Sí. Me encanta ser parte de estas conferencias. He sido parte de casi todos los React Debriefing en el pasado. Y es mi primera vez hablando. Y no hablo muy a menudo porque odio hacer diapositivas. Así que hoy no vamos a hacer diapositivas. Vamos a hacer codificación en vivo. Pero porque cometí el error de nombrar esta charla todo, en todas partes, todo a la vez. Pensé que podría haber algunos aficionados al cine allí. Así que puse una diapositiva al principio sólo para que la gente no se enoje conmigo por no, ya sabes, poner las diapositivas. Así que esta es la diapositiva. Es una animación de keynote. Mírala. Es hermosa. Ahí. Wow. Mira eso. Wow. Bien. Así que hoy quiero hablarles de algo llamado Durable Objects, que es un mal nombre para algo realmente genial. Así que este año, como todos los años al final del año, reflexiono sobre lo que he estado trabajando de manera diferente este año. ¿Cuáles son algunas de las nuevas herramientas y prácticas que han mejorado, ya sabes, mi capacidad para hacer mi trabajo como ingeniero. Y Durable Objects es uno de esos descubrimientos de este año que realmente quiero compartir con ustedes. ¿Puedo ver un show de manos? ¿Quién aquí antes de venir a esta charla ha oído hablar de lo que son los Durable Objects? Bien. Tenemos unas 10 manos. Y mantén la mano levantada si realmente has ejecutado Durable Objects en
2. Introducción a los Durable Objects de Cloudflare
Bien. Entonces, como dos o tres personas. Genial. Esto es exactamente lo que esperaba. Durable Objects es una tecnología de una empresa llamada Cloudflare. Es una empresa de tecnología realmente genial, pero no son realmente buenos explicando a la gente cómo usarla o vendiéndola o algo así. Así que pensé que en lugar de intentar explicártelo, simplemente te voy a mostrar cómo funciona. Cloudflare es una de las mayores empresas de infraestructura de Internet, conocida por sus servicios de CDN, caché, proxy y defensa contra bots. Tienen una plataforma de desarrollo llamada Workers, donde puedes ejecutar código sin servidor. Los trabajadores de Cloudflare se ejecutan en cada una de sus 300 ubicaciones de servidores, lo que hace que los servicios sean extremadamente rápidos. Durable Objects es un paradigma de programación versátil, que pronto te demostraré.
en producción. Bien. Entonces, como dos o tres personas. Genial. Esto es exactamente lo que esperaba. Y no te preocupes, esto no es tu culpa. Es culpa de
Cloudflare. Así que primero, un pequeño preámbulo. Durable Objects es una tecnología de una empresa llamada
Cloudflare. Yo no trabajo para
Cloudflare. Solo soy un fan entusiasta. No me pagan por ello. Ni siquiera revisaron mis diapositivas, así que todo podría estar incorrecto. Pero por otro lado, puedo decir lo que quiera sobre
Cloudflare. Y lo que pasa con
Cloudflare es que es una empresa de tecnología realmente genial, que tiene una tecnología realmente genial, y no son realmente buenos explicando a la gente cómo usarla o vendiéndola o algo así. Así que pensé que en lugar de intentar explicártelo, simplemente te voy a mostrar cómo funciona. Bien, así que esto es
Cloudflare. Si no has oído hablar de esta empresa, es una de las mayores empresas de infraestructura de Internet. Puede que los conozcas como un proveedor de CDN, como un proveedor de caché, proveedor de proxy, defensa contra bots, cosas así. Pero más que eso, tienen una plataforma de desarrollo perfectamente maravillosa llamada Workers, donde puedes ejecutar código
serverless, al igual que
Lambda. Pero a diferencia de
Lambda que generalmente se ejecuta en una sola ubicación o zona de disponibilidad, dependiendo de cómo lo configures, los trabajadores de
Cloudflare se ejecutan en cada una de sus 300 ubicaciones de servidores que tienen alrededor del mundo. Y automáticamente en su red, básicamente solo dirigen tu solicitud al más cercano. Así que esto significa que gracias a que estas cosas están cerca, generalmente estos servicios son extremadamente rápidos. Pero si vamos a este sitio web de la plataforma de desarrollo, detrás de aquí, debajo de estos Workers, hay una sección llamada durable objects. Y aquí, si vamos, podemos descubrir qué son los durable objects y qué hacen. Y recuerda, yo no trabajo para
Cloudflare. Y nos dicen que podemos construir aplicaciones colaborativas, como salas de chat, juegos, pizarras. Esto es realmente genial. Me encanta jugar juegos, como construir juegos y salas de chat y pizarras. Pero en realidad, la mayoría de nosotros no tenemos la oportunidad de construir este tipo de software en el día a día. Y esto es, creo, la mayor subestimación de lo que son los durable objects, es que ellos
3. Construyendo una Aplicación y Ejecutando el Desarrollo Local
Al explorar esta tecnología, considera sus posibles casos de uso más allá del tema actual. Construiremos una aplicación juntos y revisaremos nuestra comprensión al final. Únete a nosotros escaneando el código QR o visitando do-it.pages.dev. Estoy ejecutando el desarrollo local de Wrangler y un despliegue en segundo plano. Comencemos con una demostración de contador.
son realmente un paradigma de programación versátil, que pronto te demostraré. Pero cuando hagas esto, cuando pasemos por esto, ten en cuenta, ¿para qué más podrías usar esta tecnología? Y al final, lo discutiremos. Pero, ya sabes, no te obsesiones con esto. Pero vamos a desplazarnos hacia abajo. Así que llegas a mantener estados. Bueno, eso es algo. Escalar y demandar suena a marketing. Cómputo incrustado, no tengo idea de qué están tratando de decirme aquí. Así que creo que lo que haremos es que construiremos una pequeña aplicación. Todos podremos jugar con ella juntos. Y luego al final, volveremos a la misma página. Y luego veremos si realmente entendemos lo que es esto. ¿Está bien? Muy bien. Hagamos esto. Así que nos he preparado una pequeña aplicación. Si quieres unirte a nosotros en esto, puedes escanear este código QR. Y básicamente puedes jugar en tus teléfonos. Si te unes a nosotros a través de la transmisión en vivo, también puedes ir a do-it.pages.dev en tu computadora o lo que sea para unirte. Bien. Así que comencemos. Aquí en la parte inferior, estoy ejecutando dos procesos. Uno de ellos es mi entorno de desarrollo local de Wrangler. Este es el entorno de desarrollo de CloudFlight que me permite ejecutar trabajadores
serverless, cosas así. Y luego ejecutando un despliegue en segundo plano. No iniciado sesión. Eso no suena bien. Ejecutemos eso de nuevo. Y así cada vez que guardo cualquier código, también se desplegará a
CloudFlare. Así que también podrás disfrutar del mismo código unos segundos después, tal vez cinco segundos después. Así que comencemos. Creo que la primera demostración de tecnología que siempre necesitamos
4. Haciendo que el Número Aumente
Hagamos que el número aumente. Establecemos el valor en cero y lo guardamos. La aplicación se convierte en un botón, y en unos segundos, tu aplicación también debería convertirse en un botón. El código se ejecuta en Frankfurt.
para construir cualquier aplicación es un contador, un número que aumenta. Ese es también el punto de la mayoría de las estafas de crypto. Pero luego el número sigue bajando. No sé qué está mal con eso. Pero aquí hacemos como un honesto número que sube donde simplemente decimos, digamos que el valor es cero. Y luego, si lo guardo aquí, veo que esta aplicación se convierte en un botón. Y en unos segundos, tu aplicación también debería convertirse en un botón. Así que estoy controlando tus teléfonos desde aquí. Y lo que también vemos es que estamos devolviendo este colo. Este es el lugar donde se ejecuta el código. Entonces, si vuelvo a este final de
CloudFlare, vemos que
5. Creando una Clase Contador con Objetos Duraderos
Vamos a hacer esta aplicación de contador. Incrementamos el número en una solicitud POST y devolvemos el contador. El número aumenta cuando se hace clic en el botón. Sin embargo, diferentes dispositivos muestran diferentes números debido a la naturaleza de los entornos de ejecución sin servidor. Aquí es donde entran los objetos duraderos. Nos permiten aprovisionar entornos de servidor con estado y direccionables de manera única. Vamos a crear una clase contador con una variable de instancia y un constructor.
este código se está ejecutando actualmente en Frankfurt. Así que comencemos. Vamos a hacer esta aplicación de contador. Así que si recuerdo cómo programar, tenemos algún tipo de variable. Y digamos que es un número. Y luego digamos que si estas solicitudes suben, eso no es donde va. Si esta solicitud, por ejemplo, es una solicitud POST, entonces incrementemos ese número así. Y luego devolvamos ese contador. Y ahora, aquí en mi final, puedo pulsar este botón y este número subirá. Y en sus teléfonos, en unos segundos, si pulsan el botón, el número también subirá. ¿Alguien puede darme un grito cuando su número empiece a subir? Muy bien, genial. Suena bien. Por cierto, puedo ver que hay 50 personas actualmente conectadas a la aplicación. No sé si todos están en la sala o si algunos de ellos están en la transmisión en vivo, pero gracias por unirse a nosotros. Ahora, el número sube es realmente genial. Pero si comparas el teléfono de la persona que tienes al lado, ves un número diferente. ¿Por qué es eso? Lo más probable es que también estés conectado a Frankfurt, pero estamos viendo un número diferente. ¿Por qué es esto y por qué es un problema? Bueno, porque la forma en que los entornos de ejecución
serverless suelen funcionar es que para cada solicitud, básicamente iniciamos un nuevo entorno de muy corta duración. En el caso de los objetos duraderos o los trabajadores de CloudFlight, es un aislante V8, similar al WebWorker, donde podemos ejecutar código
JavaScript o
Wasm o cosas así. Pero el problema aquí es que todos obtenemos un entorno de ejecución diferente, lo cual es bueno para la
security y el aislamiento, pero no es realmente genial para las aplicaciones colaborativas. Y también ves que el número se volvió cero aquí. ¿Por qué ocurrió eso? Bueno, este número sube por accidente porque
CloudFlare optimiza los recursos y mantiene la cosa en memoria durante un tiempo. Pero después de 10 o 15 segundos de que yo esté parloteando por aquí, ellos lo desactivarán. Entonces, ¿cómo hacemos para que todos podamos ver el mismo número? Bueno, comencemos con eso. Así es donde entran los objetos duraderos. Así que en lugar de simplemente tener una función que toma una solicitud y una respuesta, somos capaces de básicamente aprovisionar estos entornos de servidor de corta o larga duración, que son con estado, luego direccionables de manera única, y todos podemos conectarnos a ellos al mismo tiempo. Así que comencemos con eso. Así que vamos a hacer una clase contador. Y si recordamos nuestro
JavaScript, podemos tener una variable de instancia aquí. Y luego en lugar de usar esa variable, simplemente incrementaremos esa instancia. Y justo antes de que avancemos cualquier más, permítanme también agregar este constructor aquí porque lo vamos a necesitar en un
6. Implementando una Clase e Instanciando Instancias
Ahora hemos implementado una clase que nos permite hacer solicitudes e instanciar múltiples instancias de ella utilizando identificadores únicos. Cada solicitud se reenvía a la correspondiente instancia de objeto duradero, lo que resulta en el incremento del número. Esto se puede mejorar para crear un ejemplo de contador más emocionante y versátil.
un poco. Ahora hemos implementado una clase. Aún no la he guardado, así que nada sucederá. Esto parece bastante normal
JavaScript, excepto que puedes hacer solicitudes a esta función. Eso es bastante genial. Pero para instanciar esta clase, también necesitamos hacer algo más, que es que necesitamos básicamente decidir a qué instancia de esta clase nos conectamos todos. Y la forma en que podemos hacer eso es que podemos tener como un estándar normal... Oh, gracias, copiloto. Lo has acertado. Eso es genial. Así que podemos crear una instancia de esto por un ID único. Así que si nosotros leemos este código línea por línea, básicamente creamos un ID de un objeto. En este caso, es solo una cadena que dice contador. Luego obtenemos una instancia de ese objeto duradero. Si ese objeto duradero existe previamente, obtenemos una instancia de él. Si no existe, se crea para nosotros. Y luego reenviamos la solicitud que entra desde la aplicación a ese objeto duradero, y luego ese objeto lo manejará. Así que ahora si guardo, aquí en mi final, el número sube. Bueno, ya vimos eso. Eso no es demasiado emocionante. Pero en un momento, esperemos, el despliegue ha ido correctamente. Genial. Ahora, oh, mira eso. Ese número sigue subiendo bastante. Creo que es porque todos ustedes lo están bombardeando. Y cada vez que lo golpeas, estás incrementando el mismo número que la siguiente persona, y luego estás obteniendo los incrementos de la persona anterior. Así que eso es bastante genial. Eso es genial. Creo que podemos hacer esto mucho mejor. Y antes de hacer eso, hagamos esto más emocionante. Creo que el ejemplo del contador,
7. Incrementando Dos Números
Pero creo que podemos hacer algo más sofisticado. Incrementemos dos números y hagamos un concurso de popularidad. La aplicación envía un ID o número con la solicitud. Hemos construido una aplicación que incrementa dos números y provoca discusiones. Esta es una aplicación estándar de Vite React que busca el código desplegado y realiza una solicitud de publicación para incrementar el número.
Creo que, es bueno para cosas simples. Pero creo que nosotros, como desarrolladores adultos, creo que podemos hacer algo mucho más sofisticado. Entonces, ¿qué es más genial que incrementar un número? Yo creo que diría que es al menos dos veces más genial incrementar dos números. Así que hagamos eso. Y mientras estamos en ello, hagamos que sea interesante. Hagamos que esos números signifiquen algo. Digamos que somos una conferencia de
React, digamos un
remix, o en
Next.js. Hagamos de esto un concurso de popularidad. Y luego aquí, veamos. Tomaremos la solicitud que entra, y la aplicación aquí enviará un ID del botón o como un número del botón. Y luego déjame agregar esta pregunta aquí también. Genial. Así que ahora en mi máquina, vemos esta pequeña aplicación de votación. Y en solo un segundo, ustedes deberían poder hacer eso también. Eso es genial. Muy bien, así que hemos construido una aplicación que incrementa dos números. Pero al adjuntar nombres a ella, ahora estamos teniendo una discusión. Curioso cómo funciona eso. Bueno, eso está bien. Pero antes de seguir adelante, creo que en este punto, sería bueno para mí explicar qué es lo que realmente está sucediendo aquí. Porque vamos a agregar mucha más funcionalidad. Y antes de hacer eso, no quiero que nadie esté confundido. Así que si miramos este proyecto que tengo aquí, esto es una aplicación completamente normal y estándar de
Vite React que se ejecuta en un navegador. Y todo lo que realmente hace la aplicación es hacer una solicitud HTTP fetch a este código desplegado que tenemos. Y luego cuando haces clic en él, hace otra solicitud con un método post. Así que incrementamos el número. Y la razón por la que el número sube, oh, 2000 veces que has presionado 4000 veces. Genial. Alguien está manteniendo sus dedos ocupados, o alguien escribió un pequeño script en su navegador para martillear el botón. Por favor, no hagas eso. Pero si tú
8. Conexión WebSocket y Actualizaciones en Vivo
Estamos realizando una conexión WebSocket a la misma dirección, lo que nos permite construir sistemas basados en push. El constructor WebSocket envía una solicitud de actualización y establece una conexión. Podemos recorrer los WebSockets conectados y enviar el mismo estado a cada uno. Esto permite actualizaciones en vivo y muestra el incremento del número en tiempo real.
debes, adelante, creo que podemos escalar para eso. Entonces eso es todo lo que está sucediendo aquí. Y luego renderizamos un botón para cada uno de los valores que entran. Así que en este caso, ya sabes, dos números, y ya sabes, obtienen dos botones. Pero también estoy haciendo una cosa más aquí, que es que estoy intentando hacer una conexión WebSocket a esa misma dirección. Y si no conoces WebSockets, básicamente es como imaginar una lata con un hilo entre ellas. Ya sabes, yo sostengo un extremo de ella, tú sostienes un extremo de ella, y luego puedo gritar en ella. Y ya sabes, puedo enviarte un mensaje y viceversa. Eso sobre TCP es básicamente lo que son los WebSockets. Así que eso nos permite construir sistemas basados en push. Así que hagamos eso ya que nuestro cliente ya está preparado para ello. Así que déjame volver a este contrato aquí. Y hagamos esto. Así que si las cabeceras de la solicitud, oh, gracias, Copilot. Y luego, oh, bien. Entonces, básicamente, lo que está sucediendo aquí es que el constructor WebSocket, la biblioteca que estamos usando es solo un estándar envoltorio
React sobre un constructor WebSocket. Envía esta solicitud de actualización. Y a cambio, les damos, sostenemos un extremo de la lata y les damos el otro extremo de la lata a ustedes. Y luego podemos enviarles mensajes. Y ahora, cada vez que los mensajes, es decir el número se incrementa, déjame también entonces, oh, bien. Nosotros, ya sabes, recorremos todos los WebSockets actualmente conectados porque estamos, ya sabes, teniendo estados en memoria. Así que básicamente podemos recorrerlos. Y podemos, ya sabes, enviarles el mismo estado a través de ese socket. Y ahora he guardado. Mi extremo parece estar funcionando. Y tal vez en un segundo después de que se actualice tu aplicación, oh, vemos el número subir en vivo. Y no sé por qué eso está cambiando la ubicación entre. Oh, acabo de hacer un error. Así que básicamente la ubicación a través del primer trabajador que te conecta a este objeto duradero. Yo en realidad acabo de hacer un error aquí, que envía, ya sabes, la ubicación de cada una de esas personas
9. Servidor WebSocket y Almacenamiento de Datos
Hemos creado un pequeño servidor WebSocket que puede mantener la conexión entre yo y todos ustedes. Actualmente, 45 personas, pero esto podría escalar hasta 32000 si quisiéramos ser realmente ambiciosos al respecto. Sin embargo, cuando hago cualquier cambio de código y guardo, el número vuelve a cero. Eso es porque estamos usando un estado en memoria, que no es realista para el almacenamiento a largo plazo. Afortunadamente, DurableObjects proporciona una tienda de clave-valor incorporada para cada objeto, lo que nos permite almacenar información en el disco y recuperarla cuando el objeto vuelve a estar activo.
a ustedes. Así que vemos dónde está todo el mundo. Todos están en Frankfurt, Viena, Sheldagol, etc. Pero se está moviendo un poco rápido. OK, ¿todos entienden más o menos qué es lo que está pasando aquí? Hemos creado un pequeño servidor WebSocket que es capaz de mantener la conexión entre yo y todos ustedes. Actualmente, 45 personas, pero esto podría escalar hasta 32000 si quisiéramos ser realmente ambiciosos al respecto. Y somos capaces de transmitir mensajes a todos ustedes. Así que hemos creado una pequeña aplicación colaborativa. Hasta ahora todo va bien. Genial. OK, pero una cosa que podrían haber notado, y esto es más fácil para mí demostrarlo cuando voy aquí en mi localhost. Cuando hago cualquier cambio de código y guardo, el número vuelve a cero. Boo. Eso no es muy útil. ¿Cómo sabremos nunca cuál ganará?
Remix nuestro
NextJS si seguimos reiniciando el número cada vez que desplegamos código. Bueno, la razón por la que eso sucede es que, ya sabes, estamos usando un estado en memoria aquí. Si solo hacemos un rápido repaso. Ya sabes, esto es todo el
state management que tenemos. Tenemos un contador en memoria. Es bastante genial, pero al mismo tiempo, realmente no podemos garantizar que un objeto permanecerá en memoria para siempre. Eso no es realmente realista. Lo que podemos hacer en cambio es que podemos almacenar esa información en el disco. Y así cuando este objeto vuelve a estar activo, en este caso, se sigue reiniciando cuando despliego nuevo código. Podemos usar algún tipo de sistema de almacenamiento. Ahora, podría ir a PlanetScale y yo podría provisionarme una, ya sabes, como una base de datos SQL
database y podría contactar eso. Pero yo creo que eso derrotaría el propósito aquí. Y afortunadamente, DurableObjects, tú sabes, es en realidad un producto de almacenamiento. Así que tenemos una tienda de clave-valor incorporada para cada objeto. Así que lo que podemos hacer aquí es que podemos decir, déjame solo escribir este código. Así que veamos. Hagamos algún tipo de función que cargue los
data desde...
10. Implementación de Almacenamiento y Creación Dinámica de Objetos
Hemos implementado un sistema respaldado por almacenamiento utilizando Durable Objects. Nos permite almacenar cualquier objeto o estructura de datos de JavaScript sin convertirlo a JSON. CloudFly asegura que los datos se almacenan y se recuperan cuando el objeto vuelve. Podemos crear múltiples instancias de estos objetos en cualquier parte del mundo al instante. Los objetos se pueden crear dinámicamente en función de las rutas HTTP. Cada objeto puede tener sus propias propiedades y funcionalidades únicas.
Eso es genial. Así que tenemos almacenamiento y eso tiene, ya sabes, un método llamado get, del cual podemos obtener
data que previamente hemos introducido en él. En este caso, usamos el valor clave y también tipificamos que el
data es solo un array de números. Y luego, de manera similar, podemos tener una función para guardar ese
data en algún momento. Así que guardemos el
data cada vez que incrementamos. Y también carguemos el
data cuando vayamos a, cuando el constructor del objeto se ejecute, es decir, cuando estamos cargando el objeto después de volver a desplegar. Y ahora básicamente hemos implementado una especie de sistema respaldado por almacenamiento. Así que la próxima vez que esto se vaya, se vuelva a desplegar, ahora fue a cero. Pero entonces si sé dónde volver a desplegar de nuevo, esperemos que digamos, guardar, me alejaré y seguirás presionando el botón y esperemos que cuando ocurra el re-despliegue, el número no se reinicie en realidad. Está bien. Así que esto es interesante, ¿verdad? Como si recapituláramos de nuevo, tenemos solo una clase normal de
JavaScript en la que podemos mantener el estado en memoria, podemos básicamente, sin serializar o sin tener que hacer nada sofisticado, podemos básicamente almacenar cualquier objeto de
JavaScript o estructura de
data sin tener que convertirlo a JSON. Y CloudFly se asegurará de que eso se almacene en algún lugar y luego podemos leerlo de nuevo cuando el objeto vuelva. Así que esencialmente estamos creando un sistema respaldado por una
database completamente funcional en solo un archivo de
JavaScript que existe en nuestro proyecto aquí mismo entre mis componentes de
frontend. Así que eso es bastante dulce, pero no es lo suficientemente dulce. Esto podría haberlo hecho muy fácilmente. Acabo de hacer un servidor de nodos y lo desplegué en fly.io o Heroku o algo así. Pero lo que es realmente extraordinariamente interesante acerca de esto es que podemos crear cualquier cantidad de estos instantáneamente, libremente, en cualquier parte del mundo. Así que aquí, si volvemos a donde creamos este objeto, creamos un contador. Y si cambio este ID, por ejemplo, el contador dos, y luego en unos segundos ahora, el número se reiniciará para ti, porque en realidad estamos hablando con un objeto diferente, ¿verdad? Como que hemos provisionado una nueva
database. Ahí vamos. Nuevo objeto, nueva
database, nueva capa de aislamiento de memoria donde podemos ejecutar este código. Pero no necesitas usar IDs estáticos. Podemos crear objetos dinámicamente. Así que por ejemplo, en este caso, digamos que enviamos una ruta, ya sabes, como una ruta HTTP normal en esta solicitud y creamos un objeto para ello. Y para hacer esa demostración un poco más genial, déjame también cambiar la pregunta para cada sala para que veamos lo que está pasando aquí. Así que he preparado un poco de código aquí. ¿Cuál es una buena pregunta de la sala ID? Y esto básicamente elige una pregunta aleatoria basada en la ID de la sala, ya sabes, de una lista de preguntas. Y ahora, esperemos. Está bien. Punto y coma o no punto y coma. ¿Ves eso en tus teléfonos también? ¿Punto y coma o no punto y coma? Genial.
11. Gestión de Salas y Almacenamiento de Datos
Hagamos una sala diferente, como la sala Berlín o la sala del muro. Podemos generar una cantidad infinita de estas salas simplemente inventando una nueva ID. Sin embargo, no queremos almacenar los datos para siempre. Podemos usar alarmas para programar la ejecución del código y eliminar el almacenamiento que ya no es necesario. Esto nos permite ejecutar el código de manera programada y gestionar el almacenamiento de datos de manera eficiente.
Genial. Hagamos una sala diferente. Digamos sala Berlín. Muy bien. ¿Pegatinas o calcetines? Esta es, ya sabes, la clásica pregunta de la conferencia. Digamos una nueva sala. Vamos a la sala del muro. ¿Oficina o remoto? Ooh, remoto. Los empleadores tomen nota.
Y luego si volvemos a la sala original aquí, ya sabes. Oh, lo siento. Este es un error en mi código del cliente. ¿Cuál era la de Berlín que teníamos antes? Genial. Así que todos esos data que teníamos en la sala anterior todavía están almacenados. Ya sabes, estamos volviendo a la cosa. Así que esencialmente pudimos generar una cantidad infinita de estas salas, ya sabes, simplemente inventando una nueva ID. Así que eso es bastante útil, creo.
Una última cosa que haré antes de pasar a la parte de explicación de esto es que en realidad no quiero almacenar estos data para siempre. Creo que ahora lo que estamos haciendo es que para estas salas que hemos creado y cualquier nueva sala que creáramos, básicamente mantendríamos estos data para siempre. Pero en realidad no necesitamos invocar un objeto duradero para ejecutar el código allí. También podemos ejecutar el código allí de manera programada. Los objetos duraderos tienen esta cosa llamada alarmas donde podemos decir, ya sabes, este estado almacenamiento establecer alarma. Digamos, OK, por ejemplo, si mi matemática es correcta, en una semana queremos ejecutar algo de código y luego haremos esta función llamada alarma. Ahí vamos. Y luego esta alarma se ejecutará básicamente una semana después de la más reciente invocación de establecer alarma. Y todo lo que hacemos aquí es básicamente eliminar el almacenamiento que ya no estamos utilizando porque no necesitamos almacenar estos data por más de una semana. Si quisieras, ya sabes, guardar esto en otro lugar en este punto, sería un buen momento para enviarlo a quizás algún tipo de sistema de respaldo en algún lugar como algún almacenamiento a largo plazo R2 o S2 o S3 o algo así. Pero hasta entonces, el almacenamiento es realmente todo el almacenamiento que necesitamos. Para demostrar esto, solo voy a acortar este tiempo a un segundo solo para que no tengamos que esperar aquí una semana. Y ahora la próxima vez que vengamos a desplegar, que sucederá más o menos ahora.
12. Explorando el Cómputo y los Datos Co-localizados en el Borde
Ahora, si todos pueden cooperar y no presionar ese botón por un segundo. Luego, la próxima vez que presionemos este botón, irá a cero. Construir aplicaciones colaborativas es genial y divertido, pero espero que puedan entrecerrar un poco los ojos y pensar en, si pueden crear esencialmente capacidad de cómputo instantáneamente, pueden co-localizar el almacenamiento con ella. Pueden enviar datos desde conexiones WebSocket. Pueden abrir conexiones TCP a bases de datos. Pueden llamar a estos como puntos finales de webhook desde sistemas externos. Es realmente interesante cómo pueden pensar realmente de manera diferente sobre el cálculo. Porque uno de los grandes errores que creo que hemos cometido en AIRA, y casualmente vi un tweet al respecto hoy, así que dejaré que este tweet hable por sí mismo. Pero creo que nosotros, como industria, hemos estado tratando de reinventar la informática distribuida básicamente creando estos separando el cómputo y el estado. Así que co-localizar su cómputo y datos en el borde, creo que es un nuevo paradigma realmente poderoso que nosotros como industria deberíamos explorar más. Y afortunadamente, no es solo CloudFlare el que está haciendo esto. Entonces Azure tiene estas funciones duraderas, que son muy diferentes desde una perspectiva de API, pero básicamente hacen lo mismo.
Ahora, si todos pueden cooperar y no presionar ese botón por un segundo. Luego, la próxima vez que presionemos este botón, irá a cero. Oh, lo hiciste. Esperaba un poco más de resistencia de tu parte, pero esto está bien. Muy bien. Creo que eso es todo el código que quería mostrar. Y creo que salió bastante bien. ¿Podemos tener un aplauso para mí? Gracias. Gracias. Y Co-Pilot se comportó realmente bien hoy. Así que gracias también a Co-Pilot.
Muy bien. Ahora el temporizador es... ¿Cómo vamos de tiempo? ¿Ya hemos pasado, verdad? Genial. Bueno, quiero decir solo dos cosas, y luego iré a la sección de preguntas y respuestas y los dejaré ir. Así que construir aplicaciones colaborativas es genial y divertido, pero espero que puedan entrecerrar un poco los ojos y pensar en, si pueden crear esencialmente capacidad de cómputo instantáneamente, pueden co-localizar el almacenamiento con ella. Pueden enviar datos desde conexiones WebSocket. Pueden abrir conexiones TCP a bases de datos. Pueden llamar a estos como puntos finales de webhook desde sistemas externos. Es realmente interesante cómo pueden pensar realmente de manera diferente sobre el cálculo. Porque uno de los grandes errores que creo que hemos cometido en AIRA, y casualmente vi un tweet al respecto hoy, así que dejaré que este tweet hable por sí mismo. Pero creo que nosotros, como industria, hemos estado tratando de reinventar la informática distribuida básicamente creando estos separando el cómputo y el estado. Creamos estos pequeños pedazos de cómputo y luego creamos estas máquinas infernales realmente complicadas donde no solo necesitamos usar una base de datos para lo que una base de datos es buena, que es el almacenamiento, sino que también necesitamos usar una base de datos para coordinación. Como si quisiéramos hacer un número que sube y no tuviéramos la capacidad de usar el estado en memoria, tendríamos que tener una base de datos Redis donde ese número sigue incrementándose. Y luego te metes en todo tipo de problemas de nivel de aislamiento de la base de datos, con los que simplemente no quieres lidiar. Y luego, si piensas en dónde quieres ejecutar tus cargas de trabajo sin servidor ¿Quieres ejecutarlas cerca de tu usuario, lo que hace que el salto inicial sea realmente, realmente rápido, o quieres ejecutarlo cerca de tu base de datos, lo que hace que tu salto de recuperación de datos sea rápido, pero no puedes tener ambos. Entonces, en algún momento estás esencialmente diciendo que si tu base de datos vive en un lugar, vas a construir una aplicación lenta si depende de los datos. Así que co-localizar tu cómputo y datos en el borde, creo que es un nuevo paradigma realmente poderoso que nosotros como industria deberíamos explorar más. Y afortunadamente, no es solo CloudFlare el que está haciendo esto. Entonces Azure tiene estas funciones duraderas, que son muy diferentes desde una perspectiva de API, pero básicamente hacen lo mismo.
13. KV de Deno y Flame de fly.io
KV de Deno y Flame de fly.io son productos innovadores que simplifican el desarrollo de programas al eliminar la necesidad de aprovisionar bases de datos, cómputo y clústeres de Kubernetes. En su lugar, distribuyen los datos a nivel mundial y aseguran que el código se ejecute de manera consistente.
Deno tiene este KV, que es un producto ligeramente diferente en el sentido de que en lugar de simplemente mantener los data en un lugar, en realidad buscan distribuir esos data eventualmente, de una manera eventualmente consistente a nivel mundial, lo que te da diferentes restricciones. Pero en este caso, no necesitamos eso. Y también esta semana, fly.io publicó este artículo o esta entrada de blog llamada Flame, que es un nuevo tipo de architecture donde puedes simplemente envolver cualquier código en una función y ellos se asegurarán de que se ejecute exactamente de la misma manera que acabamos de demostrar. Así que creo que esto es algo así como un camino que me ha ayudado a simplificar el tipo de programas que escribo, porque no necesito pensar en aprovisionar bases de datos, aprovisionar cómputo, aprovisionar, como ejecutar un clúster de Kubernetes. Esencialmente puedo tener el cómputo que necesito disponible para mí cuando lo necesito.
Explorando Todo, En Todas Partes, Todo a la Vez
Todo, en todas partes, todo a la vez. Cómputo, almacenamiento, distribuido globalmente. Barato de ejecutar. Preguntas y respuestas: Limitaciones de los objetos duraderos - 128 MB de RAM, límite de almacenamiento de 128 kilobytes. ¿Cómo se construyen? Facturación basada en el uso de cómputo, almacenamiento y memoria.
Y sí, creo que eso es todo. Si volvemos a las diapositivas, creo que quizás hemos explicado el título, todo, en todas partes, todo a la vez. Así que todo, como en, ya sabes, es cómputo, almacenamiento, todo lo que necesitas para construir algo. Está en todas partes. Está distribuido globalmente. Y todo a la vez, ya sabes, básicamente puedes iniciar cualquier cantidad de instancias. Esto se escala a millones muy, muy rápidamente. Realmente no he tocado el tema de no mucho dinero. Podemos hablar de eso en las preguntas y respuestas o con el tiempo. Pero básicamente, estas cosas también son bastante baratas de ejecutar.
Y para los amantes del cine, quería tener una última diapositiva aquí, ya sabes, solo para tener algo que mirar. Eso es. Esa fue mi referencia de película. Muchas gracias. Mi nombre es Janne. Y hagamos una sesión de preguntas y respuestas.
¿Cuál es la limitación de los objetos duraderos? 128 MB de RAM, que no es una gran cantidad. Pero de nuevo, realmente no he tenido muchos casos de uso donde exceda eso. Almacenamiento tanto como quieras, pero cada valor solo puede ser de 128 kilobytes. Entonces, si tienes valores singulares masivos, es posible que necesites dividirlos un poco. Sí, esos son los grandes. Entonces eso tiene sentido. ¿Cómo se construyen? Esto es lo realmente genial. Y ahora podemos hablar de costos. Entonces, la facturación se basa básicamente en tres factores. Así que es el cómputo. Entonces, cada vez que enviamos un mensaje, se factura como una función normal en un stack de trabajadores. Luego pagas por el almacenamiento, por supuesto. Por eso queremos borrar, por ejemplo, el almacenamiento de siete días para no pagar por
Uso de Memoria, Autorización y Aplicaciones Comerciales
La API WebSocket ofrecida por Cloudflare es interesante ya que permite que el objeto sea descargado de la memoria cuando no está procesando activamente conexiones, lo que lo hace asequible. La autorización puede ser manejada a través de endpoints HTTP, permitiendo el uso de tokens y servicios de terceros. Reflect, una plataforma de sincronización de estado multijugador, es un ejemplo de una aplicación comercial construida sobre objetos duraderos. Se utiliza en capacidades de back-office y es adecuada para aplicaciones que requieren sesiones de larga duración y almacenamiento de estado. Las relaciones de facturación existentes de Cloudflare con las empresas y su programa gratuito para startups lo convierten en una opción atractiva. Almacenar parte del estado de forma permanente es útil en escenarios como el ejemplo de Uber.
algo que necesitamos. Y luego la memoria utilizada del objeto mientras se ejecuta. Pero la API WebSocket que
Cloudflare ofrece aquí es realmente interesante porque lo que hacen es que a nivel de plataforma, a nivel de red, mantienen las conexiones WebSocket, pero pueden descargar el objeto de la memoria cuando no está procesando activamente conexiones. Así que si tienes, por ejemplo, una sala que permanece activa durante un día, pero sólo recibe unos pocos mensajes durante el día, realmente sólo pagas por el breve milisegundo que el objeto está vivo mientras procesa ese mensaje. Así que es realmente muy, muy asequible también.
Bien. ¿Cómo manejan la autorización? Así que tú manejas la autorización, ¿verdad? Es un endpoint HTTP. Así que, ya sabes, puedes enviar un token, puedes autorizarlo con cualquier servicio de terceros o tu propio endpoint de autenticación. Es completamente esto que tengo no está autorizado, pero podrías añadir una especie de ping de autenticación con sólo unas pocas líneas de código.
¿Conoces alguna aplicación comercial o simplemente diría grandes aplicaciones que funcionen en objetos duraderos? Así que hay muchas plataformas construidas en realidad sobre objetos duraderos. Por ejemplo, Reflect, que es una especie de paquete de sincronización de estado multijugador. Eso es una plataforma increíble. Realmente resuelve muchos de los problemas comunes de sincronización de estado que los usuarios podrían tener. Y está construido sobre objetos duraderos. Y, ya sabes, básicamente también es barato porque el modelo de facturación es el mismo que el de los objetos duraderos. Pero estas cosas se utilizan mucho en una capacidad de back-office. Así que si piensas en, por ejemplo, una sesión que vive durante un tiempo, digamos que estás construyendo Uber y tienes una aplicación de reserva de taxis. Necesitas un pedazo de cómputo que sea capaz de no sólo, ya sabes, comunicarse con múltiples servicios de back-end diferentes, sino mantener su estado durante la duración del viaje y luego no más. Como este es un caso de uso perfecto para ello. No estoy diciendo que Uber lo esté usando, pero estos son los tipos de, ya sabes, casos de uso de back-office industriales donde siento que el discurso de las aplicaciones colaborativas y pizarras y juegos está un poco infravalorado. Realmente puedes construir cosas serias a escala de producción. Y diré esto. No trabajo en Cloudflare. No estoy tratando de vender esto en particular. También puedes usar el de Azure o puedes usar, ya sabes, lo que sea. Pero lo bueno de Cloudflare es que si trabajas en una empresa de tamaño decente, ya tienes una relación de facturación con ellos porque lo usas para, ya sabes, DNS y caché y proxy y todo eso. Así que en realidad no es difícil vender esto a las corporaciones también. Y si eres una startup, tienen este programa que lo obtienes gratis durante un año. Así que. Y supongo que lo otro interesante es el ejemplo de Uber, creo que es un fantástico caso de uso para cuando tomarías parte de ese estado y lo almacenarías permanentemente. No necesitas todo ello.
Simplificando el Desarrollo de Características
No necesitas almacenar cada paso de la sincronización. Solo se almacenan los puntos clave al final. Esta tecnología simplifica la construcción de características como compartir viajes en Uber sin la necesidad de aprovisionar numerosos servidores WebSocket. Enviar actualizaciones a los clientes es fácil, requiriendo una mínima ingeniería de software.
No necesitas estar almacenando cada paso de la sincronización. Solo estos puntos clave, los almacenamos al final. Exactamente. Y sí, exactamente. Sí. Y luego simplemente envías los metadatos que necesitabas. Pero como, Uber ahora tiene esta característica en la que puedes, por ejemplo, compartir el viaje con tu amigo, ya sabes, por seguridad. Correcto. Así que imagina construir eso, ya sabes, sin algo como esto, necesitas aprovisionar una gran cantidad de servidores WebSocket. Necesitas crear este tipo de abstracción, como algo del tipo socket IO. Se vuelve realmente, realmente complicado. Pero aquí, como hacer un push a un cliente es tan fácil como hacer un push a todos los clientes registrados. Así que realmente no tienes que hacer ninguna ingeniería de software como tal. Genial. Y entre la charla y las preguntas, hemos llegado al tiempo. Pero solo un recordatorio de que hay una sección de preguntas y respuestas con el orador cerca de la recepción y en línea con la cronología. ¿Puedo responder una pregunta? Porque realmente va rápido. De acuerdo. Si data se almacena en el borde, ¿cómo es la historia de consistencia de data? Solo podemos tener consistencia eventual. Así que esto es realmente interesante es que tenemos una sincronía muy fuerte, ya sabes, consistencia entre la memoria y el disco porque data solo existe en una ubicación a la vez. Así que esto no es un data global en el sentido de que el mismo data se replica en cada uno de esos 300 centros de data. Vive en un centro de data a la vez. Y la red de Cloudflare se asegura de que todos los que quieran este objeto por este ID vayan a esa máquina. Así que si todos estamos aquí en Berlín y vamos a Frankfurt, eso es realmente rápido. Si alguien de Japón se uniera a esto, por supuesto para ellos sería lento. Así que esto no resuelve el problema de la rapidez global para la sincronización de estado, pero sí lo resuelve para estas sesiones efímeras cortas. Y las que son regionales, como el ejemplo del taxi. Sí, por ejemplo. Pero luego de nuevo, como para muchas cosas, como este número sube fue divertido para que veamos el número subir inmediatamente, pero habría sido visto como divertido o rápido incluso si alguien viniera de más lejos, ¿verdad? Como que realmente, a veces puedes en la capa de UX, puedes realmente como parchear el hecho de que el viaje de ida y vuelta es un poco más largo. Sí. Excelente. Muy bien. Demos un gran aplauso a Jani. Gracias. Muchas gracias.
