Jazz: Construye Aplicaciones React en Tiempo Real, Locales con Sincronización y Datos Colaborativos Seguros

Muchas gracias por la introducción. Soy Anson. Estoy aquí hoy para hablarles sobre JAS, mi nuevo marco para construir aplicaciones en torno a datos colaborativos seguros y sincronizados. Antes de entrar en detalles, esta es la primera vez que hablo de esto públicamente. Por lo tanto, si esto les resulta interesante, realmente podrían ayudarme echando un vistazo a la página principal y uniéndose al Discord, especialmente si quieren experimentar con JAS o tienen algunas preguntas. Cualquier comentario realmente me ayuda en esta etapa inicial. Hoy, hablaré sobre estas cosas. ¿Por qué empecé a hacer JAS? ¿Qué es realmente? Echaremos un vistazo a una pequeña aplicación de demostración y haremos un recorrido detallado por el código para darles una rápida impresión de cómo se siente construir una aplicación con JAS. Si tenemos tiempo, haremos una pequeña aplicación de demostración adicional y hablaré un poco más sobre qué viene para JAS. Entonces, ¿por qué decidí empezar a construir JAS? Construyo muchas aplicaciones y básicamente cada vez que digo, hey, construyamos una aplicación, pero luego tienes que preocuparte por todas estas cosas, como elegir una database, desplegarla, cómo construir el backend y especialmente si quieres hacer multijugador en tiempo real, simplemente añade más complejidad. De repente necesitas colas de mensajes, web sockets, y me pregunto, ¿por qué todo es tan difícil? Y más interesante aún, ¿qué pasaría si no tuviera que ser así? ¿Qué pasaría si pudiéramos deshacernos de casi todo eso y quedarnos solo con las cosas que realmente hacen que nuestra aplicación sea nuestra aplicación, verdad? ¿No sería eso agradable? Esa es más o menos la promesa de JAS, suena bien, ¿verdad? Y mejora aún más. ¿Qué pasaría si les dijera que también obtienen sincronización entre dispositivos, multijugador en tiempo real, obtención automática de data granular de la que no tienen que preocuparse, persistencia local y en la cloud, soporte fuera de línea y una interfaz de usuario realmente rápida de forma gratuita? Suena genial, ¿verdad? Ese es más o menos el sueño que tenía cuando comencé con eso, pero ¿cómo podemos llegar allí? Y creo que para responder a esa pregunta, realmente ayuda. Y eso es con lo que comencé, es preguntarnos, ¿cómo llegamos a este lío en primer lugar? Así que una historia rápida, comencemos desde los principios básicos. Este es más o menos mi modelo mental de una computadora, ¿verdad? Resulta que no es mi modelo mental de una computadora, es en realidad el modelo mental de este tipo, y simplemente lo hizo realidad, y eso es lo que tenemos ahora. Y ha permanecido prácticamente sin cambios desde entonces, excepto en los años 60 y 70, estos tipos añadieron una caja a eso, que es el internet, y todavía estamos recuperándonos de eso. Para la web en sí, este tipo fue super influyente. Básicamente vio esta arquitectura de computadora y dijo, oye, sabes qué, deberíamos construir hipertexto en eso, y creó algunas de las primeras interfaces de usuario gráficas, pero el hipertexto no se popularizó hasta mucho después cuando este tipo dijo, la colaboración de investigación en CERN es un desastre, tal vez deberíamos construir hipertexto, y el problema con su implementación de hipertexto, por supuesto, es que era lo suficientemente buena, y eso es con lo que estamos atrapados ahora, eso es la web. Pero más tarde, en 95, este tipo dijo, hey, eso es un buen hipertexto que tienes ahí, ¿qué tal si construimos una arquitectura de computadora encima de eso? Y también mi jefe me dio diez días para hacerlo. Y de manera similar, el problema con JavaScript fue que era lo suficientemente bueno, así que eso es lo que tenemos ahora, ¿verdad? Así que ahora estamos en una situación en la que básicamente esta es la arquitectura de computadora más popular, la VM de JavaScript en el navegador tal como la conocemos. Pero en realidad, no hay nada realmente malo con eso. La complejidad es realmente inherente en el modelo más genérico de la computadora aquí porque si queremos construir una aplicación, tenemos que preocuparnos por demasiadas de estas cajas. Básicamente la razón por la que tenemos todas estas preguntas es porque cada vez que queremos construir una aplicación, necesitamos pensar en estas flechas y mover data entre la memoria, el disco, el internet, otras computadoras. Ahí es donde creo que proviene la mayor parte de la complejidad. Cuando escuché por primera vez sobre los CRDT, me emocioné mucho porque los CRDT prometen un modelo alternativo a eso. Realmente no tengo mucho tiempo para explicar los CRDT. Hay una publicación de blog muy buena llamada Data Laced with History. Esa es una muy buena forma de pensar en los CRDT también. Así que definitivamente echen un vistazo a eso. Una forma sencilla de pensar en los CRDT que me gusta es, en lugar de intentar tan duro poner tus data en el internet y tener eso en diferentes lugares, básicamente pones el internet en tus data y tus data ahora son conscientes de que existen en diferentes lugares. Muchas personas lo están editando a la vez.

Cuando comencé a investigar los CRDT, me di cuenta de que por sí solos, realmente no son suficientes. Lo que realmente quieres además de ellos son permisos y quieres tener sincronización y almacenamiento resueltos para ti también. Si tienes este paquete de cosas, en realidad tienes una abstracción realmente poderosa. Tan poderosa que te permite pasar de esta situación bastante complicada a una mucho, mucho más simple que se ve así.

Y esta nueva abstracción es lo que estoy llamando datos colaborativos. Creo que explica bastante bien mi motivación. Entonces, ¿cómo construimos esto realmente? Y aquí es donde comenzaré a hablar sobre lo que realmente es Jazz. Queremos construir esto de alguna manera y ¿cómo lo implementamos en el mundo de hoy? Mi enfoque particular en esto lo llamo CoJson, que significa JSON colaborativo. Y básicamente solo conectas algo de JavaScript a eso y renderizas cosas en el DOM y eso es todo lo que necesitas hacer para construir una aplicación. Para ser más preciso, CoJson implementa la co-edición en varios dispositivos, identidades de usuario y cuentas como un concepto de primera clase. Permisos y roles, sincronización y almacenamiento en caché y persistencia para ti, por lo que no tienes que preocuparte de nada de eso al construir una aplicación. Lo más importante, básicamente hace que la colaboración y el control de acceso seguro se sientan como propiedades inherentes de los datos de tu aplicación. Y eso significa que puedes construir tu aplicación como si todo lo que tuvieras fuera un estado local. Ya no tienes que preocuparte por nada más.

¿Cómo es CoJson? ¿Qué te proporciona? Te da el buen viejo JSON como valores inmutables, así que tienes tus objetos, arrays y así ¿verdad? Y añade a eso un nuevo mundo de valores colaborativos o CoValues para abreviar.

Hay mapas colaborativos y listas colaborativas. Estos son bastante autoexplicativos. Pronto, habrá cadenas colaborativas, texto plano y texto colaborativo, que es texto enriquecido. Y luego hay algo un poco más extraño, que estoy llamando un CoStream, que es básicamente un flujo de valores por participante. Y veremos en el ejemplo más tarde que eso es realmente útil para las características sociales o cualquier cosa donde quieras que la gente no trabaje en el mismo objeto con posibles conflictos de edición, sino que los separe. Y hay una versión especial de eso para los datos binarios. Pero básicamente, estos son los bloques de construcción que CoJSON te da, y eso es todo lo que necesitas para construir tu aplicación. Los CoValues mantienen, siempre mantienen su historial completo de ediciones. Resuelven automáticamente los conflictos. Y son eventualmente consistentes. Y esto es exactamente lo que los hace un CRDT, ¿verdad?

Además de eso, CoJSON ofrece, como dije, permisos y cuentas de usuario como un primer concepto de clase. Y la forma en que interactúas con eso como desarrollador es que creas grupos, porque los CoValues siempre pertenecen a un grupo. Y un grupo es simplemente un conjunto de cuentas con roles, como lector, escritor o administrador. Y luego los roles de las cuentas determinan los derechos de acceso a todos los objetos que son propiedad de un cierto grupo. Y lo interesante es que este control de acceso no está implementado por alguna autoridad central o un backend, sino globalmente por firmas de cifrado. Y esta es la principal razón por la que realmente no necesitas un backend para la mayoría de las cosas si trabajas con CoJSON, si trabajas con esta nueva abstracción de datos colaborativos.

Ahora que tienes una idea de lo que es CoJSON, vamos a ver qué es Jazz. Básicamente, Jazz es solo un marco de código abierto que proporciona enlaces idiomáticos para CoJSON para diferentes entornos con baterías incluidas. Así que queremos tener esto, ¿verdad? Pero necesita existir en el navegador. Así que lo que hace Jazz, el paquete de navegador de Jazz, es que conecta CoJSON a la autenticación externa, persiste cosas localmente en IndexedDB, y hace toda la sincronización a través de WebSockets, ¿verdad? Ahora, obviamente, no somos como los hombres de las cavernas. No queremos interactuar directamente con el DOM. Queremos usar React. Así que lo que realmente quieres usar es Jazz React. Y si haces eso, esa es como mi biblioteca insignia. Eso es en lo que me estoy enfocando y realmente quiero acertar en el DX. Todo lo que tienes que preocuparte es esto. Y sí, veremos en un segundo lo agradable que es en realidad. En particular, Jazz proporciona esta idea que estoy llamando autosub para suscripciones automáticas, lo que significa que puedes suscribirte de forma reactiva a un árbol de valores centrales y se actualizarán siempre que edites los valores centrales localmente o siempre que otro participante los edite. Así que básicamente obtienes un estado de uso que mágicamente tiene persistencia y multijugador incorporado.

Y eso es súper, súper poderoso. Además de eso, como dije, proporciona un par de proveedores y también te permite subir y descargar archivos realmente fácilmente. Así que no necesitas almacenamiento blob externo. Puedes transmitir data directamente en los valores centrales y hacer que se sincronicen igual que un data estructurado. Recuerda que dije antes que no solo queremos CRDTs y permisos, también necesitamos una solución para la sincronización y el almacenamiento.

Así que además de solo la biblioteca de código abierto, también estoy ejecutando algo llamado malla global, que es básicamente una infraestructura global de sincronización y almacenamiento que estoy proporcionando como un servicio. Puedes pensar en ello como básicamente S3 más un CDN para data colaborativos. Es gratis ahora mientras estoy construyendo todo esto y será realmente barato más tarde.

Echemos un vistazo a una aplicación real construida con Jeth. Empecemos realmente simple, solo para hacerlo fácil de entender construyamos una pequeña aplicación de chat. Primero te mostraré la aplicación. Así es la aplicación. Puedo crear una cuenta, crear un nuevo chat, y luego abramos esto solo en una pestaña incógnita como si fuera otro dispositivo, crear otra cuenta. Ooh, y aquí es donde veremos si el wifi funciona bien. Pero sí, puedes ver, puedo escribir aquí, y si la conexión fuera un poco mejor, está bien, es razonablemente rápido. Veamos cómo va la otra demostración más tarde. Suficientemente simple tiene sentido. Probablemente no sea demasiado difícil construir esto tú mismo usando otra tecnología, pero déjame mostrarte lo sencillo que es construirlo con Jazz.

Así que echemos un vistazo al código para construir esta aplicación. Así que como antes, te prometí que todo lo que tienes que hacer es definir tu modelo de data y construir tu aplicación. ¿Cómo se ve el modelo de data? Básicamente un chat no es más que una lista colaborativa de mensajes, ¿verdad? Y luego los mensajes son solo un mapa colaborativo con una única propiedad de texto. Eso es todo. Ese es todo el modelo de data para nuestra aplicación. Todo lo demás es solo UI. Así que guardemos eso. Echemos un vistazo a nuestro código de nivel superior. Puedes ver que son solo cosas estándar de React. con el proveedor de jazz donde podemos conectar un proveedor de autenticación y una clave API y eso es todo. ¿Cómo se ve nuestra aplicación? Viste en la página de inicio, solo había esto, básicamente tenemos la página de inicio y luego tenemos la vista para una ventana de chat individual. Eso es solo enrutamiento basado en hash simple en la página de inicio con el botón que crea un nuevo chat antes de la primera vez que interactúas realmente con jazz.

Así que veamos eso con un poco más de detalle. Usamos este hook de Jazz que nos da este objeto llamado me, que representa al usuario actual. Y entonces, como usuario actual, podemos empezar a hacer cosas directamente en el manejador de clics del botón. Así que puede ser como, vamos a crear un grupo conmigo como administrador, y luego podemos añadir miembros a él por simplicidad. Estamos añadiendo literalmente a todos para que sean escritores. Así que podemos simplemente compartir el enlace y otras personas pueden contribuir dentro de ese grupo.

Y luego creamos un objeto que pertenece a ese grupo en este caso, una lista. Y podemos ser agradables y precisos con los tipos aquí usando nuestro modelo de data de antes. Y eso es el chat. Y eso es todo. Eso es todo lo que tengo que hacer. No tengo que hacer ninguna solicitud ni nada. Simplemente creo el objeto localmente y en segundo plano, será sincronizado y persistido.

Así que ahora todo lo que necesitamos hacer es navegar a la vista para el chat, ¿verdad? Un poco más complejo, renderizando la ventana del chat en sí y añadiendo mensajes a ella. De nuevo, vamos a repasarla poco a poco. Te hablé antes de esta cosa llamada auto-sub para suscripciones automáticas. Ese es el otro hook. Y eso es realmente lo que te da acceso a todo el poder de Code Jason. Simplemente dices que quieres suscribirte automáticamente a este chat por su ID. Y te da este objeto chat que siempre contiene la versión más actualizada del chat y cualquier objeto anidado dentro de él que estés intentando acceder.

Así que podemos simplemente mapear eso ya que es una especie de lista. Y para cada mensaje, renderizar una burbuja de chat con el mensaje. Notarás el encadenamiento opcional aquí. Básicamente al acceder a cada mensaje y al texto dentro del mensaje, eso desencadena internamente auto-sub para buscar estos objetos si aún no están cargados. Y usando el encadenamiento opcional, podemos escribir eso muy rápidamente. Obviamente, si quieres mostrar indicadores de carga o algo así, puedes imaginar cómo se vería eso, pero para mantenerlo simple, se ve así. Más interesante, como viste en la aplicación de chat, estamos renderizando quién publicó el mensaje y cuándo fue publicado. Para características colaborativas como esa, no necesitamos escribir ningún código extra porque toda esa información existe dentro de los metadatos de edición de los co-valores, y están realmente fácilmente expuestos desde auto-sub así que podemos simplemente usar la propiedad especial .meta y básicamente preguntar a Codejson, Oye, ¿quién insertó el mensaje en el índice i, consígueme su perfil y consigue el nombre en ese perfil. También hay este ayudante que me muestra si fui yo así que puedo renderizarlo fácilmente en el lado derecho o izquierdo. Y por supuesto, también tengo acceso al tiempo de esa edición.

Lo último que queremos es enviar un nuevo mensaje al chat, ¿cómo se ve eso? Recuerda que teníamos nuestro grupo que determina quién tiene acceso al chat y obviamente queremos crear el mensaje del chat dentro de ese mismo grupo. Así que podemos usar de nuevo los metadatos del chat para obtener el grupo y luego creamos un mapa de tipo mensaje con nuestro texto y lo añadimos al chat por ID.

Eso es todo. Eso es todo lo que necesita hacerse. Y lo loco es que como es tan simple, esta es toda nuestra aplicación, cabe en una pantalla para completar, aquí están los componentes para la burbuja del chat, pero eso es solo un tonto que solo renderiza cosas y la entrada que solo suelta como un elemento de entrada nativo, ¿verdad?

Así que eso es ahora completamente toda la aplicación, 82 líneas de código para implementar el chat. Si lo pongo así, se vería un poco feo. Así que vamos a darle un toque con Tailwind. Y ahora esa es realmente la aplicación tal como la viste, sí, el Tailwind. Genial. Espero que tenga sentido. ¿Quieres ver una aplicación más? ¿Algo un poco más complicado? ¿Qué tal Twitter? Vamos a reconstruir todo Twitter con Jazz rápidamente. Bueno, quizás algo de él. ¿Cómo deberíamos llamarlo? Shop the Arts, Cleaner, Twitt. Estaba considerando conseguir el dominio pero pensé que era un poco decadente para una pequeña demostración. Esta demostración puedes probarla tú mismo y la probaremos juntos. Y nunca la he probado con tanta gente antes. No tengo idea de cómo manejará el WiFi, pero vamos a intentarlo. Lo haré de nuevo aquí. Así que es twitt.jazz.tools, inicio de sesión como yo mismo. Y luego puedo publicar cosas aquí. Eso lo está haciendo de nuevo. Sí, ahí vamos. Vale. Puedo responderme a mí mismo. Avísame si aparece para ustedes en absoluto. Oh sí. Genial. Veo que los mensajes están llegando. Genial. Y ves que reacciona bastante rápido.

Todo lo que hago es instantáneo. Puedo ir al perfil de alguien. Puedo, quizás vaya a mi propio perfil. Puedo subir una foto de perfil. Como dije antes, puedes subir archivos a CoJson. Boom. Tengo una foto de perfil. Eso debería aparecer para todos. Y estás viendo algunos estados de carga parcial aquí. Probablemente el wifi no esté del todo preparado para ello. Probé esto con miles de bots solo para asegurarme, oh, ahí vamos. Pero lo genial es que, sí, todo se carga eventualmente. Y para las cosas que están disponibles, tienes interacción instantánea. Esto incluso funcionará sin conexión. No voy a hacer eso ahora, pero podría apagar mi wifi, publicar algunas cosas, volver a encender el wifi. Y simplemente se sincronizaría con ustedes.

Probemos una última cosa. Subiendo una foto de un gato porque eso es para lo que sirve Internet, ¿no es así? Genial. Sí. Sí. Y puedes ver que con las fotos, incluso hay una transmisión progresiva y se van haciendo disponibles poco a poco. Increíble. Oye, eso está funcionando realmente bien. Genial. Sí. Puedes seguir jugando con esto.

Terminaré rápidamente mi presentación. Realmente no tengo tiempo para explicar el código para el ejemplo de Twitter. Puedes encontrar eso en GitHub. Pero muy rápidamente, como viste antes para el chat, estaba básicamente determinado por el modelo de data y luego la interfaz de usuario es bastante obvia alrededor de él. Entonces, para Twitter, todo lo que es un Tweet, es un mapa colaborativo que tiene un texto. Puede tener un array de imágenes. Oh, lo siento. Como una lista de imágenes. Y luego, para los 'likes' y las respuestas, esa es la primera vez que vemos co-stream. Así que lo explicaré rápidamente. Puedes ver que un stream de 'likes' es un co-stream de corazón o nulo. Y lo que eso significa es que para cada participante, el estado de si le gustó un Tweet o no es separado. Y podemos contar cuántas personas actualmente les gusta o no. Y eso es realmente simple de usar de esa manera. Y luego tenemos nuestro perfil. Eso también es bastante obvio.

En realidad, ya que tenemos un poco de tiempo, permíteme mostrarte un huevo de pascua en la aplicación. Porque si vas a tu perfil, tienes una biografía, ¿verdad? Y creo que algo que es un poco aburrido acerca de Twitter es que no nos deja expresar nuestra individualidad tanto como, recuerda en los viejos tiempos los foros, cuando podías tener pies de página personalizados y cosas así. Así que algo que hice aquí es que si pones en tu biografía, algo que es válido, algo de react CSS, entonces todos tus tweets se verán afectados por eso. Oh, veo que otras personas están publicando gatos.

Perfecto. Esto está funcionando maravillosamente. Incluso Elan llegó aquí. Genial. Para terminar muy rápidamente, ¿qué sigue para Jazz? Mencioné antes que habrá texto plano colaborativo y texto enriquecido. Eso es obviamente lo que muchas aplicaciones necesitan para Jazz. Habrá más proveedores de autenticación con los que quiero integrar, como Auth0. En realidad hay otro que ya puedes usar basado en Touch ID, donde las claves de cifrado del usuario se almacenan con datos biométricos, lo cual es bastante genial. Obviamente quieres la presencia del usuario, así que haré algunas bibliotecas listas para usar para cursores y tarjetas de texto. Algo que es realmente interesante, puedes imaginar cómo construir una nueva aplicación desde cero con Jazz, pero también quiero permitirte adoptarlo de manera incremental con aplicaciones existentes. Entonces, la forma en que eso funciona es básicamente que Jazz sincroniza tus datos multijugador de nuevo en tu base de datos existente, y luego puedes construir nuevas características multijugador geniales que aún pueden hablar con tus características antiguas usando la API o lo que sea que usaste para construir eso. Y dado que podemos hacer archivos y medios, también podríamos hacer llamadas de video y audio dentro del mismo modelo. Ese es más o menos mi plan. Y como dije, estamos apoyando a React y a JavaScript independiente del navegador en este momento. Tener soporte para React Native obviamente sería genial. Y luego, en el lado del servidor, no Jazz, Dino y Bon y más adelante otros lenguajes desbloqueando aplicaciones nativas todas hablando el mismo protocolo y simplemente pudiendo hablar entre sí. Genial. Muchas gracias por escuchar. De nuevo, toma una foto de esto. Curiosamente, creo que casi cubriste la primera pregunta que tuvimos. Esa fue la mejor valorada. Bien. Con tu explicación de qué sigue para Jazz. Así que aquí tenemos una de nuestras preguntas mejor valoradas es cómo se almacenan estos datos en el servidor? ¿Hay una base de datos detrás de esto y entraste un poco en eso? Notas rápidas para donde te encuentras actualmente. Así que si tienes curiosidad, la malla global hace la persistencia en la nube y se llama malla porque es literalmente una malla de servicios y ellos, almacenan y cachean datos localmente. Y luego se respalda en un almacenamiento de blobs. Pero básicamente existe cerca del borde dependiendo de dónde los usuarios lo accedan. Y se sincroniza entre todos los diferentes nodos del mensaje según sea necesario. Espero que eso responda a esa pregunta.

Creo que eso responde a eso. Hay una similar aquí, de, Oh, tenemos algo de movimiento. Aquí vamos. ¿Puede la malla global ser auto-alojada? Sí. Como es de código abierto, podrías ejecutar tu propio servidor de sincronización, y hay incluso si vas al repositorio, algo llamado code, Jason, simple sync que puedes ejecutar como un servidor de sincronización local, o podrías ejecutarlo en un solo servidor. Obviamente, si quieres escalarlo, como estoy tratando de proporcionar la mejor infraestructura posible y tiene un nivel gratuito, pero es realmente importante para mí que no haya bloqueo. Así que esa es la situación allí.

Genial. Tenemos aquí ¿está Jazz construido en websockets? Socket.io también utiliza su propio tipo de websockets, pero no puedes conectarlo por websockets regulares y tienes que usar su propio sistema. Creo que. Sí. Así que sí utiliza websockets y tiene como su propio protocolo para sincronizar encima de eso. Um, a largo plazo, realmente no quiero estar completamente casado con websockets porque hay cosas más interesantes que vienen como web transport o quick que ayuda si necesitas sincronizar muchos valores independientemente, porque con websockets es una única conexión TCP, así que puedes obtener algo llamado bloqueo de cabeza de línea, donde si sincronizas un valor enorme, todo lo demás tiene que esperar a que se sincronice. Mientras que con web transport y quick, puedes sincronizar cosas en paralelo, priorizarlo. Y eso te da una experiencia mucho más suave para aplicaciones ricas y complicadas. Lo bueno es que, si usas jazz, no tienes que preocuparte por nada de eso. Solo interactúas con los valores centrales y en algún momento en el futuro, insertaré el soporte de web transport o quick, y simplemente funcionará mejor. Así que sí.

Genial. Estoy planeando un proyecto en mi cabeza. ¿Es code Jason algo que inventaste o es algo que ya existía como un estándar cuando fuiste a construir jazz? Así que code Jason, como mi invención es básicamente y será un estándar y es como una cierta implementación de CRDTs más la forma en que funcionan los derechos de acceso basados en cifrado y firmas y todo ese paquete es lo que es code Jason. Y eso es lo que he estado construyendo durante los últimos tres años aproximadamente. Genial. Felicidades. Amor en la multitud. No, realmente me gusta cómo estás votando de manera responsable diferentes preguntas porque tenemos seis votos en la siguiente. ¿Cómo maneja Jazz las diferentes versiones de la aplicación? Así que esa es la mejor y la pregunta más difícil. Básicamente Jazz tiene una versión simple de algo como migraciones donde puedes migrar la cuenta de usuario y la raíz de data que almacenas allí. Es un poco complicado porque está en un sistema distribuido. Así que sucede en el cliente y puede suceder en diferentes momentos en la investigación de CRDT.

Creo que ese es uno de los problemas más grandes sin resolver. Y básicamente lo que quiero hacer es proporcionar algunas herramientas muy básicas para hacer eso. Y a medida que la gente lo está utilizando, ver qué tipos de patterns emergen y luego apoyar esos patterns con soluciones integradas. Así que estoy pensando en algo como migraciones de database más algo como Zot data validation y ser capaz de definir tu esquema de una manera que permanezca compatible con el futuro y hacer eso lo más suave posible para los desarrolladores de aplicaciones. Pero sí, eso es algo que estoy muy emocionado de explorar junto con ustedes. Emocionante. Y tenemos, creo que tiempo para quizás un par más. Tenemos aquí, ¿cómo se maneja la concurrencia por Mesh? ¿Cuáles son algunos de los, es esto cuellos de botella aquí? Estoy como, no estoy muy seguro de lo que quieres decir con eso. Definitivamente es difícil de escalar porque tienes muchos clientes a la vez y la idea de code. Jason es que los objetos individuales pueden ser bastante pequeños y puedes sincronizarlos de manera granular. De hecho, para preparar esta demostración, como dije, realicé algunas pruebas de estrés y en un solo núcleo de CPU de Mesh, puedo manejar unas 50,000 transacciones por segundo. Y en el ejemplo del tweet eso corresponde a unos 400 usuarios a la vez. Y de nuevo, obtienes beneficios de escala porque la gente suele interactuar con los mismos valores. Y si todos están almacenados en caché en el mismo servidor, eso hace las cosas mucho más fáciles. No sé quién hizo la pregunta. Si, si tienes una pregunta más detallada, no dudes en acercarte a mí más tarde y estaré encantado de, de entrar en más detalle sobre eso. Sí. Y luego nos dirigiremos a la zona de preguntas y respuestas del orador. Así que asegúrate de ir allí cuando hagamos una pausa en unos dos minutos. Así que tenemos un par más, supongo que tenemos, podemos ir con, quiero decir, esta pregunta está cargada de cumplidos. Fue un proyecto muy cool. Así que felicitaciones allí. ¿Cómo soporta JAZZ la sincronización de múltiples dispositivos para el mismo usuario? Lo que te mostré es multijugador, pero los múltiples dispositivos son en realidad el caso más aburrido y simple donde, um, lo que puedes hacer es probar el ejemplo de to-do en el GitHub que utiliza la authentication basada en touch ID. Y lo que eso significa es que, si creas una cuenta en tu portátil y, uh, se sincronizará, si usas Safari o Chrome, esta cuenta se sincronizará en tu dispositivo móvil y puedes usar face ID allí y verás que estás conectado a la misma cuenta y de la misma manera todo se sincroniza entre múltiples usuarios. Todo también se sincroniza entre múltiples dispositivos. Así que literalmente, no necesitas hacer nada. Simplemente obtienes soporte multi-dispositivo gratis si construyes una aplicación con JAZZ. Creo. Tenemos algunos descansos de última hora. Iba a, iba a pedirte que simplemente eligieras uno para romper el empate,

Interesante. Dando un poco de libertad a los desarrolladores. Muchas gracias, Hans-Simon. Lo aprecio. Gracias.