Consigna y alcance
Asume un CSV de 2 GB, un límite de memoria de 20 MB en el hilo principal y una actualización de progreso dentro de los 100 ms posteriores a cada fragmento confirmado. El usuario puede recargar o desconectarse durante 30 minutos. El cliente debe reanudarse sin volver a leer todo el archivo, mantener la interfaz responsiva y nunca afirmar que un fragmento se subió antes de que el servidor lo haya confirmado. OPFS es privado para el origen de la página; es diferente de un manejador de carpeta visible para el usuario.
Qué está evaluando el entrevistador
- Elegir una primitiva de almacenamiento según el tamaño del archivo, la persistencia, los permisos y la compatibilidad del navegador.
- Mover el procesamiento y la E/S de bytes fuera del hilo principal sin que el estado de la UI se vuelva incoherente.
- Definir un protocolo reanudable con identidad de fragmentos, sumas de verificación (checksums), reintentos y reconciliación con el servidor.
- Manejar la presión de cuota, el desalojo (eviction), la cancelación, la privacidad y los navegadores no compatibles.
Preguntas clarificadoras para hacer
Pregunta si el archivo original debe seguir disponible después de recargar, si el servidor acepta fragmentos desordenados, si las filas se pueden procesar incrementalmente y qué navegadores están dentro del alcance. Si el servidor puede recibir un stream directamente desde un archivo seleccionado por el usuario, la persistencia local podría ser innecesaria; si la recuperación tras recargar es obligatoria, OPFS u otro almacenamiento duradero se convierte en parte del diseño.
La respuesta de 30 segundos
Mantendría un manifiesto pequeño en OPFS con upload_id, huella digital del origen, tamaño de fragmento, rangos confirmados y estado de la suma de verificación. Un worker dedicado lee cortes acotados, escribe un fragmento duradero antes de marcarlo como pendiente y lo sube con una clave de fragmento idempotente. El servidor reporta los rangos aceptados, por lo que un reintento reconcilia en lugar de adivinar. El hilo principal recibe mensajes de progreso regulados (throttled) y sigue siendo responsable de la cancelación y del estado accesible. La detección de características, el manejo de cuota de almacenamiento y un fallback de archivo seleccionado por el usuario protegen a los clientes no compatibles o cuyos datos fueron desalojados.
Análisis detallado paso a paso
1. Elegir el almacenamiento y los límites
Mantén el manifiesto y los metadatos pequeños en un almacenamiento duradero del navegador, y coloca los fragmentos temporales grandes en OPFS. OPFS es privado para el origen y no requiere un aviso de permisos para acceder; los identificadores de archivos visibles para el usuario siguen un modelo de permisos diferente y requieren un gesto explícito. Utiliza un worker para manejadores de acceso sincrónicos u otro trabajo bloqueante, de modo que el hilo principal nunca espere por operaciones de E/S en disco.
2. Hacer de la reanudación un protocolo, no una barra de progreso
Genera un uploadid y números de fragmento deterministas. Cada solicitud incluye el uploadid, el índice de fragmento, el rango de bytes, la longitud y la suma de verificación. El servidor almacena los rangos aceptados y los devuelve al consultar el estado. Un reintento con la misma identidad de fragmento es idempotente; una discrepancia en la suma de verificación se rechaza. Al recargar, el worker lee el manifiesto, solicita al servidor los rangos aceptados y sube únicamente el conjunto faltante.
3. Mantener la UI responsiva y recuperable
Lee cortes de tamaño fijo, transfiere solo un búfer acotado a la vez y regula los eventos de progreso para que el renderizado no compita con el procesamiento. Persiste el manifiesto antes de iniciar un intento de red y después de cada confirmación del servidor. La cancelación marca la subida localmente, aborta las solicitudes activas y programa la limpieza; no debe borrar los únicos metadatos de recuperación antes de que el servidor confirme la terminación.
4. Manejar cuotas, compatibilidad y seguridad
Verifica el almacenamiento disponible antes de copiar un archivo y muestra un estado recuperable de “almacenamiento lleno”. Si OPFS no está disponible o es desalojado, recurre a un archivo seleccionado por el usuario y reinicia desde los rangos conocidos por el servidor; nunca prometas una reanudación offline en ese modo. Trata los nombres de archivos y las filas procesadas como no confiables, exige autorización de subida autenticada y evita exponer rutas locales privadas. Prueba recargas, periodos offline, fragmentos duplicados, fallos de suma de verificación, caídas de pestañas, denegación de cuota y reinicios de workers.
Un ejemplo sólido de respuesta
Aclararía los navegadores objetivo, si las filas se pueden transmitir en stream y si se requiere la recuperación tras recargar. El cliente almacena un manifiesto y fragmentos temporales acotados en OPFS, mientras que un worker los lee y sube utilizando identidades de fragmentos deterministas. El servidor es la fuente autoritativa de los rangos aceptados; los reintentos se reconcilian contra ese estado y verifican las sumas de verificación. El hilo principal solo renderiza el progreso regulado y administra la cancelación. Si el almacenamiento no está disponible, la UI cambia a un flujo de archivo seleccionado con reanudación del lado del servidor, pero perdiendo explícitamente la persistencia offline. La cuota, el desalojo, la semántica de origen privado y la limpieza son estados observables, no excepciones ocultas.
Errores comunes
- Leer todo el archivo en memoria → una entrada de 2 GB congela o bloquea la pestaña → cortar fragmentos acotados en un worker.
- Tratar un porcentaje de progreso como la verdad → una confirmación perdida crea un vacío o un duplicado → reconciliar los rangos aceptados con el servidor.
- Asumir que OPFS es una carpeta visible para el usuario → los usuarios no pueden inspeccionar ni otorgar el mismo acceso → explicar el almacenamiento privado para el origen y usar un identificador de archivo cuando se requiera exportar.
- Persistir solo después de una subida exitosa → una caída pierde el siguiente punto de reintento → persistir el manifiesto antes de los intentos y después de las confirmaciones.
- Ignorar la cuota y el desalojo → la recuperación offline falla sin una acción del usuario → verificar la capacidad y proporcionar un fallback explícito.
- Confiar en nombres o campos de CSV → los datos locales pueden inyectar contenido o filtrar rutas → validar la entrada y nunca exponer detalles de rutas locales.
Preguntas de seguimiento y respuestas
La pestaña se cierra de forma inesperada después de que el servidor recibe un fragmento pero antes de la actualización del manifiesto. ¿Qué pasa ahora?
Al reiniciar, solicita al servidor los rangos aceptados y trata esa respuesta como autoritativa. La entrada faltante del manifiesto local puede subirse nuevamente con la misma identidad de fragmento; el servidor debe devolver el resultado existente en lugar de almacenar un duplicado.
El navegador reporta que el almacenamiento OPFS fue desalojado. ¿Haces que la importación falle?
Conserva el registro de subida y explica que la reanudación offline ya no está disponible. Pide al usuario que vuelva a seleccionar el archivo de origen y luego continúa desde los rangos aceptados por el servidor si la huella digital del origen coincide; de lo contrario, inicia una nueva subida.
¿Por qué no usar un identificador de directorio visible para el usuario para cada importación?
Añade un flujo de permisos y gestos, y acopla el producto a una carpeta que el usuario puede cambiar externamente. Úsalo cuando sea necesario editar o exportar el archivo original; usa OPFS para fragmentos temporales privados.
¿Cómo evitas que un worker sature la red?
Limita los fragmentos en tránsito, pausa las lecturas cuando el servidor o el navegador reporten contrapresión (backpressure) y prioriza los reintentos sobre el trabajo nuevo. Expón la profundidad de la cola y la antigüedad de los reintentos para que la UI pueda explicar la lentitud en el progreso.