Offline-First en Obra Es una Decisión de Producto

Offline-first normalmente se vende como cacheo, y no lo es. Es una decisión sobre qué puede seguir haciendo la aplicación cuando no hay red, y esa lista la escribe quien entiende el trabajo, no quien entiende la librería de sincronización. Una obra no es un lugar donde la conectividad falla de vez en cuando. Es un sótano, una estructura metálica, un sitio a treinta kilómetros de la antena más cercana — una partición que dura todo el turno y se repite todos los días. La ingeniería se desprende de aceptar eso; no lo sustituye.

Resumen rápido

• Una obra es una partición permanente, así que la disponibilidad hay que elegirla deliberadamente y renunciar a propósito a algunas garantías.
• El entregable central es la lista de acciones que tienen que funcionar sin señal. Esa lista es una decisión de producto anterior a cualquier código de sincronización.
• Los conflictos no son un solo problema. Cada tipo de registro es fusionable automáticamente, de solo agregar, o requiere una persona — y la clasificación es el diseño.
• Las fotos y el video son el costo real de la sincronización. Metadatos y medios van en colas separadas con prioridades distintas.
• Agregar comportamiento offline después se acerca a una reescritura, lo que hace de esta una de las pocas decisiones que de verdad vale la pena tomar temprano.

Esta es la arquitectura de la que depende la mitad de adopción en campo de qué construyen las empresas de construcción cuando su plataforma se queda corta. Una herramienta que no se puede usar donde ocurre el trabajo no se adopta, diga lo que diga su lista de funcionalidades.

¿Por Qué una Obra Es una Partición y No una Caída?

Porque la red está ausente por defecto, y el sistema igual tiene que servir.

El resultado de sistemas distribuidos acá es viejo y exacto. La prueba de Gilbert y Lynch de 2002 de la conjetura de Brewer estableció que un sistema no puede garantizar simultáneamente consistencia y disponibilidad cuando la red se particiona. En obra la partición no es hipotética, así que la elección no es si renunciar a algo — es a qué.

Casi siempre la respuesta es disponibilidad sobre consistencia estricta: el contratista tiene que poder registrar lo que está haciendo ahora mismo, y el sistema acepta que dos dispositivos sostengan brevemente versiones distintas de la verdad. Decir eso sin rodeos tiene una consecuencia que la mayoría de los equipos evita enfrentar. Si dos personas pueden escribir a la vez y las dos escrituras tienen que funcionar, entonces el sistema va a producir divergencia, y la divergencia hay que resolverla con una regla que usted eligió y no con la petición que llegó de última.

La versión más instructiva de esto es un dispositivo que construyó CodeBranch donde la red no se requiere del todo. El controlador INL8 de un ecosistema IoT residencial opera sus ocho zonas eléctricas desde un teclado físico en la pared, sin internet, sin app y sin configuración — el electricista lo instala y funciona. La conectividad, cuando llega, agrega control remoto, programación y actualizaciones over-the-air. No enciende el producto.

Esa es la postura arquitectónica que vale la pena copiar incluso en software sin hardware: la red debería agregar capacidad, no otorgar permiso.

¿Qué Tiene que Funcionar sin Señal?

La lista, y escribirla es la verdadera sesión de diseño.

No es “todo”, y pretender lo contrario produce un peor producto que elegir. Leer un plano, registrar una medición, fotografiar una condición, cerrar una tarea, firmar una bitácora diaria — esos son candidatos. Aprobar una orden de cambio que afecta el valor de un contrato, o leer un precio del que otro sistema es dueño, normalmente no.

Tres preguntas resuelven cada fila:

• ¿El usuario puede actuar sobre el resultado de inmediato? Si la acción solo importa cuando alguien más la ve, encolarla sin conexión agrega riesgo sin agregar valor.
• ¿El dato que el usuario necesita ya está en el dispositivo? Una acción que depende de una consulta al servidor no se vuelve offline por fuerza de voluntad; necesita esa consulta presincronizada, lo que tiene su propio costo.
• ¿Qué pasa si resulta estar mal después de sincronizar? Una acción offline que no se puede revertir barato es un pasivo.

Todo lo que sobrevive a esas tres preguntas entra al conjunto offline, y todo lo del conjunto offline necesita almacenamiento local, una cola, una regla de conflicto y un estado de sincronización visible. Todo lo que queda afuera puede ser honesto y exigir conexión — cosa que los usuarios aceptan, siempre que la frontera sea predecible.

¿Qué Conflictos Pasan de Verdad en Construcción?

Tres tipos, y tratarlos igual es el error.

La mayoría del dato de campo en construcción es de solo agregar, y eso es buena noticia: dos cuadrillas fotografiando el mismo muro producen dos fotos, no un conflicto. La segunda categoría es donde la resolución automática se gana su lugar, y está bien estudiada — el estudio del INRIA de 2011 sobre tipos de datos replicados libres de conflicto, de Shapiro y colegas, plantea estructuras que convergen sin coordinación, que es exactamente la garantía que quiere una app de campo offline.

La tercera categoría es pequeña y peligrosa. Dos personas reportando cantidades distintas instaladas en el mismo frente no es un problema de fusión; es un desacuerdo sobre la realidad, y un software que lo resuelve en silencio destruyó información. Esos registros necesitan que se conserven las dos versiones y que se le pregunte a una persona.

Clasificar cada entidad en una de esas tres filas es la mayor parte del trabajo de diseño. Los equipos que se lo saltan terminan con una sola regla global — normalmente last-write-wins — aplicada a datos donde es catastrófica.

¿Cómo Se Sincronizan Fotos sin Matar el Dispositivo?

Negándose a tratarlas como un registro más.

Un día de documentación de obra son unos pocos kilobytes de dato estructurado y varios cientos de megabytes de medios. Si los dos viajan en una sola cola, el registro estructurado — la parte que le importa hoy a la oficina — espera detrás de un video. Mientras tanto la radio se queda activa sobre una conexión débil, que es lo más caro que un celular le puede hacer a su batería.

El patrón que funciona los separa:

• Los metadatos sincronizan primero y solos. La bitácora, las mediciones y las referencias a los medios llegan a los segundos de haber señal. La oficina ve que el trabajo ocurrió.
• Los medios sincronizan con su propia política. Diferidos a Wi-Fi donde la organización lo permita, troceados para que una conexión caída reanude en vez de reiniciar, y ordenados para que las fotos de condiciones marcadas vayan antes que las de rutina.
• El registro es usable mientras los medios están pendientes. Un reporte que dice “3 fotos subiendo” sirve más que uno que todavía no existe.

La misma disciplina aparece del lado de hardware del equipo de campo conectado. En la app de herramientas conectadas que CodeBranch construyó para un fabricante estadounidense, las mediciones, las anotaciones y los medios se enganchan todos a un espacio, y el dato estructurado de la medición es pequeño y rápido mientras la foto y el video del mismo espacio no lo son. Tratarlos como una sola carga haría la parte rápida tan lenta como la lenta.

¿Qué Le Compra la Configuración Cero?

Elimina el paso que con más probabilidad se salta.

La instalación es donde muere el software de campo. Un dispositivo o una app que exige un técnico, una credencial de red o una pasada de configuración es uno que se instala mal, o no se instala, por quien esté en obra ese día. Los módulos INL8 que construyó CodeBranch se autoconfiguran: detectan y se unen a la red del hogar al primer encendido, se registran en la nube y aparecen en la app de control sin ninguna configuración manual. No hay paso de configuración que saltarse porque no hay paso de configuración.

En una app de campo el equivalente es un inicio de sesión que sobrevive, un almacén local que existe antes de la primera sincronización, y un primer arranque que funciona en obra en vez de exigir una visita previa a la oficina. La prueba es simple y vale la pena aplicarla literalmente: ¿alguien puede instalar esto en un sótano, sin señal, y empezar a trabajar?

¿Cuándo Offline-First Es Más de lo que Necesita?

Cuando el trabajo en realidad no es en campo.

Algún software de construcción se usa en un contenedor de obra con Wi-Fi, en una oficina, o en una tableta que vuelve a un escritorio todas las noches. Para eso, offline-first es ingeniería gastada en una condición que no ocurre, y una aplicación en línea directa con buen manejo de errores es la mejor construcción.

La frontera honesta es esta: offline-first vale su costo cuando los usuarios de campo crean datos y no solo los leen, y cuando la brecha entre crearlos y alcanzar una conexión se mide en horas. El acceso de campo de solo lectura es un problema de caché con un presupuesto mucho menor.

Cuando la respuesta sí apunta a offline-first, la decisión va al principio. Por eso CodeBranch la resuelve en la fase de Product Definition de software para empresas de construcción, junto con la pregunta de qué se le está pidiendo capturar al campo — las dos decisiones se condicionan mutuamente, y las dos se vuelven caras una vez la primera versión está en manos de la gente.