Qué elegir para qué: la tabla de decisión honesta

Las cuatro lecciones anteriores describen el territorio; esta lo convierte en una decisión. La forma honesta de hacerlo no es una tabla que reparta seis mecanismos entre seis casos de uso, porque los casos reales caen casi siempre en los bordes: la preferencia que empieza a crecer, el borrador que el usuario no quiere perder, la caché que en realidad quería ser una consulta. Lo que hace útil una guía de elección no es su casilla central sino su tratamiento de los límites, y sobre todo su honestidad respecto a algo que casi nunca se explicita: el coste de equivocarse es profundamente asimétrico, y esa asimetría, no la elegancia técnica, es lo que debe gobernar la decisión por defecto.

Los cuatro casos canónicos

Cuatro casos concentran la inmensa mayoría de lo que una aplicación necesita persistir. Vale la pena resolverlos de forma explícita, con su condición de validez, antes de mirar los bordes.

Preferencias del usuario. Dato diminuto, acotado por diseño, que a menudo debe leerse antes del primer fotograma para no pintar con el valor equivocado. Es el caso donde la sincronía de localStorage es una virtud y su cuota basta con holgura. La única condición es que la lista de preferencias esté cerrada: en cuanto pasa a ser una preferencia por documento o por proyecto, deja de estar acotada y cambia de casilla.

Borradores y trabajo del usuario. Aquí la propiedad que manda no es el tamaño sino el valor de lo que se pierde. Un borrador es contenido que la persona ha creado y que no existe en ningún otro sitio, lo cual exige escrituras que no puedan quedar a medias y un almacén que crezca sin un techo que sorprenda. IndexedDB es la respuesta: transacciones, cuota dinámica gestionada por el navegador, y estructura para guardar el documento sin serializarlo entero en cada pulsación.

Caché de recursos de red. El mecanismo diseñado exactamente para esto es la Cache API, y es uno de los pocos casos del inventario en que existe una respuesta única y sin matices.

La Cache API, cuya clave es un Request y cuyo valor es un Response completo con sus cabeceras. Guardar respuestas HTTP en IndexedDB es reimplementar a mano, y peor, algo que la plataforma ya resuelve; guardarlas en localStorage añade además el impuesto de base64 sobre cualquier cuerpo binario.

Base de datos completa de la aplicación. Cuando el cliente debe responder consultas sobre volúmenes que no caben en memoria, la elección real está entre IndexedDB con una biblioteca encima y un motor SQL compilado a WebAssembly sobre OPFS, ejecutándose dentro de un Worker. Es la configuración hacia la que converge todo el local-first serio, y el resto del track la desarrolla.

Conviene decir explícitamente algo que la presentación por casos oculta: estos cuatro mecanismos no compiten, coexisten. Una aplicación madura los usa todos a la vez, cada uno en su función, y esa combinación no es un síntoma de indecisión arquitectónica sino la consecuencia natural de que cada capa resuelva un problema distinto. Una configuración típica y sana consiste en una cookie HttpOnly para la sesión, dos claves en localStorage para el arranque, la Cache API para el casco de la aplicación, e IndexedDB u OPFS para los datos. Quien intenta unificarlo todo en un solo mecanismo acaba usando el equivocado para tres de las cuatro funciones.

flowchart TD
A[Que dato quiero guardar] --> B{lo necesito antes del primer fotograma}
B -->|si| C[localStorage con tamano acotado]
B -->|no| D{es trafico de red}
D -->|si| E[Cache API]
D -->|no| F{necesito consultar partes sin cargar el todo}
F -->|no| G{muere con la pestana}
G -->|si| H[sessionStorage]
G -->|no| C
F -->|si| I{necesito consultas complejas o volumen grande}
I -->|no| J[IndexedDB]
I -->|si| K[motor SQL sobre OPFS en un Worker]
style C fill:#f9e2af,color:#11111b
style J fill:#a6e3a1,color:#11111b
style K fill:#89b4fa,color:#11111b

La tabla de decisión

Obsérvese que la última fila de la columna de ruptura no propone otro mecanismo del navegador, sino abandonar el cliente. Esa salida tiene que existir en cualquier guía honesta.

La columna que importa de verdad es la tercera. Una tabla que solo empareja casos con mecanismos envejece mal, porque los casos reales nunca llegan en la forma canónica en que aparecen escritos; una tabla que enuncia la condición bajo la cual la elección es válida sigue sirviendo cuando el caso muta, porque te dice exactamente en qué momento debes volver a decidir. Léela, por tanto, como un conjunto de contratos con condición de ruptura, no como un diccionario.

Los casos límite que la tabla no resuelve

Las casillas anteriores cubren el centro de la distribución. Los problemas reales viven en los bordes, y ahí la tabla deja de decidir por ti. Los cuatro que siguen son los que más veces he visto resolverse mal, y los cuatro comparten un rasgo: en todos ellos la intuición apunta con seguridad en la dirección equivocada.

El caso de la preferencia que crece tiene una dinámica reconocible y vale la pena describirla, porque es la forma en que casi todas las aplicaciones acaban con datos en el mecanismo equivocado. Nadie decide nunca guardar una tabla en localStorage; lo que ocurre es que se guarda una preferencia legítima, luego una segunda, luego una que depende del documento abierto, y en algún punto de esa secuencia —sin que ninguna decisión individual fuera errónea— el conjunto dejó de ser una lista cerrada. El error no está en ninguna de las escrituras, está en la ausencia de un criterio explícito que dijera dónde se cruzaba la frontera.

El caso del borrador merece detenerse porque es el que más a menudo se resuelve mal. La intuición dice que un borrador pertenece a la sesión de edición y por tanto a sessionStorage; la experiencia dice lo contrario. El escenario que justifica guardar un borrador es exactamente aquel en el que sessionStorage no sobrevive: la pestaña cerrada por accidente, el navegador que se cierra, el sistema que reinicia. Un mecanismo cuya vida coincide con la del riesgo del que quieres protegerte no ofrece protección alguna.

// Antipatron: el borrador vive justo lo que dura el riesgo del que protege
sessionStorage.setItem("borrador", texto);

// Correcto: escritura atomica en un almacen que sobrevive al cierre
const tx = db.transaction("borradores", "readwrite");
await tx.objectStore("borradores").put({ id, texto, actualizado: Date.now() });
await tx.done; // o falla entera, o no falla

El coste de equivocarse

Aquí está la parte que las guías suelen omitir. Los errores de elección no cuestan lo mismo, y su coste no se mide en rendimiento sino en reversibilidad. Un error reversible es una decisión; un error irreversible es una restricción con la que vivirás durante años.

Equivocarse por exceso —usar IndexedDB para cuatro preferencias— es barato: pagas complejidad innecesaria y algo de código de arranque, y revertirlo es una tarde de trabajo. Es un error visible desde el primer día, que además se manifiesta en tu propia máquina y no en la del usuario, lo cual lo convierte casi en un no problema. Equivocarse por defecto —usar localStorage para datos que crecen— es caro por tres motivos que se acumulan. El fallo llega tarde, cuando ya hay usuarios con datos acumulados. Llega en el dispositivo del usuario más comprometido, que es el que más ha guardado. Y sobre todo, corregirlo no es cambiar una línea: los datos ya están en el mecanismo equivocado, en dispositivos que no controlas, y hay que escribir una migración que se ejecute en cada uno de ellos, tolerar estados a medio migrar, y mantener el lector antiguo indefinidamente porque siempre habrá alguien que vuelva después de un año.

La defensa contra ese coste es sorprendentemente barata si se paga por adelantado: versiona el formato desde la primera línea. Un número de versión guardado junto a los datos, y una función que sepa leer el formato anterior y escribir el nuevo, convierten una migración distribuida en un trámite de veinte líneas. Escribirla cuando ya hay usuarios afectados cuesta un orden de magnitud más, porque entonces hay que inferir el formato antiguo a partir de lo que encuentres.

// Escrito desde el primer dia, la migracion futura cuesta veinte lineas
const VERSION = 2;
const crudo = JSON.parse(localStorage.getItem("ajustes") ?? "null");
const ajustes =
  crudo === null ? porDefecto()
  : crudo.version === VERSION ? crudo
  : migrar(crudo); // el lector antiguo se mantiene, no se borra

El tercer error, el más silencioso, es confiar la única copia del trabajo del usuario a un almacén desalojable. Es silencioso porque no produce ningún error que puedas registrar: simplemente, un día el usuario abre la aplicación y su trabajo no está. Los datos de IndexedDB, Cache API y OPFS nacen en modo best-effort, y ese modo significa exactamente que el navegador puede borrarlos bajo presión de disco sin preguntar. Solicitar persistencia con navigator.storage.persist() mejora la situación, pero es una petición que puede ser denegada; una arquitectura que trate el almacenamiento local como indestructible está apostando el trabajo de sus usuarios contra una heurística que no controla.

// Antes de tratar el almacen local como fuente unica de verdad
const yaPersistido = await navigator.storage.persisted();
const concedido = yaPersistido || (await navigator.storage.persist());
if (!concedido) {
  // sigues siendo desalojable: exporta, sincroniza o avisa. No lo ignores
}