¿Qué es la arquitectura offline-first y por qué tu app la necesita?
Tu app no debería dejar de funcionar porque el usuario entró al subte. Te explico cómo implementar offline-first con event sourcing — la arquitectura que uso en mis 6 apps.
El 30% del tiempo que un usuario usa una app móvil, la conexión a internet es mala o inexistente. En el subte, en un avión, en zonas rurales, o simplemente con señal débil. Si tu app depende de internet para funcionar, estás perdiendo el 30% de tu engagement. Offline-first significa que la app funciona completamente sin internet y sincroniza cuando la conexión vuelve. Es la diferencia entre una app profesional y una app amateur.
Cómo funciona: Event Sourcing
En vez de enviar cada acción al servidor en tiempo real, la app registra cada acción como un "evento" inmutable con un UUID único. Estos eventos se guardan localmente en una cola (AsyncStorage). 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 UUID), el servidor lo ignora. Esto garantiza idempotencia: no importa cuántas veces envíes el mismo evento, el resultado es el mismo.
El estado vive en memoria
Durante gameplay activo, el estado completo vive en RAM (Zustand store). Cero operaciones de disco o red. Esto garantiza 60 FPS constantes. El autoguardado se hace con debounce cada 10 segundos usando InteractionManager.runAfterInteractions() para no bloquear la UI. Cuando el usuario cierra la app, el estado se persiste en AsyncStorage. Cuando la abre de nuevo, se rehidrata desde ahí.
Sync inteligente
No siempre conviene sincronizar. Mi implementación evalúa: si hay WiFi o datos móviles, el nivel de batería (no sync si está en modo ahorro), la cantidad de eventos pendientes, y el tiempo desde la última sincronización (mínimo 30 segundos entre syncs). Si la sync falla, se reintenta con backoff exponencial: 5 segundos, 15 segundos, 60 segundos. Después de 3 intentos fallidos, espera a que el usuario vuelva a abrir la app.
Resolución de conflictos
El servidor siempre gana. Cuando el servidor recibe eventos, los procesa en orden cronológico y calcula el estado final. Ese estado se envía de vuelta al cliente, que reemplaza su estado local. Esto funciona porque los eventos son inmutables y tienen timestamp + UUID. 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.
Anti-cheat con Event Sourcing
Un beneficio inesperado: como cada acción es un evento registrado, el servidor puede analizar patrones. Si un usuario completa un Sudoku difícil en 5 segundos, los eventos muestran que solo hizo 3 movimientos — claramente imposible. El servidor calcula un "suspicion score" y puede aplicar shadow bans sin que el tramposo se entere. Toda esta lógica es server-side y no se puede bypassear manipulando el cliente.
Si querés una app que funcione perfectamente sin internet, puedo desarrollarla con esta arquitectura. Mirá mis apps publicadas y contactame para tu proyecto.