> For the complete documentation index, see [llms.txt](https://docsmetabuscador.comisiondelaverdad.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docsmetabuscador.comisiondelaverdad.co/arquitectura-proyecto/entornos-metodologias-arquitectura.md). # Entornos y metodologías ## Desarrollo El metabuscador fue desarrollado desde cero, no hace parte de desarrollos previos, y está hecho en un lenguaje de programación abierto. Se apoya en herramientas de software. ### Tecnologías y arquitectura * JavaScript (estándar del desarrollo) * * NodeJS; versión 14 * **Para el FRONTEND:** * Framework ReactJS; versión 16.13.1 * * Template Metronic (al cierre de esta documentación, aún se utiliza el template; sin embargo, por no ser de uso libre, posiblemente sea retirado del desarrollo en la versión final). * **Para el BACKEND:** * MongoDB; versión 5.0.3 * * ElasticSearch; versión 7.6.2 * * Framework NestJS (versión 7.1.5), escrito en lenguaje TypeScript (versión 4.2) * * :heavy\_check\_mark: Se utiliza [Python ](https://www.python.org/doc/)para el desarrollo de los modelos de Machine Learnin. También es utilizado para identificar los valores de los metadatos y para el desarrollo de algunos script que se ejecutan en función de organizar las zonas geográficas y las líneas de tiempo. :heavy\_check\_mark: Se tiene un script (`runtime.py`) que orquesta todo el flujo de tareas: los análisis textuales y las visualizaciones, la estandarización de los metadatos, la creación de los NGram, el etiquetado para que sean consultadas desde ElasticSearch, y también ejecuta tareas de limpieza. Dicho script se puede encontrar en: ``` sim-data-processing/-/tree/develop/procesado-general ``` :heavy\_check\_mark: **Arquitectura orientada a servicios:** la aplicación está dividida en frontend y backend, en el backend se encuentran los servicios que luego son consumidos por la aplicación. Esta arquitectura se pensó en función de reutilizar servicios para los distintos componentes que se van creando; adicionalmente, permite una identidad misional para todos los desarrollos de la Comisión de la Verdad. Según el equipo de ingenieros, la arquitectura obedece a las tendencias que existen actualmente para el desarrollo web, las cuales consisten en un backend escrito en microservicios (los desarrollos de la Comisión de la Verdad cuentan con servicios pequeños); y un frontend con un Framework de visualizaciones que consume esos servicios. El servicio más importante para la aplicación metabuscador es `search.service.ts`, el cual es llamado desde el frontend por el controlador`search.js`. Dentro del repositorio, se encuentra una carpeta por cada servicio; se pueden encontrar en: ``` sim-backend-nest/-/tree/develop/src ``` {% hint style="warning" %} Es importante tener en cuenta que el backend del metabuscador, aunque en su mayoría está desarrollado en función de servicios, tiene algunos componentes implementados bajo el modelo monolítico; esto es así debido a que el aplicativo se comenzó a desarrollar bajo este patrón. En la medida en que el desarrollo fue creciendo, se comenzó a implementar una arquitectura orientada a servicios, conservando algunas estructuras monolíticas que eran funcionales. {% endhint %} Los archivos que ejecutan los diferentes servicios son: para el backend `main.ts` y para el frontend `app.js`. Dentro del repositorio, se pueden encontrar en la ruta: ``` BACKEND: sim-backend-nest/-/tree/develop/src FRONTEND: sim-frontend/-/tree/develop/src ``` :heavy\_check\_mark: **Integración con ElasticSearch:** la recuperación de información se hace a través del indexador ElasticSearch. El aplicativo crea un archivo JSON que agrupa los datos provenientes de MongoDB y las colecciones ResourcesGroup, Resources y Record en una sola estructura; es decir, cada ResourcesGroup se agrupa con sus Resources y estos, a su vez, con sus Record. El aplicativo está a nivel de Resource, esto quiere decir que crea un archivo JSON por cada Resource con sus respectivos Record. El archivo JSON es el que consulta luego el indexador. Para entender la arquitectura de la base de datos se recomienda visualizar [Colecciones DB](/arquitectura-proyecto/colecciones-database-arquitectura.md). :heavy\_check\_mark: **Integración de herramientas:** la integración con lo que se produce desde las demás herramientas de la Comisión de la Verdad se realiza a través de procesos ETL. Se toman las bases de datos de cada una de las herramientas y se realiza una conversión de los datos a la estructura definida para el metabuscador (ResourceGroup, Resource, Record); la conversión que realizan las ETL genera la equivalencia necesaria para almacenar esos datos en MongoDB. {% hint style="info" %} Las ETL van a las bases de datos que se quieren integrar, extraen la información de esas bases de datos, la transforma en la nueva estructura y, automáticamente, la carga en la base de datos de MongoDB. {% endhint %} {% hint style="success" %} Durante el tiempo de la Comisión de la Verdad, este proceso se ejecutó diariamente a media noche. {% endhint %} Las integraciones se realizan bajo la tecnología [Pentaho Spoon.](https://pentaho-community.atlassian.net/wiki/spaces/EAI/overview) ### Metodologías * **Modelo atómico:** bajo esta metodología se definen: páginas, organismos, moléculas y átomos, que luego pueden ser reutilizados en otros desarrollos. Todos los componentes del metabuscador desarrollado por la Comisión de la Verdad, usan esta misma estrategia con el fin de tener una estructura homogénea. ![Modelo atómico. Fuente: https://www.uifrommars.com/atomic-design-ventajas/](/files/X0sCEg45BhjtyiU6UbyW) * **Programación Sprint Scrum:** * Historias de usuarios * Definición de tableros y actividades (sprints) * Planeación y seguimientos Esta metodología se adopta por las condiciones cambiantes de la Comisión. Scrum permite adaptarse a requerimientos cambiantes y permite tomar decisiones de manera rápida; adicionalmente, se nutre de la experiencia de usuario. En entornos de desarrollo, Scrum ha sido apropiada como una buena práctica. Cuando se inició el desarrollo del metabuscador, se inició con unos lineamientos básicos que fueron cambiando, definiéndose y entendiéndose mejor; de allí la motivación de escoger Scrum frente a otras posibilidades. En últimas, permite presentar avances y versiones funcionales en un corto tiempo. ## Buenas prácticas **Programación Scrum:** se recomienda trabajar bajo la metodología de programación Sprint Scrum, dado que es una metodología que permite la articulación fácil y rápida de modelos simples y funcionales, los cuales pueden ir evolucionando con el feedback y las necesidades del cliente. Bajo esta metodología estaremos en función de un desarrollo iterativo o incremental, el cual consiste en dividir el trabajo en pequeñas partes o bloques temporales (sprint). Al final de cada etapa se entrega una funcionalidad completa. Para estructurar la evolución se recomienda crear el Mínimo Producto Viable (Minimum Viable Product, MVP): producto con suficientes características para satisfacer a los clientes y proporcionar retroalimentación para el desarrollo futuro. **MVP:** herramienta que permite aprender mientras se desarrolla. Gracias a la iteración, el producto evoluciona y se reduce el tiempo para la validación de nuevas ideas. **Estandarizar código:** definir unas reglas de trabajo; es decir, estandarizar la manera en que se van a crear y llamar las funciones, los métodos, las variables, los atributos, etc. La normalización del código es fundamental para el mantenimiento óptimo del desarrollo. **Comentar el código:** es una buena práctica comentar el código a fin de que se convierta en un texto legible, autoexplicativo y facilite las modificaciones y el mantenimiento. **Interacción con usuarios:** es una buena práctica tener entrevistas previas con los usuarios del sistema; dichos encuentros permiten entender los requerimientos puntuales y las funcionalidades concretas sobre las que debe basarse el desarrollo. Además, se recomienda encontrar un lenguaje común entre lo técnico del sistema y el requerimiento del usuario, a fin de no generar reprocesos y lograr comunicar fácilmente las funcionalidades del sistema. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docsmetabuscador.comisiondelaverdad.co/arquitectura-proyecto/entornos-metodologias-arquitectura.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.