Estado Colaborativo en Tiempo Real en el Borde

Hola a todos. Mi nombre es Steven y he vivido en muchos lugares. Así que, estoy dando esta charla desde París hoy, pero he vivido en muchos lugares diferentes. Pasé, ya sabes, 7 ½ años en Australia, en Sydney, incluso viví en Quebec antes de eso por un poco, y también pasé unos años en la ciudad de Nueva York. Así que, sí, es genial estar aquí hoy. Y lo que quiero decirles es que soy un gran nerd de las herramientas de design. Me encanta construir. Me encanta diseñar herramientas de design. Me encanta crear aplicaciones y cosas que la gente usa a cambio y crea algo con esa herramienta que ayudé a hacer. Y entonces, este es el ángulo de mi charla. Soy un gran nerd de las herramientas de design y me encanta hacer este tipo de herramientas creativas. Así que, trabajé en Facebook Messenger por un tiempo en el equipo de sistema de design / Messenger para ayudarles con sus necesidades de tooling internamente. También pasé algún tiempo en una empresa llamada Campaign Monitor en Australia cuando estaba en Sydney. Y, mi principal proyecto allí fue trabajar en este constructor de correos electrónicos. Así que, era una herramienta de arrastrar y soltar donde podías design hermosos correos electrónicos que eran como responsivos, así que funcionaban en móvil y escritorio. Y ayudamos a las marcas a crear esos correos electrónicos de una manera muy fácil de arrastrar y soltar. Esa fue realmente la primera vez que me introdujeron a las herramientas creativas. Eso eventualmente me llevó a crear Easy. Y Easy, no sé si algunos de ustedes han oído hablar de él, es bastante antiguo ahora, era una herramienta para ayudar a los diseñadores a crear animations para la web, y luego hacer eso sin tener que codificar. Y luego solo podías hacer clic en eso y obtener el CSS de ello. Fue bastante genial. Disfruté trabajando en eso. Y eso eventualmente me llevó a unirme a InVision. Y así en InVision trabajé en el equipo responsable de crear InVision Studio. Trabajé en eso durante cuatro años y medio. Y no sé si ustedes están familiarizados con InVision Studio. Pero eso era esencialmente una herramienta de design de interfaz de usuario donde podías, ya sabes, obviamente design aplicaciones, sitios web, pero también crear animations para ellos y prototiparlos, hacerlos muy interactivos. Y esto suena bastante obvio, pero en aquellos días no había muchas herramientas que pudieran hacer ese tipo de cosas. Y realmente, esa experiencia realmente me llevó al camino en el que estoy hoy. Teníamos, ya sabes, era una aplicación de escritorio que trabajaba en el sistema de archivos, y Figma era esta increíble herramienta basada en el navegador para hacer design de interfaz de usuario y ese tipo de cosas estaba empezando a ser realmente popular.

Y una cosa que Figma hizo realmente bien es que, como dije, el producto funcionaba en el navegador, lo que significa que no tienes que descargar una aplicación para que funcione, y era lo que ellos llamaban multijugador. Y entonces, eventualmente tuvimos este proyecto en InVision para convertir InVision Studio de una aplicación basada en archivos de escritorio, disculpa me, a una aplicación que era basada en el navegador y colaborativa por defecto. Y entonces lideré el design para el proyecto, y esta es la primera vez que realmente me expuse al problema de, maldita sea, esto es muy difícil de hacer. Teníamos un escuadrón dedicado de, creo, en el pico, siete ingenieros, un gerente de punto, y yo era el diseñador que encabezaba esa iniciativa. Y tomó más de un año y medio antes de que pudiéramos tener una versión funcional de esa aplicación multijugador basada en el navegador, un año y medio. Eso es mucho tiempo. Y, sí, eventualmente estaba un poco frustrado con esto porque era como esto, simplemente no entiendo cómo esto podría llevar tanto tiempo. Pero eso es así. Como que lleva mucho tiempo construir ese tipo de experiencias cuando haces todo eso tú mismo. Y al estar expuesto a eso no me di cuenta, pero eso eventualmente me llevó al camino en el que estoy hoy. Dirijo una empresa llamada LiveBlocks y en LiveBlocks lo que hacemos, proporcionamos APIs y herramientas a desarrolladores como ustedes para construir experiencias multijugador, pero también más ampliamente experiencias colaborativas como comentarios y prácticamente cualquier cosa que quieras hacer que sea colaborativa y requiera que varias personas trabajen juntas en algún tipo de experiencia digital. Pero no te preocupes. Esto no es un discurso de ventas. Prometo que solo estoy aquí para compartir mis aprendizajes y profundizar en los entresijos de esas infraestructuras, el tipo de infraestructura necesaria para construir ese tipo de experiencias. Pero sí, solo para mostrar que este problema que enfrenté personalmente con mi co-fundador Guillaume en InVision se ha convertido, quiero decir, siempre ha sido un problema, pero más en los últimos años ha habido muchas tecnologías y frameworks para trabajar en este problema. Y entonces muchos de esos frameworks y herramientas cuando hablan de esto a menudo se refieren a multijugador. Pero en el mundo de la colaboración, cuando construyes un producto SaaS colaborativo, el multijugador es solo la punta del iceberg. Hay muchas más cosas en las que pensar al construir un producto colaborativo, ¿verdad? Necesitas pensar en, bueno, cuando mis usuarios están en mi producto, ¿cómo pueden dejar comentarios? ¿Cómo pueden mencionar a sus compañeros de trabajo o colaboradores en comentarios, en anotaciones específicas dentro del documento, para que esas personas terminen colaborando de manera asincrónica y puedan unirse al documento y ser notificados en otro lugar? También hay diálogos compartidos, como ¿cómo compartes un artefacto o algo con alguien más? ¿Cómo agregas a esas personas? ¿Cómo te encargas de los permisos para esas personas? Y luego, obviamente, una vez que tienes esos documentos y esos artefactos colaborativos funcionando, ¿cómo los navegas? ¿Cómo los encuentras? ¿Cómo encuentras todos esos documentos? ¿Cómo compartes ese conjunto de documentos? ¿Cómo los pones en una carpeta y ese tipo de cosas? Así que la navegación de documentos es una gran parte de eso. Y luego, obviamente, cosas como audio y video se están volviendo cada vez más presentes. Así que si quieres hacer una reunión de audio, puedes hacer ese tipo de cosas. Compartir como un video mientras trabajas en algo. Tener esa experiencia directamente en la herramienta se está volviendo cada vez más relevante para una experiencia colaborativa. Y entonces, si retrocedemos y pensamos en cómo llegamos al estado en el que estamos hoy en términos de productos SaaS colaborativos. Para mí, realmente comenzó con Google Docs. Creo que fue hace 15 o 20 años en este punto. Introdujeron esto no es la captura de pantalla. Ves, esto es mucho más reciente, pero introdujeron Google Docs, un documento basado en el navegador o similar a Microsoft Word. Y fue alucinante. Como que podrías abrir una URL y esa URL era prácticamente un documento de Word. Y podrías editarlo.

Podrías copiar esa URL, pegarla a otra persona. Pegada a otra persona, y esa otra persona estaría en el mismo documento contigo colaborando. Y luego, probablemente una década después, Figma comenzó a trabajar en su producto. Estaban creando esta herramienta de design, la hicieron basada en el navegador y lo que hicieron con Figma es que revolucionaron la industria del design para que las personas pudieran trabajar directamente en el navegador. Y ahora no solo los diseñadores podían realmente diseñar archivos o tener acceso a esos archivos de design, hicieron que el proceso de design estuviera disponible para muchos más que los diseñadores.

Ahora tienes desarrolladores que entran en Figma para inspeccionar los elementos con el fin de ayudar a construir esas interfaces de usuario que los diseñadores arman. Tienes stakeholders, fundadores, sabes, personas de nivel C que pueden entrar en los archivos, revisar y experimentar con el design. E incluso tienes, como, personas de producto o prácticamente cualquiera que desee hacerlo puede simplemente entrar en un archivo y jugar con algunos de los componentes que son preconstruidos por el equipo de design y comenzar a diseñar algunas de esas cosas ellos mismos. Figma ha tenido mucho, mucho éxito. Y creo que lo que mostraron con su producto es que puedes hacer una herramienta de alta calidad, de alto rendimiento que normalmente solo estaba basada en el escritorio. Puedes poner eso en el navegador y hacerlo colaborativo. Y de repente obtienes tantos beneficios para que la organización colabore sin problemas juntos en un solo espacio. Y obviamente hay más empresas hoy en día, sabes, que tienen ese tipo de experiencias colaborativas multijugador por defecto.

Canva es una de ellas, Mural, obviamente para hacer pizarras blancas, Notion, Mirror, Linear ha sido realmente genial en eso para el software de gestión de tickets y obviamente Pitch para hacer presentaciones como esta. Y para habilitar la colaboración multijugador, necesitas pensar en la resolución de conflictos. ¿Y qué es la resolución de conflictos? Esencialmente, cuando estás en este mundo donde varias personas pueden manipular el mismo estado del documento, necesitas poder resolver. Acciones conflictivas de diferentes personas que se están procesando al mismo tiempo. Y entonces, si tienes a alguien solicitando hacer ese rectángulo rojo y a alguien solicitando hacerlo un círculo, ¿qué haces en ese punto, sabes, lo haces simplemente rojo o lo combinas, lo haces rojo y lo haces un círculo. Necesitas pensar en esas cosas cuando estás en el mundo multijugador.

Y para hacer eso, hay dos algoritmos principales para habilitar esto. Las transformaciones operacionales, que modifican las operaciones, son típicamente utilizadas por Google Docs para usar OTs. Y luego tienes los CRDTs, que significa, nunca lo recuerdo, Conflict Free Replicated Data Type, y esos modifican el estado del documento. Bueno, eso es bastante confuso y yo también estoy muy confundido, son muchas siglas y es bastante difícil de usar. Y entonces hay algunos marcos de trabajo CRDT por ahí que hacen esto realmente, realmente bien. Yjs es uno de ellos, y básicamente te proporcionan diferentes tipos de data como right array, right map, right text y más para encargarse de esa complejidad y asegurarse de que si interactúas con esos tipos de data, no tienes que preocuparte por la gestión de conflictos. Yjs se encargará de eso por ti. Auto merge también es uno que es genial, viene con diferentes tipos de data, contadores, listas, valores de texto, y básicamente manejan todo eso por ti también. Y son bastante fáciles de usar, ¿verdad? Como, este es solo un ejemplo de por qué si quieres hacer un array, simplemente haces un nuevo wide array, empujas el contenido a él y desplazas el contenido, y también puedes eliminar un índice. Así que es muy similar a cómo interactuarías con un array estándar de JavaScript, excepto que se aseguran de que todos siempre van a ver los mismos data, incluso si hay varias personas manipulando ese array al mismo tiempo. La cosa, sin embargo, es que los CRDTs pueden ser difíciles de usar y escalar en producción.

Tienes que pensar en la migración de data, como, ya sabes, si eres una aplicación de producción seria, quieres poder decir, como, mis data van a parecer así y quieres poder evolucionar eso con el tiempo. Así que eso puede ser bastante difícil de hacer. La validación de esquemas, ya sabes, muy similar a la migración de data que está vinculada con uno al otro, pero ser capaz de actualizar el esquema de un documento a lo largo del tiempo a medida que tu producto evoluciona, es bastante importante también.

Y así, una de las grandes cosas también con los CRDTs es que los data pueden ser muy, muy complejos porque la mayoría de los cambios suelen almacenarse. Y así, en lugar de tener una representación JSON de un documento, normalmente tienes todos los cambios que han ocurrido con el tiempo. Y eso a menudo lleva a un tamaño de documento potencialmente muy grande, incluso si visualmente como la representación JSON real puede ser pequeña, esa representación JSON está hecha de todos los cambios que han sucedido. Y eso puede llevar a un archivo bastante grande, especialmente si ese archivo ha estado presente durante años y muchas personas interactuaron con él. Y para ilustrar esto, juntamos este este ejemplo construido con TipTap, Yjs y Liveblocks. Y como puedes ver, los data son bastante básicos, ¿verdad? Es solo un encabezado y un párrafo. Se ve así. Es como, ya sabes, XML, prácticamente encabezado de nivel uno. Puedes ver aquí en el código con un párrafo. Y es bastante básico. Pero resulta que ese documento está hecho de muchos, muchos cambios.

Esto es solo una pequeña muestra, pero esa lista sigue y sigue y sigue. Y puedes desplazarte probablemente durante un par de minutos sin llegar al final de esos cambios. Y si miras cómo se ensamblan esos cambios, se parecen mucho a esto. Esta es una herramienta que construimos. Es una extensión de navegador DevTools que te permite inspeccionar tu experiencia Yjs para entender cómo se ha construido el documento. Puedes ver las dependencias entre los cambios y lo que lleva a esa representación de los data. Y así, sí, los data al final son bastante simples. Pero la representación en sí es bastante simple. Pero los data que hacen esa representación pueden ser bastante complejos y llevar a un tamaño de archivo bastante grande al final.

Y lo que acabamos de ver es solo la punta del iceberg. Es solo la parte multijugador. Hay muchas más cosas en las que pensar, como dije antes. Y así, si miras, solo seleccioné como cuatro productos SaaS que hacen la colaboración realmente bien, todos tienen patterns similares, ¿verdad? Si miras Google Notion, Figma y Pitch, todos tienen algún tipo de diálogo compartido donde puedes invitar a otras personas, copiar el enlace y también establecer permisos específicos para esas personas. Como, ¿puede esta persona editar el archivo? ¿Es esa persona el propietario de un archivo? ¿Solo pueden ver ese archivo? Esas son las cosas que los productos multijugador también necesitan habilitar. Comentarios y menciones. Como una gran colaboración necesita comentarios. Como si quieres poder colaborar, es probable que no siempre todos vayan a estar en el mismo archivo al mismo tiempo. Quieres poder comentar y colaborar también de forma asíncrona. Así que en Google, puedes comentar, puedes mencionar a personas y eso es lo mismo en todos los casos. Y luego la navegación de documentos. Todos tienen algún tipo de vista de espacio de trabajo, ya sabes, donde puedes navegar por tus documentos junto con otras personas. Puedes crear carpetas y esas personas pueden acceder a esas carpetas y navegar los documentos. Y luego no todos, pero creo que este es un patrón que vamos a ver surgir en más y más herramientas de colaboración. El audio y el video juegan un gran papel en algunas de las herramientas como Pitch, por ejemplo, te permite tener video directamente en tu presentación para que mientras te mueves con tu cursor, tu cara está esencialmente unida al cursor, dando a todas las personas en el documento una sensación de presencia y de estar juntos en la misma sala contigo. Y luego si miras Figma, Figma tiene esta característica de audio huddle, que te permite entrar rápidamente en una llamada de audio con alguien más que está mirando el mismo documento que tú. Haciendo que sea muy fácil y sin fisuras colaborar con esas personas en tiempo real. Y así, si miro todas esas empresas, todas hacen un gran trabajo. Pero creo que hay una que definitivamente destaca para mí y ha sido muy inspiradora para lo que hacemos en Liveblocks. Definitivamente es Figma. Creo que Figma ha sido genial al ensamblar todas las características de colaboración requeridas de una manera muy agradable para que trabajen juntas sin problemas.

Y como usuario, terminas teniendo una gran experiencia colaborativa, casi como si estuvieras en el mismo espacio físico con alguien más. Y si hay una publicación de blog que recomendaría de ellos y especialmente de Evan Wallace, quien fue el cofundador de Figma y el CTO durante varios años allí, él explica cómo funciona la tecnología multijugador. Y es una brillante publicación de blog con muchas ilustraciones interactivas que hacen muy fácil entender cómo funciona todo eso.

Y así, el trabajo que Evan y Figma hicieron finalmente llevó a Guillaume, mi cofundador y a mí a esta pregunta. ¿Qué construirían los desarrolladores si pudieran acceder a la infraestructura de Figma a través de React hooks y componentes? Esto es algo que realmente desearíamos haber tenido en Invision cuando estábamos convirtiendo esa aplicación basada en escritorio en una aplicación colaborativa multijugador basada en navegador. Y así, finalmente pensamos, vaya, eso sería... Esto es tan difícil de construir. Como, ¿por qué no tenemos eso como React, algunos React hooks y componentes y lo hacemos muy fácil para los desarrolladores de front-end construir ese tipo de experiencias sin tener que preocuparse por toda esa infraestructura de backend compleja? Y así es como se crea LiveBlocks. Tropezamos con esta idea mientras trabajábamos en una herramienta de presentación video. Y mientras trabajábamos en esa herramienta, nos dimos cuenta, vaya, esto se parece mucho a lo que experimentamos en Invision, como que estamos pasando un tiempo terrible tratando de descifrar el aspecto en tiempo real de las cosas y muy poco tiempo realmente enfocándonos en la herramienta. Y en ese punto, eso es cuando decidimos crear LiveBlocks.

Y una vez más, prometo que esto no es un auto-discurso. Solo quiero mostrarte un poco más. El lado práctico de esto, como para mostrarte algunas de esas experiencias múltiples, cómo funciona la infraestructura detrás de escena y cómo lo habilitamos en LiveBlocks. Y si piensas en las experiencias colaborativas que destacé antes, todas funcionan de la misma manera. Hay un artefacto central en el que varias personas colaboran y ese artefacto puede ser un documento de texto. Puede ser un pizarrón. Puede ser una herramienta creativa. Puede ser prácticamente lo que quieras. Y para construir ese artefacto central, hay varias cosas que necesitas para hacerlo colaborativo. Necesitas un concepto de presencia para que las personas que miran ese artefacto sepan quién está actualmente mirando este documento, mostrando los cursores en vivo, como mostrando eventualmente el video de la persona junto al cursor como hace Pitch, mostrando un stack de avatares en vivo, mostrando qué elemento han seleccionado las personas en el documento, ese tipo de cosas. Luego necesitas el concepto de transmisión. Correcto. Entonces, cuando estás en una sala, quieres poder transmitir eventos a las otras personas que actualmente están en la misma sala que tú. Entonces, si quieres hacer cosas como reacciones en vivo, por ejemplo, un emoji de fuego en este elemento, lo que sea que hagas clic, transmites un evento y otras personas pueden entonces mostrar ese emoji de fuego al mismo tiempo. Y luego está el núcleo del documento en sí. Necesitas una tienda de data para almacenar el documento de los data y esa tienda de data necesita permitir a las personas hacer ediciones a los mismos data al mismo tiempo. Y eso es lo que permiten los CRDTs como Yjs o como auto merge o algunos otros frameworks por ahí. Y finalmente, necesitas comentarios. Entonces, los comentarios son más para la colaboración asincrónica, pero quieres poder comentar y anotar en partes específicas de ese documento para que cuando menciones a alguien allí, esa otra persona recibe una notificación y se incentiva a entrar en el producto y colaborar y ver lo que han hecho las demás personas.

Pero esta es una masterclass bastante corta, así que solo me centraré en la parte del documento y cómo funciona. En LiveBlocks, tenemos dos formas de almacenar documentos, por lo que tenemos nuestra propia solución propietaria llamada Almacenamiento de LiveBlocks, y también recientemente introdujimos una forma de almacenar documentos Yjs directamente en la infraestructura de LiveBlocks. Y si miramos el almacenamiento, tenemos tres tipos de data por ahora. Así que LiveList, LiveMap y LiveObject. Y quería profundizar en el caso de uso de la lista porque creo que es uno que es agradable de resaltar visualmente.

Entonces, si tomas una lista, hay tres elementos en esa lista, A, B, C y tienes una persona que a la izquierda movió el elemento B de la lista a la última posición y la persona a la derecha decidió insertar un nuevo elemento en esa lista entre B y C. Ahora hay un servidor central aquí. ¿Cuál es la verdad de este documento? ¿Cuál es el nuevo orden de esa lista sabiendo que dos personas hicieron cambios en esa lista? Bueno, es difícil averiguarlo y la solución es la indexación fraccional. Y la forma en que esto funciona, por ejemplo, aquí es que cada elemento tiene un índice fraccional y ese índice se utiliza para definir el orden de esa lista. Y así, si alguien a la izquierda decide poner el segundo elemento al final de la lista, ese nuevo elemento va a obtener un aumento fraccional por lo que se convierte en 0.4. A la derecha, sin embargo, esta persona decidió insertar ese elemento entre el segundo y el último elemento de la lista. Y lo que esto hace es que toma el elemento anterior y el siguiente y encuentra el medio. Y por eso se convierte en 0.25 y luego el servidor puede reordenar eso y encontrar el orden correcto. Entonces, 0.25 es el segundo elemento y el rosa, 0.4, es el último y esa es la reconciliación que vemos. Y boom, las dos personas obtienen exactamente la misma lista una vez que se ha resuelto. Y esto es bastante fácil de hacer con el almacenamiento de LiveBlocks. Entonces, puedes crear una nueva LiveList. Es muy similar a una lista estándar de JavaScript, excepto que es una LiveList de LiveBlocks. Y aquí tienes un orden. Luego puedes decidir insertar un elemento en la lista y convertir eso en un array y este es el resultado que verás. Entonces, en este ejemplo, parece exactamente como un array normal de JavaScript. Pero aquí puedes imaginar que varias personas podrían estar haciendo esto al mismo tiempo y nos encargamos de la indexación fraccional detrás de escena para asegurarnos de que todos vean una lista única ordenada en base a todas las acciones que todas las personas han tomado en esa lista.

Pero luego hay otra parte obviamente grande de esto, que es bastante, bastante compleja y en eso es en lo que pasamos mucho tiempo, es la infraestructura que alimenta el lado en tiempo real de las cosas y asegurándonos de que todo eso se escala muy bien. Y si has trabajado en servidores WebSocket antes, sabrías que mantenerlos y escalarlos en producción es muy difícil. Son realmente difíciles de escalar, difíciles de manejar, manejar la conexión puede ser desafiante y hay muchos casos límite.

Y este es solo un ejemplo de nuestra, esta es una máquina de estado simplificada que armamos con Stately, que recomiendo encarecidamente. Es una herramienta fantástica. Y esta es la máquina de estado que usamos, simplificada de nuevo, para manejar las conexiones WebSocket en Liveblocks. Y hay un montón de casos límite a considerar. Por ejemplo, sabes, cuando terminas tu día de trabajo, vas a cerrar tu portátil y luego por la mañana lo abres de nuevo. Realmente necesitas reiniciar la conexión WebSocket, necesitas hacer un mecanismo de ping pong para verificar si la conexión aún está activa. Hay muchos casos límite como este que fueron bastante difíciles de mapear. Y usamos esta máquina de estado para crear todos los casos límite y asegurarnos de que como usuario de LiveBlocks, no tienes que preocuparte por pensar en la conexión WebSocket, nos encargamos de todo eso.

Y para escalar esto, sabes, y no tener un único punto de fallo, cada documento colaborativo, los llamamos salas, viven a milisegundos de distancia de las personas en el borde. Y lo que es genial de esto es que da a las personas un rendimiento absurdo, como, sabes, en la mayoría de los casos estás a 10, 60, 80 milisegundos del servidor, lo que significa que puedes obtener un rendimiento en tiempo real realmente rápido. Pero no solo eso, nos permite escalar esto horizontalmente, esencialmente, porque no hay un único punto de fallo y podemos tener tantas salas como queramos. Es solo un servidor central en el que las personas colaboran.

Y eso fue todo. Espero que esta charla haya sido agradable. Espero que hayas aprendido algo, y sí, muchas gracias por escuchar. Saludos. Adiós. Adiós. Saludos.