Offline First
Utilidad que no espera conectividad inmediata
Offline First es un enfoque arquitectónico donde un cliente conserva toda o una parte crítica deliberadamente elegida de su utilidad sin exigir conexión inmediata. La definición del Atlas organiza una decisión de producto y sus consecuencias, no un estándar universal. kind: concept refleja ese alcance amplio: no identifica un único patrón, scheduler o mecanismo de almacenamiento.
Android define offline-first mediante funcionalidad completa o un subconjunto crítico sin Internet. Esa precisión permite ofrecer capacidades importantes desconectadas sin prometer todas las operaciones offline. La arquitectura de esa guía pertenece a Android; no convierte Repository, Room, Flow o WorkManager en requisitos para cualquier cliente.
El alcance incluye mobile, desktop, Web/PWA y otros clientes con almacenamiento local. mobile-architecture añade restricciones especialmente visibles de proceso y background, pero no implica Offline First ni agota sus usos. La pregunta central es qué puede hacer realmente el usuario cuando la red deja de estar disponible, no si la aplicación consigue abrir una pantalla.
Elegir capacidades, no declarar todo offline
En Commerce, consultar catálogo previamente obtenido y editar un carrito pueden seguir siendo útiles sin conexión. Autorizar un pago y confirmar stock pueden requerir al owner remoto. Esa combinación puede ser coherente: no hay que fingir que toda escritura funciona offline para reconocer un subconjunto crítico bien diseñado.
Precisar quién usa cada capacidad, qué información necesita y qué resultado puede prometerse. Una pantalla cacheada sin el dato requerido para su tarea quizá no conserve utilidad suficiente. También importa el primer uso: una instalación que nunca descargó catálogo no dispone mágicamente de ese contenido. Definir cobertura, preparación y ausencia de datos evita una promesa vacía.
Offline-capable puede describir alguna capacidad sin red; Offline First suele indicar que esa condición se considera deliberadamente en el diseño del alcance elegido. Es una distinción útil del Atlas, no vocabulario normativo de toda la industria. No se mide madurez contando acciones desconectadas ni se recomienda adoptar el enfoque para todo producto.
Cache, persistencia y Local First tienen otros alcances
Cache First describe una preferencia de acceso a información; no determina edición, vigencia, recuperación ni confirmación comercial. Persistir preferencias o un borrador tampoco demuestra que una capacidad crítica continúe funcionando. Una cache puede participar en Offline First y dejar decisiones esenciales todavía sin resolver.
Kleppmann, Wiggins, van Hardenberg y McGranaghan, Local-first software, Onward! 2019, proponen ideales que incluyen colaboración, control del usuario, múltiples dispositivos y longevidad de datos, además de trabajo offline. Local First es una propuesta más amplia; no es otro nombre de Offline First. Aquí se conserva esa diferencia sin importar toda su filosofía.
synchronization trata intercambio y reconciliación entre copias. Puede ser simple o complejo según escrituras y autoridad. Una guía de museo descargada puede funcionar offline con refresh unidireccional ocasional; edición compartida en varias réplicas necesita otros compromisos. Tener Offline First no selecciona CRDTs ni obliga a construir un motor genérico de sync.
Una copia disponible no adquiere autoridad comercial
client-state-management distingue borrador, cache, valor derivado e intención pendiente. Offline First hace decisivo cuándo existen, cuánto duran y qué puede modificarse. data-ownership conserva autoridad sobre hechos comerciales: leer stock localmente no concede capacidad para reservarlo ni prueba que otro comprador no haya consumido la última unidad.
La guía Android llama a la fuente local representación canónica consumida por capas superiores y describe la fuente de red como estado real de la aplicación. El Atlas separa esa referencia local de la autoridad semántica del negocio. No se transforma su terminología de source of truth en una autorización para que cualquier copia decida pagos o plazas.
Una nota personal puede admitir autoridad local para su alcance. Una copia de Inventory puede ser solo informativa. Declarar quién acepta cambios y qué validación necesita cada operación, en vez de imponer que todo dato sea remoto o todo dato sea local. Desconexión y ownership son dimensiones diferentes.
Lecturas útiles, vigencia y datos ausentes
Para las capacidades soportadas, la lectura necesita un recorrido útil que no quede esperando indefinidamente una respuesta remota. Puede consumir datos locales y aplicar refresh posterior. Empezar siempre por red y esperar un timeout antes de mostrar información disponible puede degradar mucho ese recorrido, sin que exista una única organización correcta para todo dato.
Preguntar qué conjunto se conserva, cuándo se prepara, cómo se actualiza y qué ocurre si falta. No hace falta replicar todo el backend. Un historial descargado puede servir para consulta y no contener adjuntos; debe quedar claro qué capacidad está disponible y cuál necesita conexión. Datos personalizados también necesitan contexto de identidad.
Fresh, stale y vigencia desconocida tienen consecuencias diferentes. Una descripción antigua puede seguir siendo útil; precio, permiso o disponibilidad pueden requerir validación nueva. No hay TTL universal ni equivalencia entre stale e inválido. La representación y sus acciones deben conservar el significado prometido, sin mostrar una estimación histórica como confirmación actual.
Escrituras: distinguir efecto de intención
Android organiza su guía en online-only, queued y lazy writes. La tabla aplica esas distinciones a ejemplos propios; no declara una taxonomía universal.
| Decisión de escritura | Ejemplo ilustrativo | Qué puede afirmarse localmente |
|---|---|---|
| Requiere conexión | Solicitar autorización de pago. | Se preparó la solicitud; falta resultado remoto. |
| Intención retenida para intentar después | Enviar feedback no urgente. | Está pendiente, sin afirmar ejecución comercial. |
| Modificar localmente y coordinar después | Editar una nota que admite ese modelo. | El cambio local existe; su relación con otras copias requiere política. |
Una operación puede permanecer online-only aunque otras capacidades sean Offline First. No basta dejar activo un botón: definir qué ocurre si la conexión desaparece durante el intento. timeout conserva el resultado incierto cuando el efecto pudo ocurrir remotamente; ausencia de confirmación no significa automáticamente rechazo.
La intención durable permite recordar trabajo todavía no ejecutado. Enviar una wishlist addition después puede ser aceptable bajo un contrato; reservar la última plaza tiene otras condiciones. Guardado local, aceptado para envío y confirmado por el owner no son estados intercambiables. La UI puede dar feedback inmediato manteniendo esas diferencias.
Lifecycle y persistencia del trabajo pendiente
Si una intención importante debe sobrevivir a terminación del proceso, una cola solo en memoria puede ser insuficiente. Especificar qué se conserva y cuándo se considera registrado. No todo trabajo merece durabilidad: perder una consulta reemplazable puede tener otro costo que perder un borrador que el usuario creyó guardar.
En mobile, el sistema operativo controla oportunidades de background; en otros clientes existen restricciones diferentes. No prometer envío inmediato al recuperar conectividad ni confundir una tarea programada con una tarea completada. mobile-architecture conserva esos límites sin imponer un scheduler móvil a desktop o Web.
web.dev documenta datos offline en PWAs, incluyendo persistencia y límites de almacenamiento. MDN distingue operación offline y background. Son mecanismos Web con condiciones propias; un service worker no define todo el enfoque. Preparar assets tampoco garantiza que datos e intenciones sobrevivan bajo cualquier condición.
Reconectar no equivale a haber terminado
Network connected no garantiza backend alcanzable, autorización vigente ni éxito del request. Esa señal puede ayudar a programar intentos; el contrato de la operación y la evidencia recibida determinan qué ocurrió. Una caída temporal y un rechazo por stock no requieren la misma respuesta.
retry distingue condiciones para repetir. idempotency ayuda cuando un intento pudo ejecutarse y vuelve a enviarse, sin hacer segura toda repetición. Separar fallo transitorio, error permanente, conflicto y resultado desconocido evita reintentar indefinidamente algo que necesita decisión de dominio o intervención del usuario.
Después de reconectar puede enviarse trabajo pendiente, obtener cambios, revisar rechazos y actualizar representaciones, con una secuencia apropiada al caso. synchronization conserva ese proceso. Una preferencia confirmada y una mutación rechazada pueden coexistir: «volvió Internet» no implica que todos los cambios locales fueron aceptados ni que ya desapareció la divergencia.
Seguridad, identidad y condiciones que cambiaron
Una acción creada offline puede enviarse con sesión expirada, cuenta distinta, permiso revocado o recurso eliminado. La ejecución remota necesita comprobar autorización e invariantes pertinentes bajo condiciones actuales. Validez cuando se guardó no garantiza validez cuando se intenta. Tampoco corresponde enviar silenciosamente el trabajo de una cuenta como si perteneciera a otra.
Parte de la utilidad local puede mantenerse sin consultar inmediatamente un servidor de autenticación, según producto y datos. Eso no concede acceso remoto ilimitado. Conservar más información en el dispositivo también aumenta responsabilidades de exposición, retención y descarte; los controles adecuados dependen de sensibilidad y plataforma, sin convertir esta nota en una guía de seguridad.
Restauración, actualización de aplicación y cambio de representación pueden afectar trabajo pendiente. Mantener o transformar su significado requiere contratos, no solo bytes recuperables. El éxito técnico de abrir una base local no demuestra que una orden vieja siga siendo legal ni que el usuario entienda su estado.
Fronteras con backend, rendering y experiencia
backend-for-frontend puede adaptar payloads y conversaciones remotas; su disponibilidad no resuelve el funcionamiento desconectado. rendering-strategies pregunta dónde y cuándo se produce representación. CSR puede seguir dependiendo de red, y una aplicación que entrega HTML servidor puede tener utilidad offline posterior. No hay una correspondencia obligatoria entre esos nombres y Offline First.
Pendiente, stale, failed, requiere conexión o conflicto expresan diferencias que pueden importar al usuario. No se prescribe un enum, icono o interfaz universal. accessibility y internationalization exigen que contexto y recuperación sigan siendo comprensibles y utilizables en las variantes soportadas; sus recursos necesarios también deben estar disponibles para la capacidad offline prometida. No conviene ocultar incertidumbre comercial detrás de una indicación genérica de conexión.
La elección agrega copias, lifecycle, pruebas, recuperación y soporte. Puede reducir interrupciones reales y añadir accidental-complexity cuando se extiende sin necesidad. trade-off-analysis ayuda a comparar utilidad conservada y costos. web-performance conserva otra pregunta sobre rapidez, respuesta y estabilidad; descargar mucho contenido anticipadamente no demuestra una experiencia mejor ni la utilidad de datos locales implica vigencia.
Commerce y University: disponibilidad sin inventar compromisos
En este ejemplo del Atlas, Commerce conserva catálogo y edición de cart. Los precios y stock visibles pueden estar atrasados; al comprar, las capacidades autoritativas validan condiciones actuales. Preparar checkout no autoriza pago offline. Una modificación optimista de cantidad puede quedar pendiente y ser rechazada por Inventory: hay que reconciliar lo representado, sin prometer rollback trivial.
Una wishlist addition podría enviarse después si sus reglas lo permiten. Tras reconexión, el cliente puede recibir confirmación, rechazo o datos nuevos y distinguir cada caso. Otro dispositivo pudo modificar el carrito mientras tanto. Tener acceso local no selecciona automáticamente una regla de último escritor ni exige que el mismo modelo sirva para todas las capacidades de Commerce.
En University, el estudiante consulta cursos descargados y ordena secciones preferidas offline. La adjudicación de una plaza depende de capacidad autoritativa actual; preferencias guardadas no equivalen a matrícula. Dos dispositivos pueden editar la lista y necesitar una política de reconciliación, mientras la decisión sobre la última plaza conserva una invariante distinta.
Relación con Synchronization y criterio de adopción
Offline First pregunta qué utilidad continúa sin red inmediata. Synchronization pregunta cómo se relacionan cambios y copias después. Un cliente normalmente online puede sincronizar continuamente sin ofrecer uso desconectado como requisito; una guía de museo offline puede necesitar solo refresh sencillo. Los conceptos se combinan sin implicarse con idéntica complejidad.
Adoptar requiere identificar capacidades, autoridad, datos disponibles, persistencia, confirmación y recuperación verificables. «No hay servidor», «toda escritura funciona localmente» o «sync posterior siempre lo arregla» no son conclusiones del enfoque. frontend-and-client-architecture organiza el recorrido hacia esas decisiones, conservando una fuente canónica para cada pregunta.