プロンプトとスコープ
2 GB の CSV、20 MB のメインスレッドメモリ予算、および確認応答されたチャンクごとに 100 ms 以内の進行状況更新を想定します。ユーザーはリロードしたり、30 分間オフラインになったりする可能性があります。クライアントはファイル全体を再読み込みすることなく再開し、インターフェースの応答性を維持し、サーバーが確認応答する前にチャンクがアップロードされたと主張してはなりません。OPFS はページの生成元（origin）に対してプライベートであり、ユーザーに見えるフォルダーハンドルとは異なります。
面接官がテストしていること
- ファイルサイズ、永続性、権限、およびブラウザのサポート状況に基づくストレージプリミティブの選択。
- UI 状態の不整合を起こさずに、パース処理とバイト I/O をメインスレッドから分離すること。
- チャンク識別子、チェックサム、リトライ、サーバーとの調整を備えた再開可能プロトコルの定義。
- クォータの圧迫、エビクション（破棄）、キャンセル、プライバシー、および非対応ブラウザへの対処。
確認すべき明確化のための質問
リロード後も元のファイルが利用可能である必要があるか、サーバーが順不同のチャンクを受け入れるか、行をインクリメンタルにパースできるか、どのブラウザが対象範囲かを尋ねます。サーバーがユーザーの選択したファイルから直接ストリーミングできる場合、ローカルの永続化は不要な場合があります。リロードからの復旧が必須である場合、OPFS やその他の永続ストレージが設計の一部となります。
30秒での回答
OPFS 内に upload_id、ソースのフィンガープリント、チャンクサイズ、確認済み範囲、およびチェックサム状態を含む小さなマニフェストを保持します。専用の Worker が制限されたスライスを読み取り、保留中としてマークする前に永続的なチャンクを書き込み、冪等なチャンクキーを使用してアップロードします。サーバーは承認された範囲を報告するため、リトライ時は推測するのではなく調整を行います。メインスレッドはスロットルされた進行状況メッセージを受け取り、キャンセル処理とアクセシブルなステータス表示を担当し続けます。機能検出、ストレージクォータ処理、およびユーザー選択ファイルへのフォールバックにより、非対応またはエビクションされたクライアントを保護します。
ステップごとの詳細解説
1. ストレージと境界の選択
マニフェストと小さなメタデータは耐久性のあるブラウザストレージに保持し、大きな一時チャンクは OPFS に配置します。OPFS はオリジンプライベートであり、アクセスのための権限プロンプトを必要としません。ユーザーに見えるファイルハンドルは異なる権限モデルに従い、明示的なジェスチャーが必要です。同期アクセスハンドルやその他のブロッキング処理には Worker を使用し、メインスレッドがディスク I/O を待機しないようにします。
2. 再開をプログレスバーではなくプロトコルにする
uploadid と決定論的なチャンク番号を生成します。各リクエストには、uploadid、チャンクインデックス、バイト範囲、長さ、およびチェックサムが含まれます。サーバーは承認された範囲を保存し、ステータス要求時にそれらを返します。同じチャンク識別子でのリトライは冪等であり、チェックサムの不一致は拒否されます。リロード時、Worker はマニフェストを読み取り、サーバーに承認済み範囲を問い合わせ、不足しているセットのみをアップロードします。
3. UI の応答性と回復性を維持する
固定サイズのスライスを読み取り、一度に転送するバッファを 1 つに制限し、進行状況イベントをスロットルしてレンダリングがパースと競合しないようにします。ネットワーク試行を開始する前と、各サーバー確認応答の後にマニフェストを永続化します。キャンセル時はローカルでアップロードをマークし、アクティブなリクエストを中止してクリーンアップをスケジュールします。サーバーが終了を確認する前に、唯一の復旧メタデータを消去してはなりません。
4. クォータ、互換性、セキュリティの処理
ファイルをコピーする前に利用可能なストレージを確認し、回復可能な「ストレージがいっぱいです」状態を表面化させます。OPFS が利用できないかエビクションされた場合は、ユーザーが選択したファイルにフォールバックし、サーバーが把握している範囲から再開します。そのモードではオフライン再開を約束してはなりません。ファイル名とパースされた行は信頼できないものとして扱い、認証されたアップロード認可を要求し、プライベートなローカルパスの露出を避けます。リロード、オフライン期間、重複チャンク、チェックサムの失敗、タブのクラッシュ、クォータ拒否、および Worker の再起動をテストします。
優れた回答例
対象ブラウザ、行のストリーミングが可能か、リロード復旧が必要かを明確にします。クライアントはマニフェストと制限された一時チャンクを OPFS に保存し、Worker は決定論的なチャンク識別子を使用してそれらを読み取り、アップロードします。サーバーは承認された範囲の信頼できる情報源であり、リトライはその状態と調整され、チェックサムを検証します。メインスレッドはスロットルされた進行状況を描画し、キャンセルのみを所有します。ストレージが利用できない場合、UI はサーバー側で再開可能な選択ファイルフローに切り替わりますが、オフラインの永続性は明確に失われます。クォータ、エビクション、オリジンプライベートのセマンティクス、およびクリーンアップは、隠れた例外ではなく、観測可能な状態として扱われます。
よくある間違い
- ファイル全体をメモリに読み込む → 2 GB の入力によりタブがフリーズまたはクラッシュする → Worker で制限されたチャンクにスライスする。
- 進行状況のパーセンテージを真実として扱う → 確認応答の喪失により欠落や重複が発生する → 承認された範囲をサーバーと調整する。
- OPFS をユーザーに見えるフォルダーと見なす → ユーザーは同じアクセスを検査または許可できない → オリジンプライベートストレージについて説明し、エクスポートが必要な場合はファイルハンドルを使用する。
- アップロード成功後にのみ永続化する → クラッシュにより次のリトライポイントが失われる → 試行前および確認応答後にマニフェストを永続化する。
- クォータとエビクションを無視する → ユーザーアクションなしでオフライン復旧が失敗する → 容量を確認し、明示的なフォールバックを提供する。
- ファイル名や CSV フィールドを信頼する → ローカルデータがコンテンツを注入したりパスを漏洩したりする可能性がある → 入力を検証し、ローカルパスの詳細を決して露出させない。
フォローアップの質問と回答
サーバーがチャンクを受信した後、マニフェスト更新前にタブがクラッシュしました。どうしますか？
再起動時にサーバーに承認済み範囲を問い合わせ、その応答を信頼できる情報源として扱います。不足しているローカルマニフェストエントリは、同じチャンク識別子で再度アップロードされる可能性があります。サーバーは重複して保存するのではなく、既存の結果を返す必要があります。
ブラウザが OPFS ストレージがエビクションされたと報告しました。インポートを失敗させますか？
アップロードレコードを保持し、オフライン再開が利用できなくなったことを説明します。ユーザーにソースファイルを再選択するよう求め、ソースのフィンガープリントが一致する場合はサーバー承認済み範囲から続行し、そうでない場合は新しいアップロードを開始します。
すべてのインポートにユーザーに見えるディレクトリハンドルを使用しないのはなぜですか？
権限とジェスチャーのフローが追加され、ユーザーが外部から変更できるフォルダーに製品が結合されてしまうためです。元のファイルの編集やエクスポートが必要な場合に使用し、プライベートな一時チャンクには OPFS を使用します。
Worker がネットワークを圧迫するのを防ぐにはどうすればよいですか？
処理中のチャンク数を制限し、サーバーやブラウザがバックプレッシャーを報告したときに読み取りを一時停止し、新しい処理よりもリトライを優先します。キューの深さとリトライの経過時間を公開して、UI が進行の遅延を説明できるようにします。