Local-First development
Nuestros Hunters, cazadores de tendencias tecnológicas, nunca paran. En esta nueva edición de Inspiring Technology nos hablan de local-first devolpment, un conjunto de principios a la hora de crear productos de softwate. ¡Sigue leyendo!
El local-first development estipula que utilizando recursos locales (almacenamiento y red), y sin hacer uso de servidores centrales, es posible que un usuario mantenga la propiedad y control de los datos que introduce en el software, sea capaz de actuar sobre ellos en cualquier momento, de sincronizarlos entre varios dispositivos y de trabajar sobre los datos de forma colaborativa con otros usuarios.
Motivación
Utilizando servidores centrales, especialmente servidores cloud de otras compañías como los que se utilizan en herramientas colaborativas (Google Docs, Trello…), se cede control sobre los datos que se depositan en dichos servidores, puesto que se depende del estado de ellos y de la capacidad de alcanzarlos.
En el caso de la Ilustración, los datos del usuario dejan de ser accesibles si se pierde acceso a los servidores backend o a la base de datos.
Por otra parte, si el usuario trabaja de forma aislada en su dispositivo, sin utilizar servidores centrales, se reduce la facilidad para sincronizar los datos entre múltiples dispositivos y para colaborar con otros usuarios sobre los mismos datos.
Con local-first developoment se pretende que un usuario pueda mantener el control y propiedad de los datos introducidos en una aplicación sin renunciar a las capacidades colaborativas y de sincronización que estos proporcionan.
Ilustración 1: Diagrama de arquitectura convencional
Arquitectura y características del software resultante
En la imagen podemos ver un ejemplo de una posible arquitectura local-first. Como se puede ver, es posible utilizar servidores de sincronización y almacenamiento de copias de seguridad. Sin embargo, a diferencia de las bases de datos y los servidores backend comunes, estas contrapartes local-first tienen funciones menos importantes, pasando de ser centrales a ser prescindibles. Prescindir de ellos resultaría en una arquitectura formada solo por los clientes.
Por otra parte, local-first pretende que los productos software sean utilizables incluso sin conexión o con conexión limitada. Sin embargo, en este escenario existe la posibilidad de que, mientras se producen cambios sin estar conectados a la red, dos usuarios actúen sobre la misma porción de datos (por ejemplo, un mismo párrafo) y al intentar sincronizar los datos se produzca un conflicto, imposibilitando o dificultando la sincronización. Como respuesta, la solución más extendida es la implementación de Conflict-free replicated data types.
Ilustración 2: Diagrama de una posible arquitectura local-first
Conflict-free replicated data types (CRDTs)
Conflict-free replicated data types, conocidos también como CRDTs, son estructuras de datos que son replicadas en múltiples dispositivos en una red. Estas réplicas pueden ser actualizadas independientemente, concurrentemente y sin coordinarse con otras réplicas. Tras ello, cuando se intenta sincronizar, un algoritmo automáticamente resuelve cualquier inconsistencia que puede ocurrir, por lo que finalmente convergerán en un estado común.
Todas las réplicas divergentes pueden ser sincronizadas en cualquier orden por cualquier máquina que contenga una réplica y, una vez que todas las máquinas hayan visto todas las copias, se garantiza que todas converjan y alcancen el mismo estado. Esto es importante para eliminar la necesidad de un servidor central que coordine la convergencia.
Los CRDTs se pueden clasificar en dos estrategias diferentes en función del método que se siga para obtener la consistencia: CRDTs basados en estado y CRDTs basados en operación.
Los CRDTs basados en estado consisten en enviar el estado de las réplicas de datos entre distintos dispositivos y combinar sus estados hasta alcanzar el estado final.
Ilustración 3: Diagrama de CRDT basado en estado
Por otra parte, los CRDTs basados en operación, en lugar de enviar el estado general de la réplica, envían las operaciones realizadas sobre estas, actualizando a las demás réplicas.
Ilustración 4: Diagrama de CRDT basado en operación
Puede no ser necesario implementar los CRDTs, puesto que hay herramientas como librerías o frameworks que ya los implementan. Algunos ejemplos de estas herramientas son Yjs, Automerge o Replicache.
Estado de la tecnología
Aunque local first development es un concepto que lleva varios años en circulación, ha sido recientemente cuando ha empezado a aumentar su popularidad debido, principalmente, al auge de herramientas cloud y a sus posibles inconvenientes, comentados anteriormente.
Sin embargo, a pesar de este aumento en popularidad sigue habiendo poca documentación sobre proyectos creados basándose en los principios local-first.
Conclusiones
Las herramientas basadas en servidores son muy utilizadas en la actualidad en muchos contextos diferentes. Son herramientas muy útiles y potentes pero, como se ha mencionado anteriormente, tienen también sus inconvenientes. Por este motivo, es importante analizar estos inconvenientes y tenerlos en cuenta a la hora de depositar datos en ellas.
El software local-first puede ser una alternativa a las herramientas colaborativas basadas en servidores para intentar obtener algunos de sus beneficios sin ceder control sobre los datos que se crean en los productos software. Sin embargo, el desarrollo de software local-first puede ser complejo, con posibles dificultades como el uso de una arquitectura diferente y la adición de CRDTs.
¿Quieres saber más sobre Hunters?
Ser un hunter es aceptar el reto de probar nuevas soluciones que aporten resultados diferenciales. Únete al programa Hunters y forma parte de un grupo transversal con capacidad de generar y transferir conocimiento.
Anticípate a las soluciones digitales que nos harán crecer. Consulta más información sobre Hunters.