Curso de Arquitectura Frontend

En este vídeo veremos de qué trata el curso de Arquitectura Frontend, los objetivos y el contenido que podrás encontrar en esta formación.

Ahora vamos a ver con mayor detalle cada uno de los bloques de este curso, presentando también la práctica que desarrollaremos a lo largo de la formación

Qué es la arquitectura, por qué la necesitamos, cómo debemos aplicarla sin caer en la sobreingeinería. Introducción de diversos modelos de arquitectura de software como Domain Driven Design o Arquitectura Hexagonal.

Explicamos las piezas en las que se compone el proyecto inicial del curso, junto con las herramientas, frameworks y librerías que se usan. El proyecto viene con una serie de herramientas ya configuradas como linters, pre commits, tests con Vitest y Playwright, así como dependencias como el framework NextJS, librerías de UI, etc. También se mostrarán la localización de los componentes del propio proyecto y los orígenes de datos.

En este vídeo veremos qué son los casos de uso, de dónde vienen y cómo definir un primer ejemplo de caso de uso. Veremos cómo a partir de un código de la aplicación inicial, que no tiene una arquitectura, podemos extraer los casos de uso y separarlos en clases, que tendrán sus propias definiciones de interfaces y tipos, que podremos definir aparte y usar a lo largo de la aplicación. También veremos cómo instanciar las clases de los casos de uso en un contenedor, que luego nos vendrá bien para aplicar otros principios de diseño de software.

Creación de nuevos casos de uso según la aplicación de ejemplo del curso. Veremos cómo desarrollar dos nuevos casos de uso, creando las distintas piezas de software que vimos en el anterior vídeo de curso.

En este vídeo veremos qué es CQRS y cómo dividir los casos de uso en dos tipos, los query y los command, implementando estos dos tipos de casos de uso y migrando los casos de uso genéricos a dos ejemplos de query y command.

Ahora vamos a hacer un rápido refactoring de varios tipos de la aplicación, conociendo algunas de las utilidades de definición de tipos de TypeScript, basando éstos en tipos ya definidos anteriormente.

Nos quedaba por migrar un caso de uso a query o command. Este caso de uso puede ser más confuso al escoger su tipo. Veremos los criterios que nos llevan a clasificarlo de una manera particular.

Para terminar el tema de los casos de uso veremos qué es el use case service, por qué lo queremos implementar así y las ventajas que nos ofrece. Realizaremos el refactoring para adaptar los casos de uso de la aplicación para que trabajen por medio de un use case service.

Una primera organización que podríamos pensar para nuestra arquitectura frontend sería organizar los archivos de Javascript por el tipo de módulo que son, creando carpetas de componentes, servicios, modelos, etc. Veremos cómo se haría y los puntos donde esta organización nos podrían dar problemas de mantenimiento.

En proyectos medianos o grandes, incluso en los más pequeños, nos vendrá mejor organizar los módulos de Javascript atendiendo a su funcionalidad, o lo que es lo mismo, el dominio en el que estemos trabajando. Esto nos aportará ventajas que explicaremos con detalle. Además veremos cómo organizar el proyecto de una manera más práctica.

En este vídeo vamos a ver la estrategia que podemos usar cuando un módulo se está haciendo demasiado grande y vemos que existe una necesidad de estructurarlo. Lo veremos implementado en nuestro proyecto, con una funcionalidad a modo de ejemplo.

Ya dependiendo del tipo de proyecto y del framework también podemos tener páginas, que probablemente se agrupan en carpetas distintas, si usamos un framework que tiene un sistema de routing basado en el sistema de archivos. En esos casos las páginas también es interesante que las podamos agrupar por el dominio, facilitando el mantenimiento, la reusabilidad y el trabajo en equipo.

Cómo encarar la arquitectura del CSS, creando un sistema de diseño que podamos usar a lo largo de la aplicación, incluso que podamos reutilizar en varios proyectos de la empresa.

Veremos el concepto de middleware, por qué es útil y luego mostraremos cómo se implementan dentro del proyecto del curso de arquitectura frontend. Construiremos un par de middlewares y los pondremos en marcha, demostrando cómo es posible encadenar las llamadas a middlewares antes de la ejecución de los casos de uso, o recuperar la respuesta y seguir haciendo cosas después de que se ejecutaron los casos de uso. Explicaremos un caso práctico donde los middlewares nos resultarán muy útiles que consiste en la posibilidad de intercambiar la pila de middlewares en distintos entornos, como la etapa de desarrollo y la etapa de producción.

En este vídeo vamos a construir dos nuevos middlewares. Uno sencillo para implementar un timeout en caso que un caso de uso no pueda terminar en un tiempo concreto y uno más complejo para realizar la gestión centralizada de los errores. Por medio del middleware de gestión de errores conseguimos mostrar los errores ocurridos en los casos de uso de una manera sencilla, sin tener que llenar toda la aplicación de bloques try catch. Veremos casos simples donde el middleware muestra los mensajes de error por medio de un simple alter y se demostrará también cómo podríamos escalar eventos para que otros componentes de la aplicación se encarguen de mostrar los errores de una manera más amistosa para el usuario.

En este vídeo veremos con detalle el patrón repositorio, con sus ventajas y cómo se aplica de manera práctica en una aplicación frontend para separar el código de acceso a los datos de los casos de uso, de modo que puedas intercambiar distintos modos de acceso a los datos según las distintas necesidades de tus aplicaciones o entornos de ejecución.

Este patrón enunciado por Martin Fowler nos sirve para definir juegos de datos de una manera estructurada y comprensible, de modo que podamos crear datos para casos de prueba a alto nivel y con una semántica bien definida, además de reutilizable.

Una vez que ya conocemos el concepto de repositorio y lo hemos visto aplicado en un primer ejemplo, vamos a ver cómo los podemos completar, para gestionar todos los casos de uso en base a repositorios.

Como habrás podido comprobar, en los repositorios se hace código muy similar, por lo que podemos crear una nueva abstracción que hace las veces de cliente de HTTP. En nuestro caso será un wrapper de fetch, que se encargará de realizar las operaciones de ejecución de las solicitudes HTTP contra el servidor. Además de simplificar los repositorios y evitar código que es muy parecido en cada uno de ellos, la queremos porque así gestionamos en un solo lugar la interfaz de acceso a HTTP, que puede ser fetch, pero también otras librerías de Javascript como Axios o gretchen. De este modo, si en algún momento se decide cambiar de tecnología de solicitudes HTTP, solo tendremos que tocar una única clase.

A fin de mantener de manera consistente los nombres de los métodos de los repositorios, para ser más coherentes a lo largo de todas las piezas del software de acceso a datos, y facilitar el principio de interface segregation, vamos a crear toda una serie de interfaces para las operaciones de los repositorios.Avanzamos en el uso de repositorios viendo otros asuntos relacionados con el diseño y la arquitectura del software.

Vamos a explicar todos los principios de SOLID mostrando cómo impactan en el código de las aplicaciones, tal como lo estamos desarrollando. Además realizaremos nuevas adaptaciones en el proyecto para aplicar SOLID de una manera más adecuada.

Llegamos a un punto en el que el código de nuestra aplicación es muy testable, así que es el momento de abordar la disciplina del testing. Veremos cómo testear nuestras piezas de software y aprenderemos a crear mocks.

Veremos qué son los transformadores y cómo nos permiten mejorar todavía más las ventajas de uso de nuestros repositorios, realizando operaciones muy habituales como la transformación de los datos que nos envía el backend, para conseguir que se dispongan en el frontend tal como nos viene bien disponer de ellos.

Veremos qué son las capas concretando a qué se refiere, los tipos de arquitecturas de capas y conceptos relacionados, viendo cómo se aplica todo en la arquitectura frontend. Además comenzaremos explicando la primera de las capas, la más estable, la capa de dominio.

En el siguiente nivel tenemos la capa de application, que es la capa que ofrece un nivel de estabilidad medio donde se gestionan los casos de uso con las acciones del usuario, se gestiona el estado de la aplicación, los roles y permisos. Leyendo esta capa sabes qué puede hacer la aplicación.

Para definir nuestra arquitectura por capas vamos a tener otro nivel que es el delivery. Esta capa indica cómo se expone tu aplicación. Puedes exponer una aplicación con componentes, con un API REST, GraphQL, en una web o en una aplicación de escritorio, o una extensión del navegador. De hecho, una misma aplicación podría tener a la vez distintas maneras de exponerse y también podría cambiar con el tiempo.

Por último tenemos la capa de infrastructure. Es otra capa también más inestable con dependencias donde tenemos el código que está acoplado con sistemas externos y va a ser nuestro punto de integración. Por ejemplo aquí estarán los DTO o la implementación de los repositorios.

Un repaso final a los contenidos que hemos visto en el curso a modo de conclusión.