1. El problema

Últimamente, parece que muchos administradores de notas con estructura de árbol "infinita" están eligiendo un modelo de bloque (donde cada párrafo es una entrada en la base de datos), en lugar de un modelo de documento o archivo.

Si encuentra algún error en la tabla, por favor hágamelo saber.

Llevamos 8 meses desarrollando una aplicación muy similar a Notion, también usando el modelo de bloques, pero estamos considerando hacer un cambio radical y cambiar al modelo de documentos. La estructura de nuestros bloques en MongoDB actualmente se ve así:

 _id: "61fd3ede7f6d2cc7a53ca669" children: Array 0: "61fd3ee87f6d2cc7a53ca66b" 1: "61fd3ef37f6d2cc7a53ca671" 2: "61fd3ef77f6d2cc7a53ca673" backlinks: Array type: "bullet" parentPage: Array _id: "61fd3ede7f6e2ccra53ca664" userParent: "german-jablo" permisionParent: "edit, comment, read" parentParagraph: "61fd3ede7f6d2cc7a53ca668" content: "<p>This is a paragraph</p>" isCollapsed: false createdAt: 2022-02-04T14:57:34.280+00:00 updatedAt: 2022-02-04T14:57:59.585+00:00

Muchas páginas hablan de las diferencias de ambos enfoques ( ejemplo ) aunque de forma muy vaga, por lo que decidimos abrir este hilo para encontrar una respuesta más científica a la pregunta.

Características de nuestra aplicación

Nuestra aplicación tiene dos tipos de "bloques". El tipo de página (que, como en Notion, se puede insertar en cualquier nota y generar un documento "dentro" del documento actual), y el resto de bloques, que son equivalentes al tipo de bloque "toggle" en Notion (es decir, pueden colapsarse o sus hijos anidados pueden expandirse).

2. Lo que hemos probado

Al tratar de responder a nuestra pregunta (qué modelo de base de datos funcionaría mejor para nuestra aplicación), nos dimos cuenta de que la respuesta probablemente sea "depende". Quizás ambos modelos tengan fortalezas o debilidades en diferentes tipos de operaciones o situaciones. Es por eso que formulamos esta tabla de comparación que describe cómo creemos que sería el desempeño de ambos modelos para cada una de estas operaciones.

* Procesar documentos muy grandes : la mayoría de los usuarios probablemente no utilicen notas de más de 250 kb (considerando que los archivos multimedia se mencionan en una colección separada). Aún así, en el modelo de documento, surge la pregunta: ¿cómo podemos cargar, renderizar o editar documentos grandes en fragmentos manejables? Una idea que se nos ocurrió es dividir los documentos HTML que alcanzan grandes dimensiones en porciones de cierto tamaño en kb, en lugar de dividirlos en párrafos. (Sería como una especie de Gridfs que te permite modificar el archivo por partes). ¿Podría ser una buena idea?

** ¿Debe anidarse el DOM? Para poder colapsar o expandir los párrafos secundarios anidados, los administradores de notas con un modelo de bloque estructuran el DOM de forma anidada (los párrafos están en divs, dentro de sus divs principales, etc.). Sin embargo, una alternativa en el modelo de documento podría ser que cuando el usuario presione tab, solo a ese bloque (etiqueta HTML como <p> o <li> ) se le asigne un atributo con un número menor o igual a 1, que represente el anidamiento. niveles relativos al bloque anterior. De esta manera, cuando presiona tabulador para anidar o shift-tabulador para anular, solo tiene que modificar un atributo de un elemento HTML en lugar de muchos elementos; y el DOM se mantiene simple, sin tener bloques anidados.

3. Nuestras conclusiones

Creemos que para cada una de las filas de la tabla de comparación, se podrían hacer puntos de referencia para medir el rendimiento de ambos modelos. Otras personas han hecho algo similar aquí y aquí , comparando el rendimiento de los administradores de notas usando ambos modelos. El problema con esas pruebas es que es difícil sacar una conclusión precisa sobre la bondad de ambos modelos. Obsidian usa documentos localmente, por lo que no tiene que sincronizar notas. Roam Research es una aplicación muy nueva y mal optimizada. Standard Notes cifra las notas localmente. En otras palabras, no siempre son manzanas con manzanas.

Y aunque se pudieran hacer pruebas, creemos que la respuesta puede incluso depender de cómo cada usuario utilice la aplicación. Supongamos que el usuario A suele organizar sus notas en documentos extensos mediante el anidamiento de párrafos (para contraerlos o expandirlos). Por otro lado, el usuario B suele organizar sus notas creando nuevos documentos dentro de los documentos. Es probable que un administrador basado en modelos de bloques funcione mejor para el usuario A, mientras que uno basado en documentos funcione mejor para B.

Entonces, tratamos de llevar nuestra duda lo más lejos que pudimos, pero aún no estamos seguros de la respuesta. ¿Cuál de los dos modelos crees que ofrecería un mejor rendimiento para nuestra aplicación y por qué?

4. Actualizar

Acabo de encontrar información muy interesante. Parece que tanto TinyMCE como CKEditor (hasta la versión 4), la vista y el modelo convergen con el HTML basado en contenido editable. Sin embargo, CKEditor 5 cambió a MVC [fuente 1] , [fuente 2] .

He hecho una breve prueba pegando un portapapeles grande de unos pocos MB en TinyMCE 5, CKEditor 4 y CKEditor 5, y este último ha sido un poco más lento. Espero pronto poder hacer más pruebas con otras cosas como arrastrar bloques o renderizar documentos grandes.

En un hilo de GitHub sobre el rendimiento de CKEditor 5 cuando se trabaja con documentos grandes , uno de los colaboradores dijo: "Obviamente, funciona más lento que el elemento editable de contenido nativo, pero la experiencia de escritura es bastante buena".