Backend-Inicio

En la presente guía, se va a presentar las cosas más relevantes a considerar sobre el backend, la cual es una parte sensible de cualquier proyecto y por tal motivo debe asignarse el tiempo adecuado a esta crucial area, ten en cuenta que esta guía esta sujeta a constantes cambios, puesto que se espera que el sistema tenga una gran evolución para la versión 2.

Empecemos con los temas:

Punto de entrada de la app:

Es el lugar donde el flujo de ejecución comienza y desde donde se accede al resto del sistema. Es decir, es la puerta de entrada a todo el código que lo conforma. Su importancia radica en ofrecer una estructura organizada y sencilla de entender para nuevos integrantes.

Al crear la solución para Yomao, se optó por tener un punto de entrada de la app, pero que se comunique con distintas versiones de la api y tener en un archivo por a parte toda la configuración necesaria. Esto va así:

1. server.ts: Punto inicial de la app, contiene solo el código requerido para arrancar el servidor, importa las api en una determinada versión y el archivo config que asegura que funcione en desarrollo, pues posee las variables de entorno.
2. app.ts: Contiene todas las configuraciones establecidas en el servidor.
3. routesV(numero de la versión).ts: Importa las configuraciones establecidas del archivo app.ts, contiene todas las apis en la versión establecida.

Patrones de diseño empleados:

1. Patron Repositorio: Patron de diseño que nos ayuda a separar la capa de persistencia de la lógica de dominio, lo que permite que el sistema sea facilmente intercambiable con cualquier almacén de datos (base de datos) sin importar que sea en local o de forma distribuida.

   Lo único que se debe cumplir es la interfaz, que es la encargada de asegurar que toda implementación siga o devuelva un determinado comportamiento.

Ventajas

1. Separación de responsabilidades: El patrón Repository permite separar la lógica de acceso a datos de la lógica de negocio de la aplicación.
2. Permite mantener el código más organizado y coherente, lo que facilita la implementación de pruebas, mejora la modularidad y la escalabilidad del mismo.
3. Abstracción de la fuente de datos: El repositorio actúa como una capa de abstracción (intermedia) entre la lógica de dominio y el almacén de datos. Esto permite cambiar fácilmente la fuente de datos sin afectar directamente a la lógica de negocio.
4. Reutilización del código: Ayuda a encapsular el acceso a datos en un solo lugar. Esto facilita la reutilización del código en diferentes partes de la aplicación, reduciendo la duplicación de código y promueve la consistencia en la forma de interactuar con los datos.

Desventajas

1. Aumento de la cantidad de código: Se necesita escribir más código en comparación a tener todo mezclado en un solo lugar, el precio a pagar por las buenas practicas.
2. Curva de aprendizaje: Si no se esta familiarizado con el dicho patrón, puede llevar tiempo comprender cómo implementarlo correctamente.
3. Explosión de repositorios: Usarlo por si solo nos va a llevar a una cantidad inasumible de métodos.

Su representación gráfica es:

---

2. Patrón Criteria: Al momento de implementar el patrón antes mencionado, todo parece ser color de rosas, pero el problema radica en: “¿Y si quiero agregar filtros como hago?”

   Dado que hacer un método por cada combinación posible es una locura, acá es donde entra este patrón, permite traer solo los datos que se estan solicitando, esta es su implementación como DTO. No obstante, se necesita un poco más de tiempo para garantizar fiabilidad y confiabilidad en el cómo se comportan los filtros, así que se utilizó este patrón en su segunda forma que es como filtro de datos, el flujo es:

   1. Se hace la consulta paginada a la base de datos.
   2. La base de datos devuelve lo que debe devolver.
   3. Se filtra los datos en el backend.
   4. Se le devuelve al frontend para que los pinte en pantalla.

Principios SOLID aplicados:

Creemos en que se deben seguir los principicios que han sido probados a lo largo de los años. No obstante, hay veces que seguir tal cual una regla es perjudicial, por eso aplicamos los principios SOLID más útiles para nuestro caso, los cuales son:

1. S: Single Responsability (Responsabilidad única) una clase debe hacer una sola cosa y por ende solo debe tener una razón para cambiar.
2. O: Open-closed (Abierto-cerrado) una clase debe estar abierta a la extensión y cerrada a su modificación.
3. I: Interface segregation (Segregación de interfaces) es separar las interfaces, es mejor tener múltiples interfaces que tener una sola, dado que una clase debe solo consumir los métodos que necesita.
4. D: Dependency inversion (inversión de dependencia) las clases de alto nivel deben depender de abstracciones, los detalles deben depender de dichas abstracciones; esto significa aplicar la inyección de dependencias.