Teniendo en cuenta sus requisitos de:
- A) Bajo uso de RAM
- B) Cumplir con las limitaciones de tamaño de archivo en Mongo
- C) Una interfaz de usuario receptiva
Consideraría algo como lo siguiente.
Tome este directorio de ejemplo
C:\
C:\X\
C:\X\B\
C:\X\file.txt
C:\Y\
C:\Y\file.pdf
C:\Y\R\
C:\Y\R\file.js
En JSON posiblemente podría representarse como:
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
Este último, como usted señaló, no se escala bien con estructuras de directorios grandes (puedo decirle de primera mano que los navegadores no apreciarán un blob JSON que represente incluso un directorio modesto con unos pocos miles de archivos/carpetas). El primero, aunque similar a algunos sistemas de archivos reales y eficiente en el contexto correcto, es un dolor de cabeza para trabajar convirtiendo a y desde JSON.
Mi propuesta es dividir cada directorio en un documento JSON separado, ya que esto solucionará los tres problemas; sin embargo, nada es gratis y esto aumentará la complejidad del código, la cantidad de solicitudes por sesión, etc.
La estructura anterior podría dividirse en los siguientes documentos:
[
{
"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"
}
]
Donde cada documento representa un directorio o archivo y (si es un directorio) sus ID secundarios inmediatos. Los elementos secundarios pueden cargarse de forma diferida utilizando sus ID y adjuntarse a su elemento principal en la interfaz de usuario. La carga diferida bien implementada puede precargar nodos secundarios a la profundidad deseada, creando una interfaz de usuario muy receptiva. El uso de RAM es mínimo ya que su servidor solo tiene que manejar pequeñas cargas útiles por solicitud. La cantidad de solicitudes aumenta considerablemente en comparación con el enfoque de un solo documento, pero nuevamente, una carga diferida inteligente puede agrupar las solicitudes y reducir la cantidad total.
ACTUALIZACIÓN 1 :De alguna manera pasé por alto tu penúltimo párrafo antes de responder, así que esto es probablemente más o menos lo que tenías en mente. Para abordar el problema de demasiados documentos, puede ser necesario cierto nivel de agrupamiento de nodos dentro de los documentos. Tengo que irme ahora, pero lo pensaré un poco.
ACTUALIZACIÓN 2 :He creado una esencia de una versión simplificada del concepto de agrupamiento que mencioné. No tiene en cuenta archivos, solo carpetas, y no incluye código para actualizar los documentos. Con suerte, te dará algunas ideas, continuaré actualizándolo para mis propios fines.
Gist:tree_docs_cluster.js
