El movimiento local-first

Pregúntate dónde viven de verdad los datos de las aplicaciones que usas a diario. En casi todas, la respuesta es incómoda: viven en el servidor de una empresa, y tu dispositivo solo guarda una copia prestada que se evapora en cuanto se corta la red o la compañía cierra. Esa es la arquitectura de la nube, y durante quince años la tratamos como la única forma sensata de construir software. Local-first es la tesis contraria, y es más radical de lo que parece: los datos deben vivir primero en el dispositivo del usuario, bajo su control, y la red debe ser una optimización —un medio para sincronizar y colaborar— y no la condición sin la cual nada funciona. El giro no es de rendimiento sino de soberanía: quien tiene los bytes tiene el poder, y en la nube ese poder no es del usuario. El movimiento nació con nombre y fecha, en un ensayo de 2019 del laboratorio Ink and Switch que cristalizó una intuición dispersa en siete ideales concretos. Esta lección los desgrana, porque son la brújula de todo el nivel: cada técnica que veremos después —los CRDTs, Yjs, los motores de sincronización— existe para hacer alcanzables, a la vez, esos siete ideales que la nube solo cumple a medias.

Tres eras: local, nube y la síntesis

Para entender qué propone local-first hay que ver contra qué reacciona, y eso exige recordar dos eras previas del software de datos. La primera fue la app local clásica: procesadores de texto y hojas de cálculo de los años noventa cuyos datos vivían en un archivo de tu disco. Eran rápidas y soberanas —abrían al instante, funcionaban sin red y el documento era tuyo—, pero no sabían colaborar ni seguirte de un dispositivo a otro, y un disco perdido se llevaba tu trabajo sin remedio. La segunda era, la de la nube, resolvió justo esas carencias: Google Docs trajo colaboración en tiempo real y acceso desde cualquier pantalla, a cambio de un precio que tardamos en ver. Tus datos dejaron de ser tuyos para vivir en un servidor ajeno; sin red no hay documento, y el proveedor puede cambiar las reglas, subir el precio, cerrar el servicio o expulsarte, y tu trabajo se va con él.

Local-first se plantea explícitamente como una síntesis dialéctica: quiere la soberanía y la velocidad de la era local y la colaboración y ubicuidad de la era nube, sin renunciar a ninguna. La pregunta que se hace el manifiesto es si esa combinación es siquiera posible, y su respuesta —que sí, pero solo sobre una base técnica muy concreta— es lo que da sentido al resto del nivel. Porque unir ambas eras no es una cuestión de mejores servidores ni de más ancho de banda: exige una forma de datos que pueda vivir replicada en muchos dispositivos y fundir cambios concurrentes sin un árbitro central. Ese es el papel que jugarán los CRDTs, pero antes conviene fijar la vara de medir.

Conviene subrayar que la era de la nube no fue un error ni una conspiración, sino una respuesta racional a un problema real: sincronizar y colaborar es dificilísimo, y centralizar los datos en un servidor lo vuelve casi trivial, porque hay un único lugar donde reside la verdad y un único reloj que ordena los cambios. Local-first no niega esa dificultad; asume el reto de resolverla sin centralizar, y por eso es una empresa más ambiciosa técnicamente. Su apuesta es que ahora, por fin, tenemos las herramientas matemáticas para hacerlo.

Los siete ideales del manifiesto

En 2019, Martin Kleppmann y sus colegas del laboratorio Ink and Switch publicaron el ensayo que bautizó el movimiento y le dio su rúbrica. No propusieron una tecnología sino siete ideales —siete propiedades deseables— contra los que medir cualquier aplicación. Conviene leerlos como un espectro, no como una casilla de sí o no: la mayoría del software cumple algunos y traiciona otros.

1. Sin ruletas de carga: tu trabajo al instante. La interfaz responde a la velocidad del dispositivo, no de la red. No esperas a un servidor para ver el efecto de tus actos.
2. Tu trabajo no está atrapado en un solo dispositivo. Los datos te siguen del portátil al móvil a la tableta, sincronizados, sin ser rehenes de una máquina concreta.
3. La red es opcional. La aplicación funciona entera sin conexión; la red sirve para sincronizar y colaborar, no para arrancar.
4. Colaboración fluida con tus colegas. Varias personas editan a la vez sin pisarse, como en la nube, pero sin depender de que un servidor esté vivo para lograrlo.
5. El Largo Ahora. Tus datos deben durar décadas y sobrevivir al formato, a la empresa y al servicio que los creó. Longevidad frente a obsolescencia.
6. Seguridad y privacidad por defecto. El cifrado de extremo a extremo es el punto de partida: ni el proveedor lee tus datos. La privacidad no es un ajuste, es el diseño.
7. Conservas la propiedad y el control últimos. Tú decides sobre tus datos sin pedir permiso a un intermediario. La soberanía es del usuario, no del servidor.

Fíjate en que los siete ideales no son independientes: forman dos racimos que se tensan entre sí. Los cuatro primeros —velocidad, multidispositivo, red opcional, colaboración— son promesas de experiencia, y la nube cumple tres de ellas con soltura, fallando solo en la red opcional. Los tres últimos —longevidad, privacidad, propiedad— son promesas de soberanía, y ahí la nube fracasa de raíz, porque su modelo de negocio a menudo depende justo de custodiar y explotar tus datos. La genialidad del manifiesto fue mostrar que ambos racimos son alcanzables por la misma vía técnica, y que renunciar a la soberanía nunca fue el precio inevitable de la colaboración, sino un peaje que cobramos por no saber construirla de otro modo.

La red como optimización, no como requisito

El giro que unifica los siete ideales es una sola inversión arquitectónica, y merece formularse con precisión porque es la idea que arrastrarás por todo el nivel. En la arquitectura de la nube el servidor es la fuente de verdad y el cliente es un terminal delgado: cada acción del usuario viaja por la red, el servidor decide, y solo entonces la interfaz refleja el resultado. La red está en el camino crítico de todo, y por eso sin red no hay app. Local-first mueve la fuente de verdad al dispositivo: el cliente lee y escribe sobre una réplica local que es autoritativa para lo que el usuario ve, y la sincronización con el servidor se degrada a un proceso de fondo que pone al día esa réplica cuando hay señal.

// Nube: cada lectura es una peticion a la red, con su espera y su posible fallo
const tareas = await fetch('/api/tareas').then((r) => r.json())

// Local-first: la lectura es local e instantanea; el motor ya la mantiene fresca
const tareas = db.query('SELECT * FROM tareas')  // sin red, sin espera, sin spinner

La diferencia entre esas dos líneas parece cosmética y es abismal. La primera introduce latencia, un estado de carga, un estado de error y una dependencia dura de la conectividad; la segunda es una lectura de memoria local que nunca falla por culpa de la red. Todo lo que el frontend construyó durante una década para paliar la primera línea —cachés, invalidación, reintentos, indicadores de carga— existe únicamente porque los datos estaban lejos. Cuando los acercas, ese andamiaje entero deja de ser necesario.

flowchart LR
subgraph Nube
  C1[cliente delgado] -->|cada accion viaja a la red| S1[servidor autoritativo]
  S1 --> DB1[base de datos remota unica]
end
subgraph LocalFirst
  C2[cliente] <--> L2[replica local fuente de verdad]
  L2 -.sync en segundo plano.-> S2[servidor opcional]
end
style L2 fill:#a6e3a1,color:#11111b
style DB1 fill:#f38ba8,color:#11111b

Colocada la fuente de verdad en el dispositivo, los siete ideales dejan de ser deseos sueltos y se vuelven consecuencias. Si la réplica es local, no hay ruletas de carga —el ideal uno— y la red es opcional —el ideal tres—, porque la interfaz nunca espera al servidor. Si esa réplica puede fundir sus cambios con las de otras réplicas sin un árbitro, entonces el trabajo te sigue entre dispositivos —ideal dos— y la colaboración fluye sin depender de que un servidor esté vivo —ideal cuatro—. Y si los datos son tuyos y viven cifrados en tu máquina, la propiedad, la privacidad y la longevidad —ideales cinco a siete— dejan de estar a merced de un proveedor.

La base técnica que aún faltaba

Si la idea de local-first es tan clara y tan deseable, cabe preguntarse por qué no la construimos siempre así. La respuesta es que faltaba la pieza central: una forma de fundir sin árbitro. Durante décadas supimos replicar datos, pero no reconciliar dos réplicas editadas a la vez sin un servidor que decidiera quién gana o sin obligar a los usuarios a resolver conflictos a mano. La palabra clave, que abrirá la lección siguiente, es precisamente esa: fundir sin árbitro. Dos copias del mismo dato, modificadas simultáneamente en dos sitios desconectados, deben poder reconciliarse en un resultado único, idéntico en ambas, sin coordinación previa.

Ese problema tuvo históricamente dos respuestas parciales. La transformación operacional —la técnica detrás de los primeros editores colaborativos— funcionaba, pero exigía un servidor central que transformara cada operación contra las demás, lo que la ataba al modelo de la nube. La otra respuesta, más reciente y más radical, son los tipos de datos replicados sin conflictos, los CRDTs, que eliminan la necesidad de ese árbitro central por diseño matemático. Su madurez, hacia finales de la década de 2010, es exactamente lo que hizo posible que el manifiesto se escribiera cuando se escribió y no antes.