Durable Objects - Todo En Todas Partes Todo De Una Vez Por No Mucho Dinero

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

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.

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.

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.

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

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.

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.