En octubre pasado, me encontraba en una habitación de hotel en Lisboa, justo la noche anterior a la presentación de una herramienta de gestión de proyectos que mi equipo había desarrollado durante cuatro meses. La conexión Wi-Fi del hotel se conectaba pero no cargaba nada. La aplicación que tanto habíamos trabajado mostraba una pantalla en blanco con un icono de carga, luego un error de tiempo de espera y finalmente nada.
Ante esta situación, recurrí a la conexión móvil de mi teléfono, logrando una conexión inestable pero suficiente para cargar la app. Sin embargo, cada acción demoraba al menos dos segundos: crear una tarea, moverla de columna, todo era un proceso lento y frustrante. Pensé entonces en toda la infraestructura detrás de esa experiencia: una interfaz en React, backend en Node.js, base de datos Postgres, caché en Redis y una API GraphQL con múltiples resolutores para el tablero de tareas. Todo ese despliegue para que, sin una conexión rápida, la app no pudiera mostrar siquiera mis propios datos sin comunicarse con un servidor que estaba a miles de kilómetros.
Aquella noche fue el punto de inflexión que me llevó a investigar en profundidad la arquitectura local-first. No fue por una lectura casual ni un tuit; fue pura incomodidad profesional.
Al principio, admito que desprecié el concepto como algo académico e impráctico para aplicaciones reales. En 2019, cuando leí el documento «Local-First Software» de Ink & Switch, pensé que era una lista de deseos más que una guía de ingeniería.
Siete años después, he publicado tres aplicaciones reales que implementan patrones local-first y he retirado esa arquitectura de otros dos proyectos donde no encajaba. De todo ello, he aprendido lecciones valiosas y quiero compartir cómo construir apps web locales desde 2026, para desarrolladores que buscan soluciones pragmáticas y no disparates tecnológicos.
More Read
Qué significa realmente “Local-First” y por qué no es offline-first
Una confusión común que sigo encontrando en conferencias y meetups es equiparar local-first con offline-first o con las Progressive Web Apps (PWA). Nada más alejado de la realidad.
Offline-first significa que la aplicación maneja adecuadamente pérdidas temporales de conexión, pero el servidor sigue siendo la fuente única y oficial de la verdad. Cuando la conexión se restablece, los datos del servidor prevalecen. La estrategia cache-first (como los service workers) solo mejora la velocidad al servir datos en caché, pero no altera la propiedad o el almacenamiento principal de los datos.
Las PWAs, por su parte, son solo una tecnología de entrega: aplicaciones capaces de instalarse, con notificaciones push y caché. Pero no definen cómo se estructura ni se gestiona la información.
More Read
En cambio, local-first es un modelo de arquitectura de datos. La copia principal reside en el dispositivo del usuario. La app lee y escribe directamente en una base de datos local para ofrecer respuestas instantáneas e interacciones inmediatas. La sincronización con servidores u otros dispositivos ocurre en segundo plano. El servidor, si existe, actúa como un nodo más en este sistema distribuido, responsable de autenticación, respaldo y control de acceso, pero sin ser el controlador absoluto.
Como dice el documento original: «El cliente no es una simple vista que pide permiso para mostrar datos, sino un nodo en un sistema distribuido con su propia base de datos.» Esta humilde frase cambia todo el paradigma del desarrollo web.
Cuándo no aplicar local-first
No todo proyecto se beneficia de esta arquitectura. Por ejemplo, si el flujo de datos viene generado principalmente desde el servidor, como en dashboards analíticos, feeds sociales o resultados de búsqueda, un modelo cliente-servidor tradicional basado en APIs es suficiente y más eficiente.
Tampoco encaja donde se requiere alta consistencia transaccional estricta, como en banca, pagos o gestión de inventarios. Allí, una base de datos autoritativa única con garantías ACID evita pérdidas o inconsistencias críticas.
Para aplicaciones CRUD simples con buena conexión y pocos usuarios, añadir un motor de sincronización local es un exceso técnico.
En cambio, brilla en apps para toma de notas, edición de documentos, diseño colaborativo, gestión de proyectos y especialmente en entornos desconectados o con conectividad intermitente donde la privacidad y el control del usuario son claves.
More Read
Consejo práctico: no necesitas pasarte por completo. Integrar local-first en funcionalidades concretas, como borradores offline o notas colaborativas en una herramienta tradicional, puede ser una entrada más sencilla y rentable.
La analogía con Git: replicación en lugar de peticiones
El modelo mental de local-first se parece mucho al funcionamiento de Git sobre SVN. Antes, con SVN, dependías de un servidor central para cada cambio, sin posibilidad de trabajar offline. Git entrega a cada desarrollador una copia completa del repositorio local, donde puede hacer commits, ramas y fusiones independientes, sincronizando los cambios cuando quiera.
De forma similar, cada dispositivo mantiene una réplica (total o parcial) de los datos relevantes en una base local. Las escrituras se realizan ahí, y la sincronización con otros nodos o el servidor ocurre en segundo plano. Los conflictos se resuelven mediante estrategias formales de fusión.
En términos prácticos, esto elimina la necesidad de combates con estados de carga, errores al escribir o complejas actualizaciones optimistas en la interfaz. La base de datos local es la realidad inmediata que la app muestra.
Dónde alojar los datos localmente
A día de hoy, olvidar localStorage es imprescindible: es síncrono, limitado en tamaño y solo almacena cadenas. IndexedDB es ampliamente compatible y asincrónico, pero su API es compleja y tediosa.
La verdadera revolución actual es SQLite corriendo en el navegador a través de WebAssembly (WASM), persistiendo datos mediante el sistema Origin Private File System (OPFS). Esta combinación ofrece una base de datos relacional completa con soporte para consultas SQL, transacciones e índices, con un rendimiento adecuado.
Una implementación práctica usa la librería wa-sqlite, que inicializa el entorno WASM, monta el VFS sincronizado sobre OPFS y abre la base SQLite local. En producción es útil serializar accesos para evitar problemas de concurrencia, especialmente en navegadores como Safari donde algunas APIs tienen limitaciones o bugs.
Sincronización y resolución de conflictos: el verdadero desafío
Gestionar la sincronización eficiente entre múltiples réplicas es donde reside la dificultad. Existen varias tecnologías y enfoques:
- CRDTs (Tipos de Datos Replicados sin Conflictos): estructuras matemáticamente diseñadas para fusionar cambios concurrentes sin pérdida. Yjs es la implementación JavaScript más consolidada, ideal para edición colaborativa de texto.
- Replicación basada en base de datos: por ejemplo, replicar filas entre Postgres y SQLite mediante motores de sincronización dedicados como PowerSync o ElectricSQL, que permiten sincronización activa bidireccional.
- Event sourcing: sincronizar eventos de cambios más que estados concretos, útil en dominios específicos pero a menudo más complejo de gestionar en tareas comunes.
La resolución de conflictos suele abordarse con la técnica «last-write-wins» aplicada a nivel de campo. Esto permite conservar simultáneamente cambios independientes en diferentes atributos y resolver conflictos cuando se modifican los mismos campos, eligiendo generalmente el dato más reciente.
Sin embargo, existen problemas más complejos: los conflictos semánticos, donde la combinación correcta de datos requiere validación empresarial, como evitar que dos reuniones se solapen en el mismo horario. Aquí, el servidor debe validar las reglas de negocio durante la sincronización y notificar al usuario para que resuelva manualmente estas situaciones.
Herramientas recomendadas en 2026
– Yjs: para colaboración en tiempo real y CRDTs maduros.
– PowerSync: para sincronización Postgres-SQLite estable y práctica.
– ElectricSQL: prometedora para replicación activa, pero aún experimental.
– Triplit: base de datos full-stack con sincronización integrada.
– PGlite: Postgres compilado a WASM para SQL homogéneo en cliente y servidor.
– TinyBase: almacén reactivo ligero para prototipos o apps pequeñas.
Arquitectura práctica de una app local-first
La pila típica de un proyecto actual incluiría React para interfaz, SQLite vía wa-sqlite junto a OPFS para almacenamiento local, queries reactivos que consultan directamente la base local y un motor de sincronización como PowerSync que replica datos con un backend en Postgres; con capas de autenticación y validación de permisos centralizadas en servidor.
Un fragmento de código simple basta para mostrar el modelo: se insertan datos directo en SQLite y la interfaz se actualiza automáticamente sin llamadas a fetch ni estados de carga.
Autenticación, autorización y migraciones en local-first
La autenticación sigue fluyendo mediante tokens JWT en la conexión de sincronización. La autorización se aplica en el servidor durante la sincronización, limitando qué datos recibe cada cliente y rechazando escrituras no autorizadas. La seguridad del cliente no es un límite confiable.
Las migraciones a nivel de esquema son un reto, pues cada usuario tiene una versión distinta. La recomendación es diseñar migraciones aditivas, sin eliminar o renombrar columnas, asegurando la compatibilidad progresiva entre aplicaciones de diferentes versiones.
Rendimiento y experiencia de usuario
La lectura y escritura local son instantáneas, lo que mejora radicalmente la experiencia frente a la necesidad de esperar respuestas del servidor. La sincronización inicial consume tiempo y datos, pero suele ser un proceso único que se optimiza con sincronización parcial.
Hay que cuidar el tamaño del paquete JavaScript, pues SQLite + WASM añade unos 400KB. La memoria también es un factor, especialmente en dispositivos móviles con limitaciones estrictas.
Reflexiones finales y recomendaciones
Local-first aporta una complejidad arquitectónica considerable: sincronización, conflictos, migraciones y seguridad. Por ello, debe usarse cuando sus ventajas compensan esos costes, en aplicaciones colaborativas, offline y privadas.
Si estás empezando, lo mejor es probar con una funcionalidad específica para experimentar las mejoras sin riesgos y evolucionar a partir de ahí.
En resumen, local-first ya es una realidad con herramientas maduras y resultados palpables, y está llamado a ser un pilar fundamental en el desarrollo web de futuro.
