次の要件がある場合：
- A）RAM使用量が少ない
- B）Mongoでのファイルサイズの制限を満たす
- C）レスポンシブUI
次のようなことを考えます。
このサンプルディレクトリを見てください
C:\
C:\X\
C:\X\B\
C:\X\file.txt
C:\Y\
C:\Y\file.pdf
C:\Y\R\
C:\Y\R\file.js
JSONでは、次のように表すことができます：
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
後者は、ご指摘のとおり、大きなディレクトリ構造では適切に拡張できません（ブラウザは、数千のファイル/フォルダを持つ控えめなディレクトリを表すJSON BLOBを認識しないことを直接お伝えできます）。前者は、実際のファイルシステムに似ており、適切なコンテキストで効率的ですが、JSONとの変換を行うのは面倒です。
私の提案は、各ディレクトリを個別のJSONドキュメントに分割することです。これにより、3つの問題すべてに対処できますが、無料のものはなく、コードの複雑さ、セッションあたりのリクエスト数などが増加します。
上記の構造は、次のドキュメントに分割できます。
[
{
"id": "00000000-0000-0000-0000-000000000000",
"type": "d",
"name": "C:",
"children": [
"11111111-1111-1111-1111-111111111111",
"22222222-2222-2222-2222-222222222222"
]
},
{
"id": "11111111-1111-1111-1111-111111111111",
"type": "d",
"name": "X",
"children": [
"33333333-3333-3333-3333-333333333333",
"55555555-5555-5555-5555-555555555555"
]
},
{
"id": "22222222-2222-2222-2222-222222222222",
"type": "d",
"name": "Y",
"children": [
"44444444-4444-4444-4444-444444444444",
"66666666-6666-6666-6666-666666666666"
]
},
{
"id": "33333333-3333-3333-3333-333333333333",
"type": "d",
"name": "B",
"children": []
},
{
"id": "44444444-4444-4444-4444-444444444444",
"type": "d",
"name": "R",
"children": [
"77777777-7777-7777-7777-777777777777"
]
},
{
"id": "55555555-5555-5555-5555-555555555555",
"type": "f",
"name": "file.txt",
"size": "1024"
},
{
"id": "66666666-6666-6666-6666-666666666666",
"type": "f",
"name": "file.pdf",
"size": "2048"
},
{
"id": "77777777-7777-7777-7777-777777777777",
"type": "f",
"name": "file.js",
"size": "2048"
}
]
各ドキュメントがディレクトリまたはファイルと（ディレクトリの場合）その直接の子IDを表す場合。子アイテムは、IDを使用して遅延ロードし、UIで親に追加できます。適切に実装された遅延読み込みは、子ノードを目的の深さまで事前読み込みして、非常に応答性の高いUIを作成できます。サーバーはリクエストごとに小さなペイロードを処理するだけでよいため、RAMの使用量は最小限に抑えられます。リクエストの数は、単一のドキュメントアプローチと比較して大幅に増加しますが、繰り返しになりますが、一部の巧妙な遅延読み込みにより、リクエストがクラスター化され、総数が減少する可能性があります。
アップデート1 ：答える前に、どういうわけか最後から2番目の段落を見落としていたので、これは多かれ少なかれあなたが考えていたものです。あまりにも多くのドキュメントの問題に対処するために、ドキュメント内のあるレベルのクラスタリングノードが適切である可能性があります。今から出発する必要がありますが、少し考えてみます。
アップデート2 ：私が言及したクラスタリングの概念の簡略化されたバージョンの要点を作成しました。ファイルは考慮されず、フォルダーのみが考慮され、ドキュメントを更新するためのコードは含まれていません。うまくいけば、それはあなたにいくつかのアイデアを与えるでしょう、私は私自身の目的のためにそれを更新し続けます。