Patrones que lo hacen soportable: lotes, blobs, desnormalizar y Worker

Los tres niveles anteriores diagnostican: el clonado cobra por nodo, la transacción cobra por confirmación, los índices cobran por escritura y el disco cobra por sincronización. Los cuatro patrones de esta lección son las respuestas, y todas son variaciones de un mismo movimiento —cruzar la frontera menos veces y con menos cosas encima—. Ninguno es un truco: los cuatro son decisiones de arquitectura que hay que tomar antes de escribir el esquema, porque después cuestan una migración.

Escribir por lotes, leer por bloques

El patrón base ya está justificado en el nivel 8.2, pero la versión de producción tiene tres detalles que la versión de ejemplo no: cede el hilo entre lotes para que la interfaz siga viva, informa del progreso porque una importación larga sin retroalimentación se percibe como una aplicación colgada, y trata el fallo de un lote como recuperable en lugar de abortar la operación entera.

async function importar(db, registros, { tam = 2000, onProgreso } = {}) {
  const fallidos = [];
  for (let i = 0; i < registros.length; i += tam) {
    const lote = registros.slice(i, i + tam);
    try {
      const tx = db.transaction("docs", "readwrite", { durability: "relaxed" });
      const store = tx.objectStore("docs");
      for (const r of lote) store.put(r);   // sin await dentro del bucle
      await esperar(tx);
    } catch (e) {
      fallidos.push({ desde: i, error: e }); // el lote revierte entero
    }
    onProgreso?.(i + lote.length, registros.length);
    await new Promise(r => setTimeout(r));   // deja respirar al hilo
  }
  return fallidos;
}

En el lado de la lectura, la simetría es exacta: getAll con un rango de claves y un límite trae un bloque en una sola petición, mientras que un cursor paga una vuelta al bucle de eventos por registro. El cursor sigue siendo la herramienta correcta cuando necesitas abortar a mitad del recorrido, cuando el conjunto no cabe en memoria o cuando quieres procesar en flujo; para traer una página que vas a pintar entera, getAll gana siempre.

// Paginacion por clave: sin desplazamiento, sin recorrer lo ya visto.
function pagina(store, ultimaClave, n = 200) {
  const rango = ultimaClave === undefined
    ? null
    : IDBKeyRange.lowerBound(ultimaClave, true);
  return esperar(store.getAll(rango, n));
}

Guardar bytes, no grafos

Este es el patrón con mayor retorno y el que más cuesta aceptar, porque va contra el instinto de modelar. La idea: separar el registro en dos zonas. Arriba, unos pocos campos escalares —los que se indexan y por los que se consulta—. Abajo, un único campo binario con todo lo demás, codificado por ti. El clonado estructurado pasa de recorrer miles de nodos a recorrer media docena de escalares y un ArrayBuffer opaco.

// Esquema en dos zonas: escalares indexables arriba, carga util opaca abajo.
const registro = {
  id: doc.id,                     // clave primaria
  autorId: doc.autor.id,          // indexado
  actualizado: doc.actualizado,   // indexado, para ordenar
  version: 3,                     // version del codec, imprescindible
  cuerpo: codificar(doc.bloques), // ArrayBuffer: un solo nodo
};

Desnormalizar: aquí no existe la reunión

IndexedDB no tiene ninguna operación de reunión de tablas. Lo que en SQL sería una consulta con JOIN aquí es, literalmente, un bucle: para cada resultado del primer almacén, una petición al segundo. Ese patrón paga una vuelta al bucle de eventos y un clonado por elemento, y es la causa de la mayoría de listas que tardan un segundo en aparecer.

La respuesta es la de cualquier sistema orientado a lectura: precalcular la forma en que vas a leer. Si la vista muestra el título del documento junto al nombre del autor, guarda el nombre del autor dentro del documento. Si la vista necesita el número de comentarios, guarda el contador. Duplicas datos y aceptas amplificación de escritura —cambiar un nombre de autor obliga a tocar todos sus documentos— a cambio de que la lectura sea una sola petición.

La variante disciplinada de esta idea es mantener almacenes de proyección separados de los almacenes de verdad: uno guarda las entidades canónicas y otro guarda, ya montada, la forma exacta que consume cada vista. La proyección se reconstruye siempre desde la fuente y nunca se edita a mano, de modo que una incoherencia se arregla regenerándola en lugar de parcheándola. Es el mismo reparto entre escritura y lectura que la separación de responsabilidades de consulta y comando propone en el servidor, aplicado dentro de una pestaña.

flowchart LR
subgraph N [Normalizado]
  N1[getAll docs] --> N2[por cada doc get autor]
  N2 --> N3[N peticiones y N clonados]
end
subgraph D [Desnormalizado]
  D1[getAll docs con nombre incrustado] --> D2[una peticion y un clonado]
end
N3 --> R[lista lenta]
D2 --> S[lista instantanea]

Mover la capa de datos al Worker

El cuarto movimiento saca del hilo principal todo lo que la lección 8.3 identificaba como bloqueo. La base se abre dentro de un Worker dedicado, que expone una interfaz de llamadas por mensajes; el hilo principal pide resultados y nunca toca IndexedDB. La deserialización de diez mil registros sigue costando lo mismo, pero ya no impide que el usuario haga clic.

Hay una trampa que anula la ganancia si no se ve venir: postMessage también usa clonado estructurado. Devolver al hilo principal el mismo grafo enorme que acabas de deserializar en el Worker significa pagar el peaje dos veces, una en cada lado. El patrón solo funciona si el Worker reduce lo que cruza.

Y hay una segunda trampa, más sutil: aunque el clonado del envío ocurra en el Worker, la deserialización del mensaje recibido ocurre en el hilo principal, dentro de su manejador. Mover la base al Worker elimina el bloqueo de la lectura del almacén, pero no el de reconstruir en el hilo principal lo que le mandas. Por eso la métrica que hay que vigilar no es cuánto trabajo se fue al Worker, sino cuántos nodos siguen atravesando la frontera de vuelta.