Aplicación offline: software de empresa que sigue funcionando sin internet

Una aplicación offline permite seguir trabajando cuando se corta internet y sincroniza los datos con el servidor automáticamente cuando vuelve la conexión. A este enfoque se le llama offline first: la aplicación guarda primero los datos en el dispositivo, pone los cambios en cola y los envía cuando puede, así que el usuario nunca ve “no se ha podido guardar” y el trabajo no se interrumpe. Nuestro software de marcador en vivo Multi Score Screen sigue este principio: si el wifi del pabellón se debilita, el árbitro sigue puntuando, los datos se sincronizan al volver la conexión y el partido continúa. En este artículo explicamos cómo funciona el offline first, qué negocios lo necesitan más y qué mirar al elegir o desarrollar este tipo de software.

Por qué importa: internet no es estable en todas partes

La conexión que parece perfecta en la oficina a menudo no lo es donde se trabaja de verdad. Talleres en puertos deportivos, almacenes en sótanos, pabellones de hormigón y acero, obras y técnicos de campo conviven con conexiones débiles o inexistentes. Una aplicación que solo funciona en la nube se detiene en esos momentos: el formulario no se guarda, el stock no baja, el marcador no se actualiza. El usuario espera o lo apunta en papel para pasarlo luego, lo que cuesta tiempo y provoca errores.

El offline first da la vuelta al problema: la aplicación se diseña suponiendo que no hay conexión y la trata como un extra. Para el usuario la diferencia es clara; la app abre rápido y responde al instante porque trabaja primero con los datos locales.

Cómo funciona el offline first

1. Almacén local: la app guarda los datos en el dispositivo, normalmente en IndexedDB en las apps web o en una base local como SQLite en escritorio y móvil.
2. Cola de cambios: cada cambio se escribe en local y se añade a una cola de pendientes de envío.
3. Sincronización: al volver la conexión, la cola se envía en orden al servidor y se descargan los datos nuevos.
4. Identificadores únicos: como los registros nacen en el dispositivo, los ID deben generarse sin preguntar al servidor y sin colisiones, por ejemplo con UUID.
5. Resolución de conflictos: una regla decide qué versión vale si el mismo registro cambió distinto en dos dispositivos.

El ejemplo sencillo de abajo muestra la idea: guardar en local, poner el cambio en cola y enviarlo si hay conexión.

// Offline-first in a nutshell: write locally, queue the change, sync when online
async function savePoint(matchId: string, team: "A" | "B") {
  const change = { id: crypto.randomUUID(), matchId, team, at: Date.now() };
  await localDb.put("points", change);      // 1. the UI updates from local data at once
  await localDb.put("outbox", change);      // 2. remember what still has to reach the server
  if (navigator.onLine) void flushOutbox(); // 3. try to sync now, otherwise later
}

async function flushOutbox() {
  for (const change of await localDb.getAll("outbox")) {
    const res = await fetch("/api/points", { method: "POST", body: JSON.stringify(change) });
    if (!res.ok) return;                    // keep it queued and retry on the next "online" event
    await localDb.delete("outbox", change.id);
  }
}
window.addEventListener("online", () => void flushOutbox());

Conflictos: la parte más difícil

La gran pregunta de diseño es qué pasa cuando dos personas cambian los mismos datos sin conexión. Hay tres estrategias habituales. “Gana la última escritura” es sencilla, pero puede perder cambios sin avisar. La fusión por campos combina cambios en campos distintos del mismo registro: si uno cambió el teléfono y otro la dirección, se conservan ambos. A veces lo mejor es preguntar al usuario: si dos técnicos marcaron distinto la misma orden de trabajo, el sistema muestra el conflicto y pide decidir. En datos numéricos como el stock, sincronizar movimientos en vez de valores (“salen 3 unidades”) elimina la mayoría de conflictos.

¿Web, PWA o escritorio?

Funcionar sin conexión no es exclusivo de las aplicaciones de escritorio. Las aplicaciones web progresivas (PWA) guardan sus archivos con un service worker y los datos en el navegador, así que pueden trabajar sin conexión. Las de escritorio funcionan en local por naturaleza y, con una capa de sincronización, también entre varios dispositivos. La opción adecuada depende de los dispositivos, de la impresión y el hardware y de cómo quieras distribuir el software; lo vemos en el artículo sobre aplicación web vs escritorio. La lógica del software por suscripción en la nube está en qué es SaaS.

Experiencia de usuario: mostrar la conexión con honestidad

• Muestra el estado de sincronización: un indicador como “Todo guardado” o “3 cambios pendientes” da confianza.
• No pierdas datos en silencio: un cambio que no se pudo enviar debe avisarse y reintentarse.
• Explica qué se puede hacer sin conexión: por ejemplo, crear registros sí, cobrar no; muestra esos límites.
• Permite deshacer: los errores hechos sin conexión deben poder corregirse igual de fácil.

Seguridad y copias de seguridad

Cuando los datos viven en el dispositivo, perderlo o que lo roben se convierte en un riesgo. Cifrar los datos sensibles, limitar la duración de la sesión y poder cerrar la sesión de un dispositivo a distancia son medidas básicas. La sincronización crea además una copia central que se respalda en el servidor, pero los cambios sin sincronizar solo están en el dispositivo, así que conviene avisar al usuario tras mucho tiempo sin conexión.

Probar el funcionamiento sin conexión

Probar una app offline first solo con buena conexión no basta. Usa la limitación de red y el modo sin conexión de las herramientas de desarrollo del navegador y el modo avión del móvil para estos casos: crear registros sin conexión, corte a mitad de una acción, el mismo registro cambiado en dos dispositivos y sincronizar tras mucho tiempo sin red. Por qué importa en stock y órdenes de trabajo lo contamos en el artículo sobre inventario con código de barras.

¿Cuándo elegir offline first?

El offline first añade complejidad: sincronización, conflictos y pruebas requieren más desarrollo. Si tus usuarios trabajan siempre en una oficina con conexión fiable, quizá no lo necesites. Pero si el trabajo se hace en la calle, en un taller, en un pabellón o en un evento, y un corte significa trabajo perdido, la inversión se recupera rápido. Como indican las preguntas frecuentes de Multi Score Screen, puntuar sin interrupciones con conexión débil está pensado para que ningún partido se corte. Puedes ver las pantallas del producto en nuestra página de Multi Score Screen y, si quieres una aplicación que funcione sin conexión para tu negocio, consultar nuestro servicio de desarrollo de software a medida.

Compartir:XLinkedInWhatsApp