Local First – Colaboración Más Allá de la Nube

Así que, si eres alguien que construye aplicaciones con características colaborativas, mantente atento. Hoy, vamos a repensar fundamentalmente cómo construimos aplicaciones web, especialmente aquellas donde los usuarios trabajan activamente en lugar de solo consumir. Muchas de las aplicaciones que usamos a diario son principalmente para consumo. Piensa en un sitio de noticias o un servicio de streaming. Su función principal es entregarte información. Pero luego hay otras donde múltiples personas están creando y modificando contenido compartido activamente. Aquí es donde los usuarios realmente están trabajando juntos en un elemento compartido mientras también obtienen el beneficio de la información actualizada.

Un ejemplo principal de esto es Figma, donde diseñadores y desarrolladores colaboran en tiempo real en un solo lienzo. Algunos de los otros populares son Trello, Miro, Canva y Google Docs. Cuando pensamos en estas características colaborativas en estas aplicaciones, nuestro defecto es depender en gran medida de un gran servidor centralizado para impulsarlas. Y por una buena razón, estos servidores especializados en la nube ofrecen potencia y escalabilidad. Es una decisión obvia. Pero esta dependencia tiene un costo.

¿Alguna vez has experimentado una aplicación colaborativa que deja de funcionar cuando pierdes conectividad, dejándote incapaz de continuar tu trabajo? Bueno, el propósito de esta charla hoy es explorar una extensión a nuestras aplicaciones colaborativas de tal manera que puedan ofrecer experiencias increíbles sin ser retenidas por la conectividad y los desafíos de sincronización que vienen con no estar conectado a un servidor. Estoy aquí para presentar un paradigma que nos permite construir experiencias multijugador que prosperan offline, se sincronizan suavemente cuando están online, y aprovechan el valor del estado localizado, permitiendo a los usuarios poseer sus propios datos. Estoy aquí para presentar LocalFirst. Bueno, antes de entrar en modo de solución, déjame mostrarte cómo se comportaría una aplicación normal bajo condiciones de red impredecibles.

Tomaré el ejemplo de Trello, un gran producto que me encanta y que personalmente uso regularmente. Y en este tablero está mi plan para la conferencia. Con internet normal, como puedes ver, puedo cambiar entre carriles de natación y las tarjetas se mueven bien. Pero digamos que estoy trabajando en mi camino en un taxi y paso por un túnel, lo que significa internet irregular o lento para el caso. Y presiono actualizar. Toma un minuto, pero termina cargando y está bien. Todavía puedo trabajar.

Pero digamos que pierdo la conectividad por completo. ¿Qué pasa entonces? Como puedes ver, cuando me desconecto, puedes ver el pequeño mensaje emergente en la parte inferior izquierda que me dice que no puedo trabajar más. Y es posible que ya hayas notado que mi capacidad para hacer cambios está obstaculizada. Pero nada que un modo offline no pueda solucionar, ¿verdad? Simplemente haz que la aplicación sea una aplicación web progresiva para que esté disponible offline y deja que el trabajo continúe. Pero entonces, ¿qué pasa con la deriva?

Cuanto más tiempo siga trabajando offline, hay una alta probabilidad de que el colega que me ha estado ayudando a preparar haya hecho algunos cambios en el tablero. Mientras tomo el ejemplo de este tablero, un escenario más realista es el de Git, donde inherentemente mantenemos una copia local de nuestro código y luego tenemos que resolver conflictos manualmente a medida que aparecen. En pocas palabras, no es tan sencillo. Bueno, principalmente porque durante las últimas décadas, hemos construido nuestras aplicaciones en torno a una premisa simple.

Hay un servidor central en algún lugar que contiene la verdad. Nuestros clientes, ya sea móvil, web o de escritorio, son esencialmente solo ventanas a esa verdad. Cada interacción, cada cambio, cada pieza de datos generalmente tiene que ir y venir a esa única fuente de verdad. Bueno, este enfoque nos da una sensación de control, asegura la consistencia entre los usuarios y proporciona esa tan deseada única fuente de verdad para nuestros datos. Y funciona para muchas aplicaciones hasta que comenzamos a construir características colaborativas pesadas en nuestras aplicaciones.

Y luego, si una fuente central de verdad o la verdad central es lenta para responder o inalcanzable, la aplicación se detiene. La capacidad de respuesta instantánea que esperamos desaparece, y puede sonar un poco dramático, pero nuestros datos están retenidos como rehenes en un servidor para nunca ser vistos de nuevo. Bueno, aquí es donde tenemos la oportunidad de proporcionar una mejor experiencia de usuario, donde el paradigma local first ofrece una poderosa extensión a las capacidades de nuestras aplicaciones. Local first transfiere el control de los datos directamente al usuario en lugar de a la nube.

Tus datos residen en tu dispositivo, dándote acceso inmediato y propiedad. En cuanto a la consistencia entre los usuarios, lo reimagina completamente. A través de mecanismos de sincronización y estrategias de resolución de conflictos, que a menudo funcionan en segundo plano, las aplicaciones local first aseguran que, aunque tengas acceso inmediato a tus datos, tus cambios se propaguen eventualmente y de manera confiable a otros usuarios. Esto mantiene un estado compartido cohesivo sin depender de una conexión en vivo constante a un servidor central.

Y finalmente, el más impactante de todos, poder trabajar offline. Debido a que tus datos son locales, tus aplicaciones son instantáneamente receptivas. Ya no estás esperando viajes de ida y vuelta de red o procesamiento del servidor, ya sea que estés en una conexión Wi-Fi de Apache, en lo profundo de un túnel como estábamos, o incluso completamente sin Internet. Tus experiencias colaborativas continúan funcionando sin problemas.

Muy bien, comencemos viendo una pequeña demo de una aplicación que he creado. Esta es una aplicación que utiliza el enfoque local first. Y aquí mismo, hay dos instancias de una aplicación de lista de tareas ejecutándose en dos clientes diferentes imitados por dos navegadores. Podemos imaginar a dos usuarios diferentes usando esto, tú y tu colega. Y como puedes ver, a la izquierda está Panda y a la derecha está Paula. Cuando Panda a la izquierda añade un elemento a la lista de tareas, simplemente aparece sin problemas en el otro cliente y viceversa también, que está en el otro extremo, añadiendo Find Eucalyptus, que una vez que se hace clic en añadir, aparece muy fácilmente.

Esta mirada inicial te muestra la poderosa experiencia de usuario que podemos lograr. Ahora hablemos de la tecnología subyacente que hace que todo funcione. Bueno, esta aplicación local first y muchas otras como ella usan Yjs, una poderosa biblioteca para habilitar características colaborativas mientras se mantiene la funcionalidad offline. En el núcleo está el paquete Yjs. Esto proporciona el Y doc, que es esencialmente una estructura de datos compartida en tiempo real que vive en el dispositivo de cada cliente. La belleza de este tipo compartido, como Y map o Y array o Y text, es que son muy familiares a sus contrapartes de JavaScript en las APIs que exponen.

Lo que significa que aún puedes hacer push a un Y array. Puedes establecer un valor en un Y map e insertar texto. Para ilustrar la diferencia entre los dos, déjame mostrarte cómo se vería un componente estándar de React que tendría una lista de tareas. Es básicamente esto. Habría algún tipo de estado local. Habría un campo de entrada para poder aceptar ese valor, valor de entrada, y luego un montón de operaciones sobre ese valor. Así que añadir, editar, alternar y eliminar para mover cosas dentro y fuera del estado de la lista de tareas. Con Yjs, comenzaríamos un paso más arriba, que es instanciando un documento Y. Este documento es donde se almacenaría todo el material que deseas poner en el Y doc.

Con Yjs, comenzaríamos un paso más arriba, que es instanciando un documento Y. Este documento es donde todos los datos colaborativos viven localmente. Luego definimos nuestras estructuras compartidas dentro de él, como un Y array llamado Ytodo's para contener nuestra lista de objetos de tareas pendientes.

Ahora, tradicionalmente, cuando construimos características colaborativas, estás trabajando con una arquitectura donde una fuente central, tu servidor, y todos tus datos viven allí y los clientes los obtienen a intervalos. Bueno, Yjs invierte ese paradigma.

Cada cliente tiene su propia copia completa y autorizada del documento, guardada directamente dentro de estas estructuras de datos especiales de Yjs. Podrías notar que el servidor todavía está en la imagen.

El papel del servidor, sin embargo, se ha reducido fundamentalmente. Ahora actúa como un servidor de sincronización ligero, simplemente retransmitiendo actualizaciones entre clientes, en lugar de ser la autoridad central que mantiene la única versión verdadera de los datos. Este es un cambio poderoso. Aunque estoy usando un ejemplo simplificado, una extensión natural de este servidor podría ser uno que también mantenga su propia instantánea de los datos, tal vez para respaldo o algún procesamiento del servidor o experiencia del usuario y análisis. Pero, crucialmente, el usuario continúa poseyendo su copia local y directamente en su máquina, asegurando que poseen sus datos y su trabajo permanece instantáneamente accesible.

Volvamos al código. Así es como se ve el componente de lista de tareas local first, que aprovecha Ytodos. Observe el hook Y useEffect en el componente. Este hook es crucial para conectar el estado compartido de Yjs con el estado local de su componente React. Esta línea configura un observador o un listener de eventos en el array compartido Ytodos. Siempre que Ytodos cambie, ya sea debido a una edición local o una sincronización remota, se llama a la función updateTodos. Dentro de updateTodos, convertimos el array Y en un array estándar de JavaScript, que luego actualiza nuestro estado local de React usando setTodos.

updateTodos se llama una vez inicialmente para poblar el estado local con el contenido actual de Ytodos. Y finalmente, desobservamos el array Ytodos para asegurar que el observador se limpie cuando el componente se desmonte y prevenir fugas de memoria. Bueno, con esta configuración, cualquier operación CRUD, como agregar, editar, alternar y eliminar, modificaría directamente el tipo compartido Ytodos en lugar del estado local de tareas, lo que habría sido el caso si no estuviéramos usando un enfoque local first. Eso fue fácil, ¿verdad? Así que, hasta ahora, hemos creado un documento Y local y hemos cambiado el uso del estado local y en su lugar ahora estamos usando un array Y.

Básicamente, solo estamos guardando nuestra lista en un área diferente. Observe que no tuvimos que cambiar mucho de la lógica del componente en sí. El ajuste clave fue simplemente usar el tipo compartido de Yjs en lugar del estado local. Las operaciones como agregar o eliminar todavía se sienten muy familiares, pero ahora están respaldadas por el poder colaborativo de Yjs. Esto nos prepara para extender la capacidad de nuestra aplicación para aprovechar Yjs para la sincronización y el soporte offline.

Y para eso, introducimos los proveedores de Yjs. Estas son piezas modulares que conectan tu documento Y local a varios sistemas externos para persistencia o comunicación en tiempo real. El primero que vemos para la colaboración en tiempo real es Y WebSocket o WebSocket. Estos son independientes. Para hacer que estas copias independientes se comuniquen entre sí en tiempo real, especialmente cuando queremos colaborar en vivo a través de diferentes dispositivos, usamos Y WebSocket. Un proveedor de Yjs que maneja la sincronización de actualizaciones de documentos a través de una conexión WebSocket a un servidor ligero.

Así es como nuestro archivo DS del proveedor Y en el cliente se actualiza para incluir el paquete del proveedor WebSocket. Y así de simple, como puedes ver, todo lo que estamos haciendo es importar una nueva clase, instanciarla, y eso es todo. Lo que estamos haciendo aquí es dejar que Y WebSocket maneje todos los cambios entrantes y salientes por nosotros. Cuando ocurren cambios en el documento Y de un cliente, por ejemplo, en nuestro caso, el elemento de tareas, Y WebSocket envía esas pequeñas actualizaciones incrementales al servidor WebSocket configurado. Luego, el servidor actúa como un simple mensajero, transmitiendo esas actualizaciones a todos los clientes actualmente conectados al mismo nombre de sala.

Es crucial que el servidor sea un simple relé. No realiza una resolución de conflictos compleja ni almacena la verdad definitiva. Ese trabajo pesado, la fusión y asegurar la consistencia está dentro de cada documento Y en los propios clientes. Este diseño mantiene el servidor ligero, escalable y enfocado puramente en la transmisión de datos. Ahora, para prosperar verdaderamente offline, necesitamos una forma de procesar los datos directamente en el dispositivo del usuario para que incluso si cierran su navegador o pierden la conectividad a Internet, su trabajo esté seguro e inmediatamente disponible. Ahí es donde entra en juego IndexedDB.

Yjs aprovecha un paquete llamado y-index-db-provider para guardar automáticamente todo el documento Y en un IndexedDB local. Esto significa que incluso si el usuario cierra su navegador, pierde la conexión a Internet, o reinicia su computadora, su copia local de los datos está segura e inmediatamente disponible en el momento en que reabren la aplicación. Prácticamente lo que haría el almacenamiento local en este caso, ¿verdad? Solo que un poco más poderoso porque se gestiona en instantáneas incrementales. Este es el núcleo para habilitar la capacidad de respuesta instantánea y el trabajo offline sin problemas que discutimos anteriormente. Tu aplicación ahora siempre tiene acceso a los datos independientemente de las condiciones de la red. Este diagrama aquí ilustra el flujo simplificado. Cada cliente, como puedes ver, tiene su propia aplicación impulsada por un documento Yjs local. Este documento es donde viven todos los datos.

Para el soporte offline, el y-index-db-provider persiste automáticamente el documento en IndexedDB en el dispositivo del cliente. Cuando ocurren cambios, el y-web-socket-provider envía estas actualizaciones incrementales compactas a un servidor de sincronización ligero. Dado que esto no gestiona, estado, o resuelve conflictos en el servidor, simplemente actúa como un conducto, retransmitiendo actualizaciones a todos los demás clientes conectados si están conectados a la misma sala.

Cada cliente receptor luego aplica estas actualizaciones a su Y-doc local gestionado por CRGTs, y más sobre esto más adelante, para asegurar una fusión sin conflictos. Ahora que tenemos una aplicación que tiene todos los proveedores configurados y es perfectamente local first, veamos algunos de los escenarios colaborativos comunes, centrándonos en cómo Yjs maneja adiciones y eliminaciones dentro de una aplicación, especialmente cuando los usuarios están trabajando concurrentemente y offline. Esto mostrará cómo Yjs y su concepto subyacente de CRGTs, más sobre esto, aseguran que las listas permanezcan consistentes y ordenadas.

En este escenario, tenemos dos colaboradores, son los mismos Kuala y Panda, trabajando en la misma lista de tareas. Primero, establezcamos una línea base. Entonces, hagamos que Kuala elimine un elemento, y como puedes ver, con la misma facilidad, la lista de elementos de Panda también se actualiza, y Panda, al eliminar la lista de Kuala, también se actualiza. Hasta ahora, todo bien. Eliminaciones simples, sincronizadas al instante, la lista ahora es consistente. Ahora para la verdadera prueba. Tanto Kuala como Panda intencionalmente se desconectan.

Como puedes ver, los indicadores muestran en la parte superior que están efectivamente desconectados. Ahora, mientras están desconectados, Panda añade un nuevo elemento a la lista, y obviamente porque están desconectados, no se actualiza instantáneamente en la otra pantalla. Poco después, aún desconectado, Kuala también añade un nuevo elemento a la lista. En este punto, mientras ambos están desconectados, cada uno ve su propia lista. Mientras están desconectados, cada uno ve sus propios elementos recién añadidos apareciendo en la parte superior de sus respectivas listas. Sus copias locales del documento reflejan sus últimos cambios.

Ahora para el momento de la verdad. Se vuelve a encender el Wi-Fi, y sus clientes se reconectan al servidor. Como puedes ver, el elemento de Panda es el primero, y el de Kuala es el segundo. Esto no es aleatorio. Yjs, para su tipo compartido Y array, utiliza algoritmos de tipos de datos replicados sin conflictos para listas como arrays globales replicados o CRDTs simples que preservan el orden. Estos algoritmos tienen una forma determinista de resolver inserciones concurrentes y mantener un orden consistente en todas las réplicas, independientemente de la latencia de la red o del tiempo exacto de reloj de pared de una operación. Si ves, ambas listas se ven idénticas, incluso si comenzaron con ambos, Kuala y Panda viendo su elemento como el primero en la lista, y de eso estamos hablando.

Ahora, aunque el algoritmo exacto puede ser un poco complejo, el principio clave es que cada operación obtiene un identificador único que incluye su origen, que es el cliente, y una marca de tiempo lógica. Cuando dos adiciones concurrentes intentan ocupar la misma posición lógica en la lista, que es lo que estaba sucediendo justo entonces cuando tanto Kuala como Panda querían añadir un elemento a la posición superior, el algoritmo utiliza una regla de desempate, generalmente basada en sus identificadores únicos o propiedades específicas de las marcas de tiempo lógicas, para decidir consistentemente su orden relativo final para todos los clientes. En nuestra demo, el elemento de Panda simplemente tenía un identificador único que hizo que se ordenara antes que el de Kuala cuando las dos adiciones concurrentes offline se fusionaron. La conclusión importante es que el resultado está garantizado para ser el mismo en todos los clientes. No obtienes un estado de deriva donde Kuala ve su elemento primero y Panda ve el suyo. Yjs asegura que a pesar del trabajo offline independiente y concurrente, tus datos compartidos convergen a un estado único, consistente y lógicamente ordenado para todos.

Genial. Vamos a llevar esto un poco más allá. ¿Qué pasa si ambos clientes están editando el mismo elemento? Veamos eso en acción. Así que aquí ahora tenemos, de nuevo, el mismo estado de Panda y Kuala. Y en este caso, solo Kuala se desconecta. Y eso se puede ver por el indicador en la parte superior. Panda, mientras aún está en línea, ahora está editando el primer elemento en la lista de tareas. Y Kuala, a la izquierda, ahora edita su primer elemento en esa lista, en la misma lista también. Cuando Kuala vuelve a estar en línea, notamos que tanto Panda como Kuala ven las ediciones de Kuala mientras se hicieron offline.

En este caso específico, el cambio de Kuala ganó. Y esto sucede porque Yjs para actualizaciones de propiedades individuales típicamente utiliza un tipo de CRDT llamado last write wins register. Está diseñado para asegurar que la última operación registrada para un dato dado basada en su marca de tiempo única, que es manejada internamente por Yjs, es la que prevalece. Es una estrategia muy común e intuitiva para muchos tipos de conflictos.

Ahora para otro escenario, ¿qué pasaría si lo llevamos a otro nivel? Que es, Kuala se desconecta, y Panda, frustrado por el hecho de que perdió la última vez, ha eliminado ahora el primer elemento de la lista por completo. Kuala, porque está offline, no es consciente de eso y ahora sigue adelante y lo edita otra vez, probando su suerte. Como puedes ver en este caso, la eliminación de Panda ganó, y el elemento permanece eliminado. Incluso mientras la edición de Kuala fue posterior. Esto demuestra un aspecto sutil pero poderoso de los CRDTs.

Mientras que el last win register generalmente elige la última edición para operaciones que involucran adiciones y eliminaciones dentro de una sola línea, el last win register generalmente elige la última edición para operaciones que involucran adiciones y eliminaciones dentro de un conjunto o lista, Yjs a menudo implementa una estrategia que favorece las eliminaciones cuando un elemento puede ser editado y eliminado concurrentemente. En muchos contextos colaborativos, una operación de eliminación deliberada a menudo se considera definitiva. Incluso si una edición ocurrió concurrentemente como nosotros mismos. Este es el problema fundamental que Yjs resuelve. Con una solución increíblemente elegante y poderosa llamada conflict-free replicated data types, los CRDTs de conflicto son estructuras de datos especiales que están diseñadas para ser fusionadas automática y correctamente sin requerir una lógica de resolución de conflictos compleja, del tipo al que estamos acostumbrados con Git.