Primero sin conexión: diseñar para cuando Internet no esté disponible

La mayoría de las aplicaciones tratan la falta de conexión como un accidente. Abres una pantalla, la red desaparece y aparece ese aviso desalentador: no hay internet, inténtalo de nuevo. La aplicación se rinde y el usuario también.

Offline-first invierte esta lógica desde cero. La premisa es que la ausencia de conexión es el estado normal y su presencia es la ventaja. No es pesimismo, es realismo. Cualquiera que cree aplicaciones híbridas de campo, móviles o web sabe que la red falla más de lo que nos gustaría admitir.

Trate la conexión fuera de línea como una regla, no como un error

La diferencia comienza en la mente del diseñador. En el modelo común, el camino feliz es estar en línea, y fuera de línea es una mala desviación que se debe abordar más adelante, generalmente mal. Primero fuera de línea, el camino feliz ya supone que puede que no haya red.

Este cambio de premisa modifica las decisiones a todos los niveles. La pantalla no puede depender de una llamada remota para mostrar contenidos. La acción del usuario no puede bloquearse esperando la confirmación del servidor. El flujo debe diseñarse para completarse localmente y conciliarse más tarde.

Cuando diseñas así, también le sucede algo interesante al usuario en línea. Dado que todo responde primero localmente, la experiencia es más rápida incluso con una red excelente. Primero fuera de línea es, en la práctica, un superconjunto de la filosofía de primero lo local, aplicada al caso más hostil.

Guardar local primero, siempre

El corazón del enfoque es una regla simple: toda la escritura ocurre primero en el dispositivo. La interfaz lee desde este almacenamiento local y refleja el cambio sobre la marcha. El usuario nunca espera a que el servidor vea el resultado de su propia acción.

En el navegador, el almacenamiento elegido para esto suele ser IndexedDB. Se trata de una base de datos incrustada en la propia página, capaz de almacenar volúmenes considerables de datos estructurados, con soporte para índices y consultas. A diferencia de las soluciones más simples, maneja el peso de una aplicación real, no sólo algunas preferencias vagas.

La capa de interfaz ahora trata a IndexedDB como su fuente de lectura. El servidor se convierte en una segunda capa, impulsada por la sincronización. Este diseño requiere disciplina, porque ahora hay dos lugares donde vive el troquel y deben converger sin que el usuario note la costura.

En las aplicaciones móviles nativas, el principio es idéntico, sólo cambia la tecnología de almacenamiento. Lo que importa es la regla: local primero, remoto después.

La cola de sincronización y sus detalles.

Si la escritura se realiza fuera de línea, es necesario entregarla al servidor más tarde. Aquí es donde entra en juego la cola de sincronización. Cada acción que cambia los datos se registra como una intención pendiente, se almacena localmente y se espera que se abra la ventana de conexión.

Parece simple, pero el diablo está en los detalles. La cola debe sobrevivir al cierre de la aplicación. Debes volver a intentarlo cuando la entrega falle, sin duplicar lo que ya se envió. Es necesario respetar el orden de las operaciones, porque crear un registro y luego editarlo son cosas que no se pueden intercambiar en el servidor.

Recomiendo ver cada operación en cola como idempotente siempre que sea posible. Idempotencia significa que volver a enviar la misma operación no causa daño. Esto hace que la sincronización de una fuente de errores sutiles sea un proceso predecible porque puedes volver a intentarlo sin miedo.

También hay sincronización inversa. Mientras el dispositivo estaba desconectado, el mundo continuaba: otros usuarios editaron, el servidor cambió. Cuando se restablezca la conexión, deberá realizar estos cambios y fusionarse con el estado local. Y en la fusión es donde surge el problema más espinoso de todos.

Cuando dos dispositivos editan los mismos datos

Imagine dos agentes de campo abriendo el mismo registro sin conexión. Uno corrige la dirección, el otro corrige el número de teléfono. Ambos tienen señal nuevamente y se sincronizan. ¿Qué versión gana? La respuesta ingenua, el último en llegar lo sobrescribe todo, hace que uno de ellos pierda el trabajo silenciosamente. Inaceptable.

La resolución de conflictos es el tema central de cualquiera que se tome en serio lo offline. La estrategia más simple, ganar por tiempo, funciona para datos poco cuestionados, pero falla estrepitosamente cuando las ediciones en competencia tocan diferentes campos del mismo registro.

Mejores estrategias fusionan por campo, conservando el cambio de dirección para uno y el número de teléfono para el otro. Para estructuras más complejas, entran en juego los CRDT, tipos de datos diseñados para converger automáticamente cuando se fusionan, sin necesidad de un árbitro central. Vale la pena estudiar cómo funcionan los CRDT en la práctica antes de inventar su propia lógica de fusión, porque este es un campo lleno de trampas.

Mi sincera recomendación: no trates el conflicto como un caso raro e improvises al final del proyecto. Definir tempranamente, para cada tipo de datos, la regla de convergencia. Esta decisión es tanto una decisión de producto como de ingeniería, porque define lo que sucede con el trabajo de dos personas reales.

El impacto en la experiencia de quienes lo utilizan

Todo esto existe para servir a una experiencia y el efecto en ella es excelente. Una aplicación sin conexión responde a la velocidad del tacto, no de la red. Para quienes trabajan en el campo, esta es la diferencia entre una herramienta confiable y una molestia que falla en el peor momento.

Pero es necesario ser honesto con el usuario. Debido a que la sincronización ocurre en segundo plano, necesita señales de estado claras: qué sucedió, qué está pendiente, si algo salió mal. Ocultar esto crea una falsa sensación de seguridad, y la falsa seguridad es peor que la inseguridad abierta.

Las buenas aplicaciones sin conexión se comunican sin asustar. Un indicador discreto de asuntos pendientes, un aviso cuando un conflicto requiere una decisión, una confirmación tranquila cuando todo está sincronizado. El usuario no necesita entender ingeniería, pero debe confiar en que su trabajo no se evaporará.

¿Dónde debería empezar un equipo?

Si lidera un equipo a punto de adoptar el modo offline primero, evite el error de intentarlo todo a la vez. Comience con el almacenamiento local y lea desde él. Luego introduzca la cola de sincronización para escrituras. Sólo entonces afrontar el conflicto, y afrontarlo por tipo de dato, no de forma genérica.

Resista también la tentación de crear su propio motor de sincronización desde cero. Es un problema seductor y profundo, pero que se resuelve con herramientas maduras. Comprender las opciones de los [motores de sincronización locales primero preparados para 3] puede ahorrarle meses a su equipo.

Primero sin conexión no es un lujo técnico, es una forma de respetar la realidad de quienes utilizan el software lejos de la comodidad de una red perfecta. Quienes diseñan con esta premisa ofrecen productos que siguen destacando exactamente cuando más importa.