El arranque en frío: los milisegundos que nadie diseña

Hay un intervalo en toda aplicación local-first que casi nadie diseña y que sin embargo es lo primero que el usuario experimenta: el que va desde que pulsa el marcador hasta que la base de datos puede responder a la primera pregunta. Durante ese intervalo tu aplicación no está lenta, es que literalmente no existe todavía, y la diferencia importa porque las dos situaciones piden respuestas distintas de la interfaz. La ironía del asunto es difícil de exagerar: el software local-first se vende con la promesa de que no habrá esperas, y la arquitectura que hace posible esa promesa introduce una espera al principio que puede superar con creces la de cargar una página convencional contra un servidor. Esta lección desmonta ese intervalo etapa por etapa, lo convierte en una máquina de estados explícita, y examina la técnica que permite enseñar algo verdadero antes de que la base esté disponible.

La secuencia real, etapa por etapa

Lo que la gente llama arrancar la base son en realidad ocho etapas encadenadas, con perfiles de coste muy distintos y, sobre todo, con modos de fallo independientes. Enumerarlas es la mitad del trabajo, porque el error habitual es tratarlas como un bloque opaco que termina bien o mal.

1. Carga del documento y del código de la aplicación. Antes de que exista ninguna base, el navegador tiene que analizar y ejecutar tu código. Es la etapa que ya conocías y la única que las herramientas convencionales miden bien.
2. Creación del Worker. Barata, pero no gratuita, y ocurre después de que tu código haya empezado a correr.
3. Adquisición del bloqueo de líder. Si otra pestaña ya lo tiene, esta ruta no continúa: la pestaña se convierte en seguidora, que es un camino distinto con un coste distinto y casi siempre menor.
4. Descarga del binario del motor. Decenas o cientos de kilobytes en el primer arranque, servidos desde la caché en los siguientes. Es la etapa que más se beneficia de la compilación en flujo mientras se descarga.
5. Compilación e instanciación. Coste real de procesador, muy dependiente del dispositivo, y donde la diferencia entre un portátil de desarrollo y un móvil de gama media alcanza un factor incómodo de mirar.
6. Apertura del almacén. Adquirir el manejador exclusivo sobre el fichero. Rápida cuando funciona; cuando no, produce el error de contención que conoces del nivel 10.
7. Verificación del esquema. Leer la versión almacenada y compararla con la que el código espera. Milisegundos.
8. Migración. La única etapa sin cota superior. Añadir una columna es instantáneo; reescribir una tabla de medio gigabyte no lo es, y ocurre en el dispositivo del usuario, una sola vez, sin que nadie lo haya podido ensayar a esa escala.

La máquina de estados

Un indicador booleano de carga es insuficiente porque no distingue entre estar arrancando y haber fracasado, ni entre las distintas razones de fracaso, que piden mensajes y acciones diferentes. Lo que necesitas es una máquina de estados explícita, publicada por el Worker y observable desde la interfaz.

stateDiagram-v2
[*] --> Arrancando
Arrancando --> Seguidora: otra pestana tiene el bloqueo
Arrancando --> Cargando: bloqueo obtenido
Cargando --> Instanciando: binario descargado
Instanciando --> Abriendo: modulo listo
Abriendo --> Verificando: manejador obtenido
Abriendo --> Bloqueada: manejador denegado
Verificando --> Migrando: esquema desfasado
Verificando --> Listo: esquema correcto
Migrando --> Listo: migracion completada
Migrando --> Rota: migracion fallida
Seguidora --> Listo: proxy establecido
Seguidora --> Cargando: el lider desaparecio
Listo --> [*]

Tres observaciones sobre este diagrama que no son evidentes en el código. La primera es que el camino de la seguidora es un camino de primera clase, no una excepción: en una aplicación que la gente usa con varias pestañas, es el camino más frecuente, suele ser más rápido porque se salta la descarga y la instanciación, y tiene su propio modo de fallo cuando el líder desaparece a mitad. La segunda es que hay dos estados terminales de error distintos —bloqueada y rota— que exigen mensajes opuestos: uno se resuelve cerrando otra pestaña y el otro no se resuelve con nada que el usuario pueda hacer. La tercera es que la transición de seguidora a candidata a líder debe existir, porque el usuario cerrará la pestaña líder tarde o temprano y las demás no pueden quedarse muertas.

Sobre las etapas cuatro y cinco conviene decir lo que sí funciona, porque hay dos técnicas que rinden mucho y son casi gratuitas. La primera es compilar mientras se descarga: las interfaces de instanciación que aceptan directamente la respuesta de red solapan ambas etapas en lugar de encadenarlas, y en conexiones modestas eso recorta un tramo apreciable sin cambiar nada más. La segunda es empezar antes: nada obliga a esperar a que tu aplicación termine de arrancar para lanzar la descarga del binario y la creación del Worker, y adelantarlas al principio del documento las solapa con el análisis y la ejecución de tu propio código. Las dos juntas suelen convertir dos etapas secuenciales en una sola espera, que es la única forma real de mejorar una cadena.

Mientras la máquina no llega a listo, las peticiones que la interfaz emita tienen que encolarse, nunca perderse ni fallar. Esa cola es la pieza que permite que el resto de la aplicación se escriba sin pensar en el arranque.

const cola = [];
let estado = 'arrancando';

export function pedir(metodo, args) {
  if (estado === 'listo') return enviar(metodo, args);
  if (estado === 'rota') return Promise.reject(new Error('BASE_NO_DISPONIBLE'));
  return new Promise((resolve, reject) => cola.push({ metodo, args, resolve, reject }));
}

function alPasarAListo() {
  estado = 'listo';
  const pendientes = cola.splice(0);           // vaciar antes de reenviar
  for (const p of pendientes) enviar(p.metodo, p.args).then(p.resolve, p.reject);
}

Hidratación optimista

Existe una forma de romper la espera que consiste en no esperar: guardar en un almacén de acceso inmediato una instantánea de lo último que la interfaz mostró, pintarla en el primer fotograma y reconciliarla cuando la base esté disponible. La aplicación aparece llena de contenido en decenas de milisegundos, y la base termina de arrancar por detrás sin que nadie la mire.

Dónde guardar esa instantánea es la primera decisión y tiene una restricción dura: debe poder leerse antes de que exista ningún Worker y sin esperar a nada asíncrono que retrase el primer pintado. Eso descarta la propia base, descarta el almacén de ficheros del origen y deja como candidatos los almacenes de clave y valor de acceso inmediato para volúmenes pequeños, o la caché de recursos para volúmenes mayores a cambio de una espera breve. La regla de tamaño es tajante: si guardar o leer la instantánea empieza a costar tanto como arrancar la base, la técnica ha dejado de tener sentido y solo estás añadiendo una fuente más de estado desactualizado.

La técnica funciona bien y tiene tres reglas que no admiten excepción.

Regla uno: la instantánea es solo para mostrar. Es un fotograma congelado de una vista, no una réplica del estado. Nada que se calcule a partir de ella puede escribirse ni acumularse, porque no sabes cuánto ha envejecido ni qué le falta.

Regla dos: se marca como provisional y se dice. No basta con saber internamente que el dato es viejo: la interfaz tiene que comunicarlo de una forma discreta pero real, porque un usuario que actúa sobre información caduca creyéndola actual acabará culpando a la aplicación con toda la razón.

Regla tres: no se aceptan escrituras hasta la reconciliación. Una intención emitida contra un estado que no has verificado es la vía más corta a un conflicto que nadie sabrá diagnosticar. Los controles de escritura permanecen inertes, con su motivo visible, hasta que la máquina llegue a listo.

// Al terminar cada pintado con datos confirmados
guardarInstantanea('panel', { version: ultimaVersion, filas: visibles.slice(0, 50) });

// En el arranque, antes de que el Worker exista siquiera
const foto = leerInstantanea('panel');
if (foto) pintarProvisional(foto.filas);      // sin permitir escrituras

// Cuando el Worker anuncia que esta listo
const real = await pedir('cargarPanel', {});
reconciliar(real);                             // puede contradecir a la instantanea

Qué mostrar mientras tanto

La decisión final es de comunicación, y se rige por un principio que conviene enunciar sin adornos: lo que muestras debe corresponder a la duración esperada, no a la duración real. Un indicador de progreso que aparece durante ochenta milisegundos es un parpadeo molesto; su ausencia durante cuatro segundos es una aplicación rota.

Queda un caso que no encaja en ninguna de las cuatro tarjetas y que hay que tratar aparte: el arranque de una pestaña seguidora. Es habitualmente el más rápido de todos, porque se salta la descarga, la compilación, la apertura del fichero y la migración, y se reduce a establecer el proxy con la líder. Merece por tanto un tratamiento distinto: donde la líder muestra un esqueleto, la seguidora puede a menudo mostrar contenido directamente. Y merece también su propio modo de fallo, porque si la líder desaparece durante ese establecimiento, la seguidora tiene que reintentar la adquisición del bloqueo y recorrer entonces el camino largo, pasando de un arranque de decenas de milisegundos a uno de cientos sin ninguna acción del usuario que lo explique.

Una advertencia sobre la etapa larga que se aprende cara: si vas a nombrar las etapas, no muestres una barra de progreso a menos que tengas una estimación real de cuánto falta. Una barra que se detiene al ochenta por ciento durante diez segundos daña más la confianza que un indicador indeterminado acompañado de un texto sincero, porque promete una precisión que no tienes. Y para migraciones largas, el mejor movimiento es directamente informar del número de registros procesados, que es un dato verdadero, monótono y comprensible.