Perintah dan cakupan
Asumsikan CSV 2 GB, anggaran memori main thread 20 MB, dan pembaruan progres dalam 100 ms setelah setiap chunk diakui (acknowledged). Pengguna dapat memuat ulang atau offline selama 30 menit. Klien harus melanjutkan tanpa membaca ulang seluruh file, menjaga antarmuka tetap responsif, dan tidak pernah mengklaim bahwa sebuah chunk telah diunggah sebelum server mengakuinya. OPFS bersifat privat bagi origin halaman; ini berbeda dari handle folder yang terlihat oleh pengguna.
Apa yang sedang diuji oleh pewawancara
- Memilih primitif penyimpanan berdasarkan ukuran file, persistensi, izin, dan dukungan browser.
- Memindahkan parsing dan I/O byte dari main thread tanpa membuat status UI tidak koheren.
- Menentukan protokol yang dapat dilanjutkan (resumable) dengan identitas chunk, checksum, percobaan ulang (retry), dan rekonsiliasi server.
- Menangani tekanan kuota, penggusuran (eviction), pembatalan, privasi, dan browser yang tidak didukung.
Pertanyaan klarifikasi yang perlu diajukan
Tanyakan apakah file asli harus tetap tersedia setelah pemuatan ulang, apakah server menerima chunk yang tidak berurutan, apakah baris dapat di-parse secara inkremental, dan browser mana saja yang masuk dalam cakupan. Jika server dapat melakukan streaming langsung dari file yang dipilih pengguna, persistensi lokal mungkin tidak diperlukan; jika pemulihan setelah pemuatan ulang wajib dilakukan, OPFS atau penyimpanan tahan lama lainnya menjadi bagian dari rancangan.
Jawaban 30 detik
Saya akan menyimpan manifes kecil di OPFS dengan upload_id, sidik jari sumber, ukuran chunk, rentang yang telah diakui, dan status checksum. Worker khusus membaca irisan terbatas, menulis chunk yang tahan lama sebelum menandainya sebagai pending, dan mengunggah dengan kunci chunk yang idempoten. Server melaporkan rentang yang diterima, sehingga percobaan ulang melakukan rekonsiliasi alih-alih menebak. Main thread menerima pesan progres yang di-throttle dan tetap bertanggung jawab atas pembatalan serta status yang dapat diakses. Deteksi fitur, penanganan kuota penyimpanan, dan fallback file yang dipilih pengguna melindungi klien yang tidak didukung atau yang datanya digusur.
Pembahasan mendalam langkah demi langkah
1. Memilih penyimpanan dan batasan
Simpan manifes dan metadata kecil di penyimpanan browser yang tahan lama, serta letakkan chunk sementara yang besar di OPFS. OPFS bersifat origin-private dan tidak memerlukan prompt izin untuk akses; handle file yang terlihat oleh pengguna mengikuti model izin yang berbeda dan memerlukan gestur eksplisit. Gunakan worker untuk synchronous access handle atau pekerjaan pemblokiran lainnya sehingga main thread tidak pernah menunggu I/O disk.
2. Jadikan proses melanjutkan sebagai protokol, bukan sekadar progress bar
Hasilkan uploadid dan nomor chunk yang deterministik. Setiap permintaan membawa uploadid, indeks chunk, rentang byte, panjang, dan checksum. Server menyimpan rentang yang diterima dan mengembalikannya pada status. Percobaan ulang dengan identitas chunk yang sama bersifat idempoten; ketidakcocokan checksum akan ditolak. Saat memuat ulang, worker membaca manifes, meminta rentang yang diterima kepada server, dan hanya mengunggah bagian yang hilang.
3. Menjaga UI tetap responsif dan dapat dipulihkan
Baca irisan berukuran tetap, transfer hanya satu buffer terbatas pada satu waktu, dan throttle event progres agar proses rendering tidak bersaing dengan parsing. Pertahankan manifes sebelum memulai upaya jaringan dan setelah setiap pengakuan server. Pembatalan menandai unggahan secara lokal, membatalkan permintaan aktif, dan menjadwalkan pembersihan; pembatalan tidak boleh menghapus satu-satunya metadata pemulihan sebelum server mengonfirmasi penghentian.
4. Menangani kuota, kompatibilitas, dan keamanan
Periksa penyimpanan yang tersedia sebelum menyalin file dan tampilkan status “penyimpanan penuh” yang dapat dipulihkan. Jika OPFS tidak tersedia atau digusur, beralihlah ke file yang dipilih pengguna dan mulai ulang dari rentang yang diketahui server; jangan pernah menjanjikan kelanjutan offline dalam mode tersebut. Perlakukan nama file dan baris yang di-parse sebagai data yang tidak tepercaya, wajibkan otorisasi pengunggahan yang diautentikasi, dan hindari mengekspos jalur lokal privat. Uji pemuatan ulang, periode offline, chunk duplikat, kegagalan checksum, crash pada tab, penolakan kuota, dan mulai ulang worker.
Contoh jawaban yang kuat
Saya akan mengklarifikasi target browser, apakah baris dapat di-stream, dan apakah pemulihan setelah pemuatan ulang diperlukan. Klien menyimpan manifes dan chunk sementara terbatas di OPFS, sementara worker membaca dan mengunggahnya menggunakan identitas chunk yang deterministik. Server memegang otoritas atas rentang yang diterima; percobaan ulang merekonsiliasi status tersebut dan memverifikasi checksum. Main thread hanya merender progres yang di-throttle dan mengelola pembatalan. Jika penyimpanan tidak tersedia, UI beralih ke alur file yang dipilih dengan kelanjutan di sisi server tetapi secara jelas kehilangan persistensi offline. Kuota, penggusuran, semantik private-origin, dan pembersihan adalah status yang dapat diamati, bukan pengecualian tersembunyi.
Kesalahan umum
- Membaca seluruh file ke dalam memori → input 2 GB membekukan atau merusak tab → iris chunk terbatas di worker.
- Memperlakukan persentase progres sebagai kebenaran mutlak → pengakuan yang hilang menciptakan celah atau duplikasi → rekonsiliasi rentang yang diterima dengan server.
- Menganggap OPFS sebagai folder yang terlihat oleh pengguna → pengguna tidak dapat memeriksa atau memberikan akses yang sama → jelaskan penyimpanan origin-private dan gunakan handle file saat ekspor diperlukan.
- Melakukan persistensi hanya setelah unggahan berhasil → crash menyebabkan hilangnya titik percobaan ulang berikutnya → pertahankan manifes sebelum mencoba dan setelah pengakuan.
- Mengabaikan kuota dan penggusuran → pemulihan offline gagal tanpa tindakan pengguna → periksa kapasitas dan berikan fallback eksplisit.
- Mempercayai nama atau kolom CSV → data lokal dapat menyuntikkan konten atau membocorkan jalur → validasi input dan jangan pernah mengekspos detail jalur lokal.
Pertanyaan lanjutan dan jawaban
Tab mengalami crash setelah server menerima sebuah chunk tetapi sebelum pembaruan manifes. Apa yang terjadi sekarang?
Saat memulai ulang, minta rentang yang diterima kepada server dan perlakukan respons tersebut sebagai sumber otoritatif. Entri manifes lokal yang hilang dapat diunggah kembali dengan identitas chunk yang sama; server harus mengembalikan hasil yang ada alih-alih menyimpan duplikat.
Browser melaporkan bahwa penyimpanan OPFS telah digusur (evicted). Apakah Anda menggagalkan impor?
Simpan catatan unggahan dan jelaskan bahwa kelanjutan offline tidak lagi tersedia. Minta pengguna untuk memilih kembali file sumber, lalu lanjutkan dari rentang yang diterima server jika sidik jari sumber cocok; jika tidak, mulai pengunggahan baru.
Mengapa tidak menggunakan handle direktori yang terlihat pengguna untuk setiap impor?
Hal ini menambah alur izin dan gestur serta mengikat produk ke folder yang dapat diubah pengguna secara eksternal. Gunakan itu saat pengeditan atau pengeksporan file asli diperlukan; gunakan OPFS untuk chunk sementara yang privat.
Bagaimana cara mencegah worker membanjiri jaringan?
Batasi chunk yang sedang berjalan (in-flight), jeda pembacaan saat server atau browser melaporkan backpressure, dan prioritaskan percobaan ulang daripada pekerjaan baru. Tampilkan kedalaman antrean dan usia percobaan ulang sehingga UI dapat menjelaskan progres yang lambat.