Qué significa local-first en Prior
Prior guarda tu trabajo primero en tu dispositivo y lo sincroniza después. Cómo funciona, cómo se fusionan los cambios según el dato y dónde deja de aplicarse.
Local-first significa que la copia de tu trabajo que de verdad cuenta es la de tu dispositivo. El servidor es el medio por el que tus dispositivos se encuentran, no el lugar donde una acción tiene que aprobarse para contar. La idea la expusieron en 2019 Martin Kleppmann, Adam Wiggins, Peter van Hardenberg y Mark McGranaghan, en Ink & Switch, en un ensayo que enumera siete ideales: rapidez, varios dispositivos, uso sin conexión, colaboración, longevidad, privacidad y control por parte del usuario.
La arquitectura de Prior sigue esta idea. Aquí va lo que significa en la práctica, y dónde se detiene.
Qué pasa cuando añades una tarea
Escribes una tarea. Prior la guarda en una base de datos de tu dispositivo: SQLite en las aplicaciones de escritorio y Android, y el almacenamiento propio del navegador en la web. Junto a ella, escribe una entrada en una bandeja de salida con un identificador de mutación único. La tarea aparece en pantalla en ese momento. Nada ha esperado a la red, por eso crear una tarea es instantáneo.
Cuando el dispositivo tiene conexión, envía la bandeja de salida al servidor. El servidor guarda un registro de cambios que solo crece, con un número de revisión que sube, y aplica cada cambio una sola vez por identificador de mutación, así que un reintento tras una conexión caída no puede crear una tarea dos veces. Tus otros dispositivos piden lo que ha cambiado desde la última revisión que vieron. Un pequeño mensaje WebSocket les dice que pidan ya, en lugar de esperar a la siguiente sincronización periódica. No lleva datos, solo la noticia de que algo ha cambiado.
Sin conexión, la aplicación lo dice: “Todo está guardado en este dispositivo. Se sincronizará cuando vuelvas a estar en línea.” Si hay cambios en espera, los cuenta. Los datos creados antes de iniciar sesión se quedan en el dispositivo hasta que se vinculan a tu cuenta.
Fusionar es una elección por tipo de dato
Dos dispositivos que cambian lo mismo sin conexión no coincidirán cuando se encuentren. No hay una única solución para todos los tipos de datos, así que Prior usa la que encaja con cada uno.
- Tareas y hábitos. El servidor aplica el último cambio aceptado, en orden de revisión. Una tarea con un cambio que todavía espera en tu dispositivo no se sobrescribe con lo que llega de otro lugar.
- Calendarios y eventos. Los cambios son parches por campo. Las ediciones de campos distintos del mismo evento se combinan; para el mismo campo, gana la última recibida. Los borrados dejan una marca, así que una copia antigua sin conexión no puede devolver un evento.
- Flashcards. Los repasos son un registro que solo crece, y el calendario de una tarjeta no se guarda: se calcula repitiendo sus repasos. Dos dispositivos que repasaron sin conexión acaban con el mismo calendario cuando sus registros se encuentran, sin nada que resolver.
- Presupuestos. Se fusionan línea a línea. Gana la versión más reciente de cada línea, y las líneas borradas dejan una marca.
- Notas compartidas. Son documentos de Yjs, pensados para que varias personas escriban a la vez. Si la conexión se corta, la nota muestra que está sin conexión, y los cambios de los editores se fusionan cuando vuelven a conectarse.
Lo que comparten los cinco es una fusión elegida según cómo se usan los datos, y una marca para cada borrado, de modo que una copia antigua nunca pueda deshacer una decisión más reciente.
Dónde se detiene
Local-first es una promesa sobre dónde vive tu trabajo y qué sigue funcionando, no una promesa sobre todo.
- Los proyectos compartidos necesitan conexión. Prior lo dice y mantiene un proyecto compartido en solo lectura hasta que vuelves a conectarte.
- Algunas cosas van por internet por naturaleza. Iniciar sesión, Prior AI, el correo y las ligas necesitan la red.
- No es cifrado de extremo a extremo. Tus datos se guardan en nuestro servidor para poder sincronizarse. Local-first no cambia eso.
- Un navegador es un lugar frágil. En la web, tus datos viven en el almacenamiento de ese navegador. Si lo borras antes de que los datos se sincronicen, los cambios no sincronizados se van con él. Las aplicaciones nativas guardan un archivo de base de datos.
Un fallo que nos enseñó algo
Una versión temprana de la sincronización funcionaba en un orden fijo. Una columna de fecha se leía mal en las tareas programadas y hacía fallar toda la descarga de tareas, lo que también impedía sincronizar los calendarios y el espacio de trabajo. Corregimos la lectura y cambiamos el diseño: ahora cada parte de la sincronización funciona por separado, y un fallo en una ya no bloquea a las demás. La interfaz indica qué parte sigue esperando, y no muestra un éxito completo cuando una parte ha fallado.
Eso también es local-first en acción. Tus datos nunca se perdieron, porque estaban a salvo en el dispositivo. La sincronización llegó tarde.
Más sobre cómo usarlo está en Uso sin conexión y sincronización, y Solucionar problemas de sincronización explica qué hacer cuando algo no llega.