¿Qué es la arquitectura offline-first y por qué tu app la necesita?

La arquitectura offline-first es una forma de diseñar apps en la que todo funciona primero en el dispositivo: los datos se guardan en el teléfono y se sincronizan con el servidor cuando hay conexión. Para el usuario, la app nunca se queda "cargando": abre, responde y guarda aunque esté en el subte, en un avión o en el campo.

Es lo contrario al enfoque tradicional, en el que cada acción viaja al servidor y, si no hay señal, la app se traba o pierde lo que cargaste. La uso en mis apps, como Sudoku Play, y en el cotizador de EQUIBOX. Te explico cómo funciona, cuándo conviene y qué aprendí implementándola.

¿Qué es la arquitectura offline-first?

"Offline-first" significa "primero sin conexión". En una app así, la fuente de datos inmediata es el dispositivo: lo que el usuario ve y lo que carga se lee y se escribe ahí, al instante. El servidor sigue existiendo, pero cumple otro rol: es donde todo termina consolidado, respaldado y compartido con otros dispositivos.

La clave es que la sincronización pasa a ser un proceso de fondo. El usuario no espera al servidor para seguir usando la app: sigue, y la app se pone al día sola cuando puede.

Online-first vs offline-first: la diferencia en la práctica

¿Cómo funciona la sincronización?

En vez de enviar cada acción al servidor en tiempo real, la app registra cada acción como un "evento" inmutable con un identificador único (UUID). Estos eventos se guardan localmente en una cola. Cuando hay internet, la cola se envía al servidor en lotes. El servidor procesa los eventos en orden y devuelve el estado actualizado.

Si un evento ya fue procesado (mismo identificador), el servidor lo ignora. Esto garantiza lo que se llama idempotencia: no importa cuántas veces se reintente el envío del mismo evento, el resultado es el mismo. Este patrón se conoce como event sourcing.

¿Dónde vive el estado mientras usás la app?

En Sudoku Play, durante una partida el estado completo vive en memoria (en un store de Zustand): cero operaciones de disco o de red mientras jugás, lo que mantiene la app fluida. El autoguardado se hace cada pocos segundos, en momentos en que no bloquea la pantalla. Cuando cerrás la app, el estado se guarda en el almacenamiento del teléfono (AsyncStorage) y, cuando la abrís de nuevo, se recupera desde ahí.

¿Cuándo conviene sincronizar?

No siempre conviene sincronizar en el momento. Mi implementación evalúa si hay WiFi o datos móviles, el nivel de batería (no sincroniza en modo ahorro), la cantidad de eventos pendientes y el tiempo desde la última sincronización (para no sincronizar a cada rato).

Si la sincronización falla, se reintenta con esperas cada vez más largas. Después de unos pocos intentos fallidos, espera a que el usuario vuelva a abrir la app.

¿Cómo se resuelven los conflictos?

En mi caso, el servidor siempre gana. Cuando recibe eventos, los procesa en orden cronológico y calcula el estado final. Ese estado se envía de vuelta al dispositivo, que reemplaza su estado local. Funciona porque los eventos son inmutables y tienen fecha y hora más un identificador único: incluso si el usuario jugó en dos dispositivos sin conexión, al sincronizar ambos el servidor reconcilia los eventos cronológicamente y el resultado es consistente.

¿Cuándo conviene una app offline-first?

No todas las apps la necesitan. Conviene cuando se da alguno de estos casos:

• La usan en lugares con mala señal: el campo, exposiciones, depósitos, el subte o viajes.
• Se trabaja en la calle o en el lugar del cliente, cargando pedidos, formularios o cotizaciones.
• Los datos que se cargan no se pueden perder (un pedido, una venta, un presupuesto).
• Es una app de uso diario en la que la velocidad se nota, como un juego o una herramienta de trabajo.

¿Y cuándo no hace falta?

Si la información tiene que estar siempre en vivo (por ejemplo, la disponibilidad de un turno que se puede reservar desde muchos lugares a la vez) o la app solo muestra contenido que cambia todo el tiempo, el enfoque tradicional suele alcanzar, y es más simple y más barato. Lo importante es decidirlo al diseñar la app: si estás pensando en una, contame cómo la van a usar y te digo qué enfoque le conviene. Acá podés ver cómo trabajo y qué tipo de proyectos hago.

Ejemplo real 1: ¿cómo funciona Sudoku Play sin internet?

Sudoku Play es una app de Sudoku que publiqué en las tiendas, con modo aventura y duelos 1 contra 1. Funciona completamente sin internet: todos los puzzles vienen guardados en el teléfono (en una base de datos local), el estado de la partida vive en memoria y todo lo que hacés se anota en una cola de eventos. Cuando hay conexión, esa cola se sincroniza con el servidor con el mecanismo que te conté arriba.

Ejemplo real 2: ¿cómo cotiza EQUIBOX en una exposición rural sin señal?

EQUIBOX es una fábrica de boxes para caballos. Le armé un cotizador web con render 3D que se instala como una app y funciona sin conexión, porque se usa en exposiciones rurales donde la señal es mala.

Las cotizaciones se guardan primero en el dispositivo y se sincronizan cuando vuelve la conexión. Cada una lleva un identificador generado en el propio dispositivo, y la base de datos no acepta dos con el mismo, así que aunque el envío se reintente varias veces, nunca se duplica un contacto. Es el mismo principio de idempotencia de Sudoku Play, aplicado a una web.

¿Qué más se gana registrando cada acción como evento?

Un beneficio que no esperaba: como cada acción queda registrada, el servidor puede analizar patrones. Si alguien completa un Sudoku difícil en 5 segundos, los eventos muestran que solo hizo 3 movimientos, algo claramente imposible. El servidor calcula un puntaje de sospecha y puede aplicar medidas sin que el tramposo se entere. Toda esa lógica vive en el servidor, así que no se puede saltear modificando la app.

Preguntas frecuentes