DEV Community: Rubén Aguilera Díaz-Heredero

L.U.C.I.A.: Cómo trabajar codo con codo con la IA sin perder el volante

Rubén Aguilera Díaz-Heredero — Tue, 17 Mar 2026 13:15:35 +0000

Todos en el sector tecnológico estamos viviendo la misma fiebre: la necesidad de ir rápido con la Inteligencia Artificial. Usamos asistentes, generamos código a una velocidad nunca antes vista y automatizamos tareas rutinarias. Pero, seamos sinceros, cuantos más agentes de IA tenemos, más caótico se vuelve el desarrollo y más tenemos la sensación de perder el volante.

En muchos equipos, la adopción de la IA está siendo caótica. Cada desarrollador la usa por su cuenta y riesgo, el contexto funcional se diluye entre prompts aislados y, al final del día, generamos mucho código, pero perdemos la visión de producto y la trazabilidad de la arquitectura, es más, las features que generamos vemos que funcionan pero no sabemos cómo realmente funcionan, por lo que no podemos dar soporte ni mantener el producto a largo plazo.

Para resolver este problema, estandarizar el trabajo de los equipos y domar el "caos", he creado L.U.C.I.A. No es una herramienta de pago ni un SaaS restrictivo. Es una metodología basada en repositorios Git estándar que nos permite gobernar la IA a lo largo de todo el ciclo de vida del software, desde la idea hasta la producción.

¿Qué es L.U.C.I.A.?

El logo no es casualidad. Representa los cinco pilares de esta forma de trabajar:

L (Lifecycle): Cubre absolutamente todo. Desde la inception de la idea y la definición funcional, hasta el despliegue en producción (DevOps/GitOps).
U (Universal): Es agnóstica. Nosotros la aplicamos usando el stack de Antigravity (con cuentas AI Pro o incluso en su versión gratuita), pero los principios sirven para cualquier modelo, asistente o tecnología.
C (Collaborative): Humanos e IA colaboran en un entorno natural para ambos: texto plano (Markdown) y repositorios Git.
I (Iterative): El producto evoluciona de forma controlada mediante commits y flujos de revisión, que se auto-prueban y se validan antes de su despliegue a los distintos entornos de ejecución.
A (Automation): El pegamento que lo une todo. Scripts y pipelines (CI/CD) que traducen documentos en issues accionables en tableros ágiles y automatizan el despliegue a los distintos entornos de ejecución.

La Arquitectura del Control: Divide y Vencerás

El corazón de L.U.C.I.A. se basa en la separación estricta entre el "Qué" (Negocio) y el "Cómo" (Tecnología), utilizando repositorios Git conectados.

Para ilustrarlo, podemos imaginar el desarrollo de un producto digital interno complejo y a la vez habitual que requiere integraciones, persistencia y una interfaz de usuario.

El Repositorio Git de Producto (El GPS)

Aquí es donde reside la "fuente de la verdad". En este repositorio, no hay código fuente, solo Docs-as-Code (Markdown).

Las personas de negocio y producto pueden hacer uso de cualquier herramienta que estén usando en la actualidad: Excel, NotebookLM, Confluence, etc., lo importante es que el resultado final sea un archivo Markdown que defina la visión del producto y el "Qué" se quiere construir.

A L.U.C.I.A. lo único que le importa es que este repositorio contenga un fichero product-vision.md con esa información y a partir de ese ficher, configuramos a nuestro agente de IA con una skill específica para que asuma el rol de Product Owner y algunos workflows para que pueda extraer los requisitos funcionales y los criterios de aceptación en formato Gherkin.

Pero no se queda aquí, a partir de esos requisitos funcionales, y conociendo el ecosistema de repositorios técnicos (technical-mapping.md) a los que tiene acceso, puede crear las tareas técnicas necesarias en cada uno de los repositorios técnicos correspondientes.

De esta forma, al tener todo el contexto en un solo repositorio, la IA nunca alucina ni pierde el hilo. Sabe exactamente cuáles son las reglas de negocio y los límites del producto.

Incluir nuevas tareas para ser ejecutadas por los equipos de desarrollo es tan sencillo como apoyarse en un workflow de IA (/new-task.md) el cual a través de lenguaje natural nos permite definir la tarea técnica y el repositorio técnico donde debe ser creada, comprueba si ya existe un requisito donde se defina esa tarea técnica y si no existe crea uno nuevo y asocia la tarea técnica a ese requisito.

La Transmisión: Automatización hacia GitLab

Para evitar tener que volver a definir las tareas dentro de cada repositorio técnico, desde este mismo repositorio de producto lanzamos un script que se encarga de crear o sincronizar las tareas en los repositorios técnicos correspondientes: Front, Microservicio 1, Microservicio 2, etc.

En nuestro caso usamos GitLab, que nos permite hacer está sincronización de tareas via API REST, en caso de contar con otro sistema como GitHub, Jira, etc. tendríamos que crear un script especifico para ese sistema.

De esta forma el trabajo llega a los equipos de desarrollo sin necesidad de tener que abrir la herramienta de gestión de tareas, ellos simplemente se encuentran con las tareas listas para ser ejecutadas.

Los Repositorios Técnicos (El Motor)

Un punto vital de esta metodología es su escalabilidad y adaptabilidad tecnológica: un único repositorio de producto puede tener asociados n repositorios técnicos. Al tener esta separación física, podemos dotar a cada repositorio de su propio agente y, lo más importante, configurarlo con las skills (habilidades) exactas para ese proyecto en concreto.

L.U.C.I.A. se adapta a cualquier ecosistema interno. Puedes tener un agente experto en Java y Spring Boot para un repositorio de microservicios de backend, otro especializado en Node.js, y otro configurado con directrices estrictas para desarrollar una SPA (Single Page Application) respetando una arquitectura basada en BLoCs.

Cuando la issue aterriza en uno de estos repositorios, se activan los workflows de sincronización y ejecución. El agente especializado absorbe la tarea con un contexto cristalino: conoce el requisito funcional general, las reglas de negocio exactas y la arquitectura técnica de su dominio específico.

Gracias a que trabajamos sobre una arquitectura de proyecto firmemente definida y a que el proyecto cuenta con mecanismos para autotestearse, le damos autonomía al agente para ejecutar la tarea. El propio agente diseña la solución, pica el código y crea las baterías de pruebas (ya sean tests unitarios, de integración o E2E según la tecnología del repositorio) para validar su trabajo.

Un factor clave en esta autonomía es la estandarización de la infraestructura mediante Docker y Docker Compose. Hemos comprobado que la IA es perfectamente capaz de asimilar y trabajar bajo este paradigma. Al hacerlo, conseguimos que el entorno de desarrollo local que levanta y testea el agente sea idéntico a cómo se va a ejecutar la aplicación en producción. Se acabó el temido "en mi máquina funciona"; si la IA lo conteneriza y los tests pasan, sabemos que el código es robusto.

Si todo está en verde, el agente tiene la capacidad de crear la Merge Request (MR) automáticamente. Es aquí donde el humano interviene para verificar y aprobar los cambios antes de que se integren, es el human-in-the-loop.

Pero un aviso a navegantes: no todo el proceso es IA. En L.U.C.I.A. le damos una importancia extrema a la automatización de procesos tradicional. Una vez que el desarrollador revisa y aprueba la MR, la IA se hace a un lado y los pipelines de integración continua (como GitLab CI) toman el control absoluto. Son estos flujos automatizados clásicos los encargados de empaquetar y desplegar hacia los entornos de beta y producción, asegurando que las subidas sean seguras, deterministas y completamente auditables.

¿Por qué este enfoque lo cambia todo?

Trabajar con la metodología L.U.C.I.A. aporta beneficios inmediatos:

Estandarización y Paridad Dev/Prod: Todos los equipos interactúan con la IA bajo las mismas reglas. Al incorporar Docker de serie, programamos y testeamos de la misma forma en la que vamos a desplegar.
Contexto Absoluto: Como la IA vive en el repositorio de Producto, comprende la estrategia global antes de escribir una sola línea de código.
Trazabilidad Extrema: Podemos rastrear una línea de código en un componente visual directamente hasta la regla de negocio Gherkin que la originó en el repositorio de producto.
Control del Volante: La IA propone, estructura y acelera, pero el proceso (las MRs, los scripts de sincronización, los tests automáticos y la canalización CI/CD) obliga a que haya validación humana o procedimental en cada punto de inflexión.
Resiliencia Total (A prueba de caídas): L.U.C.I.A. está hipervitaminada por la IA para alcanzar velocidades vertiginosas, pero funciona exactamente igual sin ella. Al basarse en estándares universales (Markdown, Git, Bash, CI/CD), si un día te quedas sin tokens, se cae el proveedor del modelo o simplemente decides abordar una tarea a mano, tu equipo sigue operando sin fricción. La IA es el acelerador, pero la mecánica del coche es cien por cien tuya.

Conclusión

La Inteligencia Artificial no ha venido a sustituir la ingeniería de software, sino a potenciarla. Pero para escalar su uso en equipos de desarrollo sin generar una deuda técnica inmanejable ni ataduras tecnológicas críticas, necesitamos metodologías sólidas.

L.U.C.I.A. es nuestra respuesta: un marco de trabajo donde la IA es un compañero incansable, pero el ciclo de vida del producto sigue estando firmemente bajo nuestro control.

¿Y por vuestra parte? ¿Cómo estáis estructurando el trabajo con IA en los equipos para no perder el volante? Os leo en los comentarios. 👇

Cobertura de tests con Vite, Cypress, Vitest y Docker

Rubén Aguilera Díaz-Heredero — Sat, 12 Aug 2023 23:15:54 +0000

Introducción

Cypress es una tecnología que, entre otras cosas, nos permite hacer testing e2e de nuestras aplicaciones web sin preocuparse por la tecnología que estemos utilizando por debajo, haciendo que se reduzca nuestro esfuerzo cognitivo de tener que aprender como testear la capa de UI en cada framework.

Pero no deja de ser interesante conocer la cobertura que estos tests tienen sobre todo nuestro código e incluso mergearla con la cobertura de los tests unitarios en la capa de core.

En este tutorial vamos a ver cómo hacer todo esto, partiendo de que nuestro proyecto ya tiene instalado Cypress como vimos en el tutorial Empezando con Cypress

Levantar el proyecto antes de ejecutar Cypress

Para poder ejecutar las pruebas e2e con Cypress tenemos que tener nuestro proyecto web levantado, además cuando ejecutamos estas pruebas en un pipeline necesitamos asegurarnos de que el servidor está levantado antes de ejecutarlas, ¿cómo podemos hacer esto?

La respuesta es instalar la siguiente dependencia:

$> npm install --save-dev start-server-and-test

y establecer dentro de nuestro package.json un nuevo script que nos permita ejecutar los tests de cypress justo después del arranque de la aplicación.

{
  "name": "spa-app",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "cy:open": "cypress open",
    "cy:test": "cypress run",
    "test:ci": "start-server-and-test dev http-get://localhost:5173 cy:test"
  },
  "dependencies": {
    "lit": "^2.7.2"
  },
  "devDependencies": {
    "cypress": "^12.17.3",
    "start-server-and-test": "^2.0.0",
    "vite": "^4.3.9"
  }
}

Es importante tener en cuenta el puerto dond ese vaya a levantar la aplicación, en este caso, el "5173" y el script que usamos para levantarla que en este caso es "dev".

De esta forma, ya podemos ejecutar:

$> npm run test:ci

y nuestros tests solo se ejecutaran en el terminal cuando el servidor se haya levantado.

Cálculo de la cobertura

Para realizar el cálculo de la cobertura necesitamos incluir las siguientes dependencias de desarrollo:

$> npm install --save-dev @cypress/code-coverage istanbul istanbul-merge nyc vite-plugin-istanbul

Ahora configuramos el fichero vite.config.js dejándolo de esta forma:

import { defineConfig } from "vitest/config";
import istanbul from "vite-plugin-istanbul";

export default defineConfig({
  plugins: [
    istanbul({
      cypress: true,
      requireEnv: false,
    }),
  ],
  test: {
    environment: "jsdom",
  },
});

Añadimos la siguiente línea al fichero cypress/support/e2e.js:

import '@cypress/code-coverage/support'

En el fichero cypress.config.js sustituimos el bloque actual por este otro:

import { defineConfig } from "cypress";
import codeCoverageTask from "@cypress/code-coverage/task.js";

export default defineConfig({
  video: false,
  e2e: {
    baseUrl: "http://localhost:5173",
    setupNodeEvents(on, config) {
      codeCoverageTask(on, config);
      return config;
    },
  },
});

Ahora creamos el fichero .nycrc con el siguiente contenido para configurar nuestros reportes de cobertura:

{
    "all": true,
    "check-coverage": true,
    "instrument": false,
    "report-dir": "coverage/cypress",
    "include": [
      "src/**"
    ],
    "exclude": [
      "instrumented/**"
    ],
    "lines": 0, //% mínimo, por debajo lanza error
    "statements": 0, //% mínimo, por debajo lanza error
    "functions": 0, //% mínimo, por debajo lanza error
    "branches": 0 //% mínimo, por debajo lanza error
}

Añadimos los siguientes scripts a nuestro package.json para hacer limpieza de los directorios, ejecutar los test de cypress con su cobertura, y generar los reportes correspondientes:

...
"clean:cov": "rm -rf coverage .nyc_output",
"test:ci": "start-server-and-test start http-get://localhost:5173/ cy:test",
"report:cov": "nyc report --reporter html --reporter text --reporter lcov -t coverage/cypress --report-dir coverage/cypress",
...

De esta forma al ejecutar:

$> npm run test:ci

Veremos que al finalizar los test nos genera los reportes de cobertura de cypress dentro del directorio "coverage/cypress".

Mergear la cobertura de Cypress y Vitest

Llegados a este punto, tenemos dos informes de cobertura, el primero de los tests con Vitest que tenemos dentro de la carpeta "coverage" y el segundo de los tests de cypress que encontramos en la carpeta "coverage/cypress".

Para ver un informe conjunto de ambos y saber cuál es el grado de cobertura de todos los tests en conjunto, hacemos uso de la utilidad "istanbul-merge".

De forma que teniendo esta sección de scripts dentro de nuestro package.json:

"scripts": {
    "start": "vite",
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "test": "vitest run --coverage --reporter junit --outputFile reports/junit-reporter.xml",
    "sonar": "sonar-scanner",
    "cy:open": "cypress open",
    "cy:test": "cypress run",
    "clean:cov": "rm -rf coverage .nyc_output test/reporter.xml",
    "test:ci": "start-server-and-test start http-get://localhost:5173/ cy:test",
    "cov:merge": "istanbul-merge --out coverage/total/coverage.json coverage/coverage-final.json coverage/cypress/coverage-final.json",
    "report:cov": "nyc report --reporter cobertura --reporter html --reporter text --reporter lcov -t coverage/total --report-dir reports/coverage",
    "test:all": "npm run clean:cov && npm run test && npm run test:ci && npm run cov:merge && npm run report:cov"
  }

Podemos ejecutar:

$> npm run test:all

De forma que se van a limpiar los directorios generados, se van a lanzar los tests de Vitest con su cobertura, se van a lanzar los tests de Cypress con su cobertura, se van a mergear en una única fuente de cobertura, se van a generar los reportes lcov, html y vamos a poder ver el resultado final también en la terminal.

Nota: es importante actualizar nuestro fichero .gitignore añadiendo los directorios que no queremos subir a nuestro control de versiones:

dist/
node_modules/
coverage/
.nyc_output/

Ejecución con Docker & Docker Compose

Para que estos tests aporten valor real al proyecto, tienen que formar parte del proceso de integración continua de nuestro proyecto.

Una de las formas más universales que tenemos de hacer esto, es hacer uso de Docker & Docker Compose y ejecutarlo en nuestro pipeline.

Para ello vamos a crear un fichero Dockerfile.cy con el siguiente contenido:

FROM cypress/included:12.17.3

WORKDIR /workspace

COPY package.json ./

RUN npm install --unsafe-perm=true --allow-root

COPY . .

Y un fichero docker-compose.ci.yml con el siguiente contenido:

version: "3.7"

services:
  test_all:
    build:
      context: .
      dockerfile: Dockerfile.cy
    entrypoint: /bin/sh -c "npm run test:all"
    volumes:
      - ./reports:/workspace/reports

Si nuestro pipeline fuera con GitlabCI, podríamos definir un stage de esta forma:

validate:
  stage: validate
  script:
    - docker-compose -f docker-compose.ci.yml up test_all --build --exit-code-from=test_all || exit 1
  tags:
    - runner101-shell
  except:
    - tags
  artifacts:
    reports:
      junit:
        - reports/junit-reporter.xml
      coverage_report:
        coverage_format: cobertura
        path: reports/coverage/cobertura-coverage.xml
  timeout: 600 seconds

Donde ejecutamos el script test:all al proyecto dentro de los stages de nuestro pipeline y podemos consultar los reportes generados para ser visualizados en nuestras Merge Requests.

Gestión del estado de una SPA con BLoC

Rubén Aguilera Díaz-Heredero — Mon, 07 Aug 2023 09:53:40 +0000

Introducción

La gestión del estado en una SPA, es una de las cosas más importantes a tener en cuenta, para que la experiencia de usuario sea la más adecuada.

Por poner un ejemplo de su importancia, ninguna persona que use nuestra aplicación querrá tener que volver a hacer login porque simplemente ha refrescado la página o tener que volver a buscar el resultado en una tabla cuando vuelve del detalle, entre otros tantos ejemplos.

De esto ya se hemos hablado cómo hacerlo utilizando solo RxJS y hay otras soluciones como Valtio que nos permiten controlar el estado de la aplicación. Pero podemos hacerlo sin usar ninguna librería, controlando nosotros todo el código.

Para ellos vamos a hablar en este artículo de los BLoCs, que ya fueron mencionados en el artículo de Arquitectura limpia en el front donde tenéis un ejemplo de su uso con React.

Pero, ¿qué es un BLoC?
Son las siglas de Business Logic Component, es un patrón muy conocido en el desarrollo con Flutter, y que se puede aplicar de igual forma al desarrollo web.

Dentro de la arquitectura limpia propuesta, es el pegamento entre las capas de UI y Core. Existen librerías que implementan este patrón pero aquí veremos que su implementación no es nada difícil y que además nos puede proporcionar persistencia en el estado de nuestra SPA de una forma muy sencilla.

Implementación propuesta para TypeScript

Lo más habitual es encapsular toda la funcionalidad del BLoC en una clase base de la que extenderan todos los distintos BLoCs que necesite nuestra aplicación.

Una posible implementación de esta clase base en TypeScript sería esta:

export class BaseBloc<T> {
  private subscribers: ((state: T) => void)[] = [];
  protected state: T = {} as T;
  private persistKey: string;

  constructor(persistKey: string) {
    this.persistKey = persistKey;
    this.loadPersistedState();

    window.addEventListener("beforeunload", () => {
      this.savePersistedState();
    });
  }

  private loadPersistedState() {
    const persistedState = localStorage.getItem(this.persistKey);
    if (persistedState) {
      this.state = JSON.parse(persistedState) as T;
    }
    localStorage.removeItem(this.persistKey);
  }

  private savePersistedState() {
    localStorage.setItem(this.persistKey, JSON.stringify(this.state));
  }

  subscribe(callback: (state: T) => void) {
    this.subscribers.push(callback);
  }

  unsubscribe(callback: (state: T) => void) {
    const index = this.subscribers.indexOf(callback);
    if (index !== -1) {
      this.subscribers.splice(index, 1);
    }
  }

  protected notifySubscribers() {
    this.subscribers.forEach((callback) => {
      callback(this.state);
    });
  }

  setState(newState: Partial<T>) {
    this.state = { ...this.state, ...newState };
    this.notifySubscribers();
  }

  getState() {
    return this.state;
  }
}

Estos son los componentes clave de la clase:

Constructor

constructor(persistKey: string) {
  this.persistKey = persistKey;
  this.loadPersistedState();

  window.addEventListener("beforeunload", () => {
    this.savePersistedState();
  });
}

El constructor recibe un parámetro persistKey que se utiliza como clave para almacenar el estado persistente en el almacenamiento local (localStorage). Al inicializar una instancia de BaseBloc, se carga el estado persistente previo (si existe) y se establece un evento que guarda el estado persistente antes de que el navegador se refresque.

Métodos loadPersistedState() y savePersistedState()

private loadPersistedState() {
  const persistedState = localStorage.getItem(this.persistKey);
  if (persistedState) {
    this.state = JSON.parse(persistedState) as T;
  }
  localStorage.removeItem(this.persistKey);
}

private savePersistedState() {
  localStorage.setItem(this.persistKey, JSON.stringify(this.state));
}

Estos métodos se encargan de cargar y guardar el estado persistente utilizando el localStorage. El estado previamente guardado se carga en la propiedad state cuando se crea una nueva instancia del componente y se elimina del localstorage una vez está cargado, a fin de no exponer la información del estado de forma permanente. Al refrescar el navegador, el estado actual se almacena en el localStorage.

Métodos de suscripción y notificación

subscribe(callback: (state: T) => void) {
  this.subscribers.push(callback);
}

unsubscribe(callback: (state: T) => void) {
  const index = this.subscribers.indexOf(callback);
  if (index !== -1) {
    this.subscribers.splice(index, 1);
  }
}

protected notifySubscribers() {
  this.subscribers.forEach((callback) => {
    callback(this.state);
  });
}

Estos métodos permiten que otros componentes o partes de la aplicación se suscriban al estado del componente BaseBloc. La función subscribe agrega un nuevo callback a la lista de suscriptores. Con unsubscribe, un callback puede ser eliminado de la lista de suscriptores si ya no es necesario recibir actualizaciones. Cuando el estado cambia mediante setState(), notifySubscribers() se encarga de notificar a todos los suscriptores para que puedan reaccionar a los cambios.

Métodos setState() y getState()

setState(newState: Partial<T>) {
  this.state = { ...this.state, ...newState };
  this.notifySubscribers();
}

getState() {
  return this.state;
}

Estos métodos son fundamentales para manipular y acceder al estado de la lógica de negocio. setState() actualiza el estado actual mediante una copia superficial (shallow copy) de newState, lo que garantiza que no se modifique directamente el estado original. Después de actualizar el estado, se llama a notifySubscribers() para informar a los suscriptores sobre el cambio. getState() simplemente devuelve el estado actual.

Uso de BaseBloc

Ahora imagina que tenemos que implementar un loading general de la aplicación, para hacer esto vamos a crear la clase LoadingBloc con el siguiente contenido:

import { BaseBloc } from "./base";

export type LoadingState = {
  loading: boolean;
};

export class LoadingBloc extends BaseBloc<LoadingState> {
  private static instance: LoadingBloc;

  public static getInstance(): LoadingBloc {
    if (!LoadingBloc.instance) {
      LoadingBloc.instance = new LoadingBloc();
    }
    return LoadingBloc.instance as LoadingBloc;
  }

  private constructor() {
    super("loading_state");
    this.setState({ loading: true });
  }

  show() {
    this.setState({ loading: true });
  }

  hide() {
    this.setState({ loading: false });
  }
}

Como vemos en la propia clase se define el tipo estado que vamos a almacenar, en este caso, una propiedad booleana loading.

Un punto fundamental para que se pueda gestionar correctamente el estado es que nos tenemos que asegurar de que esta clase solo tenga una instancia en toda la aplicación, porque de lo contrario no podría compartir el estado.

Como vemos esto se consigue con la implementación del patrón Singleton, donde ponemos como privado el constructor y el método getInstance() quien se encarga de mantener una única instancia.

Luego, para esta funcionalidad, necesitamos dos métodos públicos: show() que se encarga de poner a true la propiedad loading y hide() que se encarga de ponerla a false.

Como ya se comento anteriomente el método setState() se encarga de notificar a todos los componentes de la aplicación que se hayan suscrito a los cambios de este BLoC.

Además fíjate que el test de esta clase queda tan sencillo como realizar una serie de acciones y ver que el estado es el esperado. Para este BLoC este sería su test asociado:

import { LoadingBloc } from "./loading.bloc";

describe("Loading Bloc", () => {
  let loadingBloc: LoadingBloc;

  beforeEach(() => {
    loadingBloc = LoadingBloc.getInstance();
  });

  test("should set loading state properly", () => {
    loadingBloc.show();
    expect(loadingBloc.getState().loading).toBe(true);
    loadingBloc.hide();
    expect(loadingBloc.getState().loading).toBe(false);
  });
});

Ejemplo de uso del BLoC con Angular

En el artículo de arquitectura limpia viene un ejemplo de cómo hacerlo con React, así que aquí vamos a ver cómo hacer uso del BLoC dentro de una aplicación de Angular.

Imaginamos que necesitamos conocer el estado del loading en un componente header de nuestra aplicación, esta podría ser una posible implementación:

import { Component, OnDestroy, OnInit } from '@angular/core';
import { LoadingBloc, LoadingState } from 'src/core/blocs/loading.bloc';

@Component({
  selector: 'app-header',
  templateUrl: './header.component.html',
  styleUrls: ['./header.component.css']
})
export class HeaderComponent implements OnInit, OnDestroy{

  loading: boolean = false;
  loadingBloc = LoadingBloc.getInstance();
  handleState = (state: LoadingState) => {
    this.loading = state.loading;
  }

  ngOnInit(): void {
    this.loadingBloc.subscribe(this.handleState);
  }

  ngOnDestroy(): void {
    this.loadingBloc.unsubscribe(this.handleState);
  }

}

De forma que este SmartComponent, ya que tiene que conocer el estado de la aplicación, se puede apoyar en su template en n DumbComponents para mostrar de la forma que sea precisa el estado de loading de nuestra aplicación, pudiendo ser modificada desde cualquier punto de la misma.

Fíjate que el SmartComponent se encarga de hacer la suscripción y desuscripción del BLoC del método handleState(state) que recibe las actualizaciones del estado.

Conclusiones

Espero que este artículo sirva para entender mejor la parte de los BLoCs, que es quizá la pieza más importante en la arquitectura limpia propuesta.

Arquitectura limpia en el front

Rubén Aguilera Díaz-Heredero — Sun, 23 Jul 2023 09:27:53 +0000

Introducción

Lo primero que me gustaría decir es que entiendo yo por arquitectura limpia en el front, después de años de experiencia, de leer y practicar mucho este tema.

Para mi la arquitectura limpia en el front es aquella que es EVOLUCIONABLE, punto no hay más.

Es aquella que me permite tener hoy una aplicación implementada en un framework X y poder pasar al framework Y sin tener que reescribirla de cero.

Hoy en día esto parece una utopía ya que las personas que estamos en este lado del desarrollo sufrimos un bombardeo constante de mega-frameworks que nos venden el poder hacer aplicaciones de front cada vez más rápidas y vistosas a cambio de que nos aprendamos su solución; ahora podría estar hablando de Angular, Vue, React, Lit, Svelte, NextJS, ...

De hecho poco se habla de la fátiga mental que esto supone y que no sería la primera vez que algunos de estos frameworks desaparecen o se transforman obligando a aprender nuevas soluciones.

Por otro lado ahora mucho se habla de la arquitectura hexagonal aplicada al front, que en mi opinión, es demasiado rígida en sus principios y no termina de casar con el desarrollo front actual.

Un solo ejemplo de esto, en el desarrollo backend me parece completamente necesaria esa inversión de control que propone ya que es la única forma de poder hacer dobles de pruebas en los tests unitarios; pero el front es un poco distinto y con tecnologías actuales de testing como Jest o Vitest podemos mockear cualquier dependencia sin pagar el coste de un sistema de inyección de dependencias en el front.

Ahora con esto no quiero decir que los frameworks sean malos pero si que se tienen que utilizar donde realmente aportan valor a nuestra aplicación, no en toda ella, haciendo que irremediablemente nos casemos con esa solución.

Cómo conseguir una arquitectura limpia / evolucionable en el front

La respuesta es sencilla a la par que compleja, tenemos que abstraernos completamente del framework que hayamos seleccionado para montar nuestra aplicación.

Para ello vamos a estructurar nuestra aplicación en dos grandes capas:

core: la cual puede estar implementada con Javascript o Typescript y debe aislar la parte funcional de nuestra aplicación sin tener ninguna relación con el framework, como mucho puede apoyarse en librerías que aporten soluciones especificas como Axios.
ui: será la capa que contenga toda la parte relacionada con el framework en el que nos apoyemos para la presentación de nuestra aplicación y que nos ayudará en la creación de la interfaz gráfica y el router de páginas, entre otras cosas.

La clave es que la capa "core" sea completamente independiente y que en caso de cambiar el framework solo tengamos que re-implementar la capa de ui.

Vamos a centrarnos en la capa "core"

En la capa "core" irán los siguientes elementos funcionales (los cuales se pueden estructurar por módulos si desea):

model: va a contener las entidades y value objects que representen el modelo de la aplicación, es muy importante que no estén 100% ligados al API de turno.
services: van a ser clases que tengan funcionalidad transversal a la aplicación, es decir, que sea utilizada en distintos casos de uso o nos den cierta funcionalidad como helpers.
usecases: van a ser clases que reflejen las funcionalidades que la aplicación permite hacer. Se van a caracterizar por tener un único método llamado "execute()" o "run()".
repositories: van a ser las clases encargadas de la conexión con las APIs externas de servidor. Como recomendación personal, estas clases las implemento con Axios por el uso de interceptores y facilidad a la hora del testing en contraposición a solo usar fetch.
blocs: son las clases que hacen de pegamento entre la capa de ui donde está el framework y nuestro core. Mantienen el estado de la aplicación independiente del framework.

La estrategía de testing a seguir en esta capa será probar de forma unitaria los distintos blocs de la aplicación mockeando únicamente la parte de conexión con el servidor, es decir, los métodos de axios.

Con lo que queda probada el resto de la capa de forma social, no teniendo que hacer test unitarios de cada elemento a no ser que esto nos ayude en su desarrollo.

Fíjate en el detalle de que está capa puede quedar completamente probada y funcional sin tener que levantar el navegador con el tiempo que eso nos ahorra.

Además es recomendable aplicar TDD para la creación del bloc haciendo que el resto de elementos se vaya autodescubriendo en base a los casos de prueba.

Y qué hay en la capa de "ui"

Como hemos dicho en la capa de "ui" vamos a tener todo lo relativo a la presentación de nuestra aplicación apoyándonos en el framework seleccionado.

Los elementos más comunes de esta capa serán:

pages: serán los componentes que estén relacionado con el router de nuestra aplicación.
smarts: son los componentes "inteligentes" que hacen uso de los blocs para conectar con el core.
dumbs: son los componentes donde se apoyan los "smarts" para crear la interfaz gráfica adecuada a nuestra aplicación.

Dependiendo de la rigidez del framework seleccionado esta estructura de elementos podrá variar significativamente.

Para la parte de testing de esta capa, la recomendación es hacer uso de una tecnología agnóstica al framework que se esté utilizando, como es Cypress.

Conclusiones

Estructurando de esta forma la aplicación hacemos que sea más evolucionable y tengamos una red de seguridad de tests en ambas capas para no tener miedo a incluir nuevos cambios sean de la naturaleza que sean.

Ninguna de estas ideas son originales, son un batiburrillo de principios y buenas prácticas que actualmente intentamos poner en práctica en nuestros proyectos.

Ojalá estas ideas a corto plazo se transmitan en las formaciones previas al empleo como son Universidades, Bootcamps, Formación profesional, etc... poniéndolas por encima del conocimiento del framework que en ese momento este moda.

Aplicando estas prácticas nos daremos cuenta de lo poco que aportan los mega-frameworks al front y lo sencillo que se hace estar pegados a los estándares de la web con las ventajas que supone.

Si quieres que haga un workshop empezando de cero con estas ideas, contáctame a través de los comentarios.

Muchas gracias por llegar hasta aquí :-)

Este es el repo con un ejemplo de puesta en práctica de esta arquitectura con React + TypeScript usando Vite & Vitest: https://github.com/raguilera82/clean-arch-workshop-ts-react

Como construir una SPA sin frameworks y con testing

Rubén Aguilera Díaz-Heredero — Mon, 29 May 2023 17:09:34 +0000

A día de hoy estamos muy acostumbrados a que cuando queremos hacer un proyecto SPA tenemos tres opciones: Vue, Angular o React; pero se nos olvida que podemos hacerlo sin ninguno de estos frameoworks que nos obliga a estudiarlos y trabajar de la forma que nos marcan para conseguir nuestros objetivos de negocio.

Creación del proyecto desde cero

Para crear el proyecto de nuestra SPA desde cero podemos hacerlo de forma más manual con Webpack como se describe en este artículo e integrar Jest: https://dev.to/raguilera82/montar-spa-de-cero-con-vanilla-y-jest-3odb

Pero a día de hoy tenemos otra opción para crear nuestro proyecto, con todos los procesos necesarios, llamada Vite que además se integra con una solución de testing llamada Vitest, muy similar a Jest.

Para ello solo tenemos que ejecutar:

$> npm create vite@latest spa-app -- --template vanilla 
$> cd spa-app
$> npm install

Y para añadir Vitest solo tenemos que ejecutar:

$> npm install -D vitest

De esta forma quedaría el package.json de nuestro proyecto en este estado inicial:

{
  "name": "spa-app",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "test": "vitest --coverage"
  },
  "devDependencies": {
    "vite": "^4.3.2",
    "vitest": "^0.31.1"
  }
}

Únicamente tenemos las dependencias de desarrollo de vite y vitest. Ahora para arrancar el proyecto que viene de ejemplo podemos hacerlo con el comando:

$> npm run dev

Y la URL http://localhost:5173 podemos ver el resultado.

Si queremos crear la carpeta dist con los ficheros estáticos de nuestra aplicación, solo tenemos que ejecutar:

$> npm run build

Y para probarlo en modo producción, ejecutamos el comando:

$> npm run preview

Organización de proyecto

Independientemente de la forma de crear nuestro proyecto y de la funcionalidad que le queramos dar, vamos a incluir una carpeta src donde vamos a tener el código fuente de nuestro proyecto, organizado en una serie de carpetas cada una con una única responsabilidad (a medida que el proyecto crezca se puede llevar el mismo concepto a nivel de módulos funcionales):

components: va a almacenar "web components" que llaman a casos de uso. Es decir, componentes que conocen de nuestra lógica y que es posible que tengan relación con el estado de nuestra aplicación.
infra: va a almacenar los ficheros relacionados con tecnologías en las que nos apoyamos para realizar la aplicación. Por ejemplo, estarán en esta carpeta todo lo relacionado con el router de la spa, la gestión de estado, el fichero de conexión con Firebase si lo usamos, etc...
model: va a almacenar las clases de dominio de nuestra aplicación y que serán utilizadas por los elementos de la carpeta "components" y que como recomendación no se corresponderán con lo que venga en el API de turno.
pages: va a almacenar "web components" que estén relacionados con el router de nuestra SPA. Es decir, van a ser nuestras páginas a las que podemos ir navegando desde la URL a través del router.
repositories: va a almacenar las clases que permiten el acceso al API de turno para interacturar con un servidor. Es importante, que las clases de este nivel no tengan nada de lógica de negocio, más allá de conectarse con el api y transmitir la información al resto de la aplicación.
services: contiene métodos síncronos que resuelven funcionalidad transversal a distintos casos de uso.
ui: contiene los "web components" que solo utilizamos para la interfaz de nuestra aplicación, pero sin ningún tipo de lógica. Es decir, no llaman a casos de uso, reciben la información a través de propiedades o eventos de otros componentes y se comunican con el resto a través de eventos. Decimos que son componentes "tontos".
usecases: contiene las acciones que permitimos realizar a los personas que usan nuestra aplicación. Es importante que cada caso de uso tenga un único método llamado run o execute que reciba la información que necesita para ejecutarse y devuelva la información solicitada, todo de forma síncrona para favorecer el testing.

Implementación de un caso uso

Imaginad que nos piden hacer una página en nuestra aplicación que conectándose a un API (https://jsonplaceholder.typicode.com/) muestre un listado de posts, donde queremos mostrar: postId, heading y content.

Por lo que ya podemos crear el fichero "src/model/post.js" con el siguiente contenido:

export class Post {
    constructor({postId, heading, content}) {
        this.postId = postId;
        this.heading = heading;
        this.content = content;
    }
}

Vamos a empezar por definir el test de nuestro caso de uso, lo que nos va a permitir abstraernos de la parte visual y del API con el que conectar, por lo menos de momento. Entonces creamos la carpeta "test" y dentro el fichero "all-posts.usecase.spec.js" empezamos a pensar que información necesita y que información tiene que devolver este caso de uso, sabiendo que el caso de uso solo va a tener un método estático "execute".

También sabemos que tenemos que recuperar la información llamando a la URL https://jsonplaceholder.typicode.com/posts la cual ejecutada en Postman o en el propio navegador, nos informa que van a llegar 100 registros con la estructura: userId, id, title, body. Por lo que el resultado de nuestro caso de uso tendrá que devolver esos 100 registros y, al menos, comprobar que la primera posición coincide en valores con la primera posición de la información que devuelve el servidor.

De esta forma, creamos una carpeta "fixtures" dentro de "test" y creamos un fichero posts.json con el contenido de lo que devuelve el servidor.

Quedando algo como esto:

import { describe, it } from 'vitest';
import postsServer from './fixtures/posts.json';

describe('All posts use case', () => {
    it('should get all posts', () => {
        const posts = AllPostsUseCase.execute();
        expect(posts.length).toBe(postsServer.length);
        expect(posts[0].postId).toBe(postsServer[0].id);
        expect(posts[0].heading).toBe(postsServer[0].title);
        expect(posts[0].content).toBe(postsServer[0].body);
    })
})

Obviamente, el test no pasa porque no tenemos implementado el caso de uso, pero ya tenemos un test que responde a las necesidades de nuestra lógica de negocio.

Ahora creamos el fichero "src/usecases/all-posts.usecase.js" el cual va a tener un único método "execute" que inicialmente va a devolver nuestro fixture transformado al modelo que espera la aplicación:

import { Post } from '../model/post';
import postsServer from './../../test/fixtures/posts.json';

export class AllPostsUseCase {
    static execute() {
        return postsServer.map((postServer) => {
            return new Post({
                content: postServer.body,
                heading: postServer.title,
                postId: postServer.id
            })
        });
    }
}

Ahora ejecutamos el test con el comando npm run test y conseguimos que el test pase. Obviamente no estamos conectando con el servidor, pero ya hemos probado que la transformación a nuestro modelo simulando la llamada es correcta.

El siguiente paso es conectar con el servidor, para ello vamos a crear el fichero "src/repositories/posts.repository.js" donde vamos a implementar la llamada al servidor con la infraestructura que más nos guste, algunas personas lo querrán hacer con fetch, aquí lo vamos a ver con axios porque es más compatible con el testing.

Por lo que lo primero es instalar la dependencia.

$> npm install --save axios

Y el contenido del fichero quedaría de la siguiente forma:

import axios from "axios";

export class PostsRepository {
    async getAllPosts() {
        return (await axios.get("https://jsonplaceholder.typicode.com/posts")).data;
    }
}

Ahora nuestro caso de uso ya no necesita el fixture y debe ser asíncrono:

import { Post } from '../model/post';
import { PostsRepository } from '../repositories/posts.repository';

export class AllPostsUseCase {
    static async execute() {
        const repository = new PostsRepository();
        const postsServer = await repository.getAllPosts();
        return postsServer.map((postServer) => {
            return new Post({
                content: postServer.body,
                heading: postServer.title,
                postId: postServer.id
            })
        });
    }
}

y nuestro test ahora también es asíncrono:

import { describe, expect, it } from 'vitest';
import postsServer from './fixtures/posts.json';
import { AllPostsUseCase } from '../src/usecases/all-posts.usecase';

describe('All posts use case', () => {
    it('should get all posts', async () => {
        const posts = await AllPostsUseCase.execute();
        expect(posts.length).toBe(postsServer.length);
        expect(posts[0].postId).toBe(postsServer[0].id);
        expect(posts[0].heading).toBe(postsServer[0].title);
        expect(posts[0].content).toBe(postsServer[0].body);
    })
})

Si volvemos a ejecutar el comando npm run test veremos que nuestro test sigue pasando en verde, pero... por cada vez que lanzamos el test estamos haciendo la llamada real al servidor y esto, en la mayoría de los casos, no es lo más recomendable. Es por ello que tenemos que mockear la llamada y para ello podemos usar vitest prácticamente de forma igual a como haríamos con jest, una forma podría ser la siguiente:

import { beforeEach, describe, expect, it, vi } from 'vitest';
import postsServer from './fixtures/posts.json';
import { AllPostsUseCase } from '../src/usecases/all-posts.usecase';
import { PostsRepository } from '../src/repositories/posts.repository';

vi.mock('../src/repositories/posts.repository');

describe('All posts use case', () => {

    beforeEach(() => {
        PostsRepository.mockClear();
    })

    it('should get all posts', async () => {

        PostsRepository.mockImplementation(() => {
            return {
                getAllPosts: () => {
                    return postsServer;
                }
            }
        })

        const posts = await AllPostsUseCase.execute();
        expect(posts.length).toBe(postsServer.length);
        expect(posts[0].postId).toBe(postsServer[0].id);
        expect(posts[0].heading).toBe(postsServer[0].title);
        expect(posts[0].content).toBe(postsServer[0].body);
    })
})

En este momento estamos haciendo un mock del repositorio y le damos la respuesta que daría el servidor al llamar al método "getAllPosts". Es importante que antes de ejecutar el tests nos aseguremos resetear el mock, esto lo hacemos en el beforeEach.

De esta forma la parte funcional del caso de uso queda resuelta a la espera de ser invocada desde la página correspondiente y no hemos tenido que levantar la aplicación para nada, lo que hace que el desarrollo de la funcionalidad sea mucho más ágil.

Creación de la página

Para crear una página en un aplicación spa necesitamos tener un router que se encargue de simular la navegación entre páginas de nuestra aplicación.

Los frameworks (Angular, React y Vue) ya nos ofrecen su solución propia de routing pero nos casa a esta tecnología, a fin de mantenernos Vanilla o Frameworksless vamos a recurrir a una librería mucho más liviana que nos soluciona el problema como es vaadin-router (https://github.com/vaadin/router), la cual instalamos con el siguiente comando:

$> npm install --save @vaadin/router

Para utilizar el router vamos a crear el fichero "src/infra/router.js" con el siguiente contenido:

import { Router } from "@vaadin/router";
import './pages/posts.page';

const outlet = document.querySelector("#app");
export const router = new Router(outlet);

router.setRoutes([
  { path: "/", component: "posts-page" },
  { path: "(.*)", redirect: "/" },
]);

No hay que olvidar importar este fichero dentro del fichero main.js de nuestra aplicación, dejándolo de esta forma:

import "./src/infra/router";

Y asegurarse de que existe el elemento con identificador "app" dentro del fichero index.html, en nuestro caso:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite App</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/main.js"></script>
  </body>
</html>

Ahora vamos a crear la página que tenemos importada en el fichero . Para ello creamos el fichero "src/pages/posts.page.js" el cual va a ser un web component nativo que usaremos como contenedor de otros componentes. El código podría ser el siguiente simplemente para mostrar un título en la página y el conjunto de posts que vamos a recuperar del servidor a través del caso de uso con radh-posts:

import "./../components/posts.component";

export class PostsPage extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `
            <h1>Posts Page</h1>
            <radh-posts></k-posts>
        `;
  }
}

customElements.define("posts-page", PostsPage);

Entonces vamos a implementar el componente "radh-posts" que será el que tenga la inteligencia de saber a qué caso de uso llamar, y que por tanto lo vamos a crear en la ruta "src/components/posts-component.js" para su implementación nos vamos a apoyar en la librería lit que es una capa muy fina por encima del estándar HTMLElement que nos simplifica en parte el trabajo, para instalarla tenemos que ejecutar:

$> npm install --save lit

Una posible implementación de este componente sería:

Nota: el método createRenderRoot lo usamos para que todo el contenido del componente sea directamente accesible por los lectores de pantalla y las arañas del SEO.

import { LitElement, html } from "lit";
import { AllPostsUseCase } from "../usecases/all-posts.usecase";
import "./../ui/post.ui";

export class PostsComponent extends LitElement {
  createRenderRoot() {
    return this;
  }

  static properties = {
    posts: {
      type: Array,
    },
  };

  async connectedCallback() {
    super.connectedCallback();
    this.posts = [];
    this.posts = await AllPostsUseCase.execute();
    console.log(this.posts);
  }

  render() {
    return html`${this.posts.map(
      (post) => html`<post-ui .post="${post}"></post-ui>`
    )}`;
  }
}

customElements.define("k-posts", PostsComponent);

Como se puede apreciar este componente se apoya en otro de UI para mostrar la información, por lo que creamos el fichero "src/ui/post.ui.js" con esta posible implementación:

import { LitElement, html } from "lit";

export class PostUI extends LitElement {
  createRenderRoot() {
    return this;
  }

  static properties = {
    post: {
      type: Object,
    },
  };

  render() {
    return html`
      <div>
        <p>Post Id: ${this.post.postId}</p>
        <p>Heading: ${this.post.heading}</p>
        <p>Content: ${this.post.content}</p>
      </div>
    `;
  }
}

customElements.define("post-ui", PostUI);

De esta forma si hemos realizado correctamente las distintas importaciones al arrancar la aplicación con npm run dev deberemos ver algo como esto por pantalla:

Conclusiones

Espero que este tutorial refleje la poca necesidad que tenemos ahora mismo del uso de frameworks para conseguir nuestros objetivos con una spa.

De todos modos, esta implementación no es incompatible con los frameworks que deberían cubrir los aspectos de routing y creación de componentes visuales dejando tal cual la implementación y testing de los casos de uso.

Montar proyecto NodeJS con TypeScript

Rubén Aguilera Díaz-Heredero — Fri, 13 Aug 2021 22:13:53 +0000

Introducción

En este tutorial vamos a crear un proyecto de cero que esté preparado para trabajar con TypeScript.

Vamos al lío

Configuración inicial con TypeScript

Lo primero será crear una carpeta para nuestro proyecto y situarnos dentro:

$> mkdir ts-playground
$> cd ts-playground

Ahora dentro de la carpeta inicializamos el proyecto con Node:

$> npm init -y

E instalamos la dependencia de TypeScript para desarrollo:

$> npm install --save-dev typescript

Creamos el fichero tsconfig.json con los valores por defecto:

$> npx tsc --init

Y editamos el fichero tsconfig.json recién creado para dejarlo con las siguientes propiedades:

{
 "compilerOptions": {
  "target": "es5",
   "module": "commonjs",
   "outDir": "./dist",
   "rootDir": "./src",
   "strict": true,
   "noImplicitAny": true,
   "strictNullChecks": true,
   "esModuleInterop": true,
   "skipLibCheck": true,
   "forceConsistentCasingInFileNames": true
},
 "exclude": [
   "node_modules",
   "**/*.spec.ts"
  ]
}

Creamos la carpeta src donde vamos a tener nuestros ficheros *.ts

$> mkdir src

Editamos el fichero package.json para incluir los siguientes scripts:

"scripts": {
   "build": "tsc --build tsconfig.json",
   "build:watch": "tsc --build tsconfig.json --watch"
},

Probamos que la build se genera correctamente creando el fichero src/calc.ts con el siguiente contenido (src/calc.ts):

export class Calc {
 add (a: number, b: number): number {
   return a + b
 }
}

Ahora ejecutamos:

$> npm run build

Y tenemos que ver que el fichero dist/calc.js se genera correctamente.

Configuración de Jest

Para la integración con Jest vamos a instalar las siguientes dependencias de desarrollo:

$> npm install --save-dev jest ts-jest @types/jest

jest - Es el test runner
ts-jest - Es un preprocesador de Jest para TypeScript
@types/jest - Es la librería de definición de tipos de Jest

Para la configuración de Jest vamos a crear en la raíz del proyecto el fichero jest.config.js con el siguiente contenido:

module.exports = {
 roots: [
   "<rootDir>/src"
 ],
 testMatch: [
   "**/__tests__/**/*.+(ts|tsx|js)",
   "**/?(*.)+(spec|test).+(ts|tsx|js)"
 ],
 transform: {
   "^.+\\.(ts|tsx)$": "ts-jest"
 },
 collectCoverageFrom: [
   "**/*.{js,jsx,ts,tsx}",
   "!**/*.d.ts",
   "!**/node_modules/**",
 ],
 globals: {
   "ts-jest": {
     tsconfig: "tsconfig.json",
   },
 },
}

Y para poder ejecutar los test, editamos los scripts del fichero package.json para añadir:

"test": "jest --coverage"

Para probar la ejecución de los test vamos a crear el fichero src/calc.spec.ts con el siguiente contenido:

import { Calc } from './calc'

describe('Calc', () => {
 test('should return 10 for add(6, 4)', () => {
   expect(new Calc().add(6, 4)).toBe(10)
 })
 test('should return 9 for add(10, -1)', () => {
   expect(new Calc().add(10, -1)).toBe(9)
 })
})

Y ejecutamos:

$> npm run test

Configuración de ESLint

La integración con ESLint nos permite definir una guía de estilo única en nuestro proyecto que será respetada por todas las personas que trabajen en él. Necesitamos las siguientes dependencias:

$> npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

Ahora para configurar las opciones, tenemos que ejecutar el siguiente comando y contestar a una serie de preguntas:

$> npx eslint --init

How would you like to use ESLint?
- To check syntax, find problems, and enforce code style
What type of modules does your project use?
- JavaScript modules (import/export)
Which framework does your project use?
- None of these
Does your project use TypeScript?
- Yes
Where does your code run? (Seleccionar son la barra espaciadora)
- Node
How would you like to define a style for your project?
- Answer questions about your style
What format do you want your config file to be in?
- JavaScript
What style of indentation do you use?
- Spaces
What quotes do you use for strings?
- Single
What line endings do you use?
- Unix
Do you require semicolons?
- Yes

Lo que creará un fichero .eslintrc.js en la raíz de proyecto con el siguiente contenido:

module.exports = {
   'env': {
       'es2021': true,
       'node': true,
       'jest': true
   },
   'extends': [
       'eslint:recommended',
       'plugin:@typescript-eslint/recommended'
   ],
   'parser': '@typescript-eslint/parser',
   'parserOptions': {
       'ecmaVersion': 12,
       'sourceType': 'module'
   },
   'plugins': [
       '@typescript-eslint'
   ],
   'rules': {
       'indent': [
           'error',
           4
       ],
       'linebreak-style': [
           'error',
           'unix'
       ],
       'quotes': [
           'error',
           'single'
       ],
       'semi': [
           'error',
           'always'
       ]
   }
};

Nota: añadimos jest a env para evitar problemas a la hora de chequear los archivos de test. Y añadimos la siguiente línea a los scripts del package.json:

"lint": "eslint ./src --ext .ts"

Para realizar la integración con el IDE para que nos pueda avisar de los errores y corregirlos al salvar vamos a editar las settings de Visual Studio Code para añadir las siguientes:

/**
   ----- Linting configurations
 */
 // Prevent editor formatting on save for certain file types
 "editor.formatOnSave": true,
 "[javascript]": {
   "editor.formatOnSave": false,
 },
 "[typescript]": {
   "editor.formatOnSave": false,
 },
 // Configure eslint to report + fix errors for correct file types
 "editor.formatOnPaste": true,
 "eslint.autoFixOnSave": true,
 "eslint.validate": [
   "javascript",
   {
     "language": "javascript",
     "autoFix": true
   },
   {
     "language": "typescript",
     "autoFix": true
   }
 ],

Configuración de Husky

Para forzar ciertas acciones a la hora de hacer commit o pushear cambios utilizamos la librería husky, para lo que tenemos que añadir la siguiente dependencia de desarrollo:

$> npm install --save-dev husky

Inicializamos git en el proyecto:

$> git init

Creamos el fichero .gitignore con el siguiente contenido:

node_modules/
coverage/
dist/

Inicializamos husky:

$> npx husky install

Configuramos husky para ejecutar el script de lint antes de hacer un commit:

$> npx husky add .husky/pre-commit "npm run lint"

Para ejecutar los test antes de hacer push:

$> npx husky add .husky/pre-push "npm run test"

Y para no permitir mensajes de commit que no cumplan con Conventional Commits, para ello vamos a instalar las siguientes dependencias:

$> 
npm install --save-dev commitlint @commitlint/config-conventional

Editamos el fichero package.json para añadir la siguiente sección:

"commitlint": {
 "extends": "@commitlint/config-conventional"
},

Y, por último, añadimos el siguiente hook con husky:

$>  npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"

Configuración para debugger

A fin de poder hacer debug con Visual Studio Code necesitamos añadir la propiedad “sourceMap” a true en el fichero tsconfig.json del proyecto, pudiendo quedar de esta forma:

{
"compilerOptions": {
 "target": "es5",
  "module": "commonjs",
  "outDir": "./dist",
  "rootDir": "./src",
  "strict": true,
  "noImplicitAny": true,
  "strictNullChecks": true,
  "esModuleInterop": true,
  "skipLibCheck": true,
  "forceConsistentCasingInFileNames": true,
  "emitDecoratorMetadata": true,
  "experimentalDecorators": true,
  "sourceMap": true
},
"exclude": [
  "node_modules",
  "**/*.spec.ts"
 ]
}

y configurar el fichero .vscode/launch.json con el siguiente contenido:

{
   "version": "0.2.0",
   "configurations": [
       {
           "type": "node",
           "request": "launch",
           "name": "Launch Program",
           "program": "${workspaceRoot}/dist/server.js",
           "cwd": "${workspaceRoot}",
           "sourceMaps": true,
           "outFiles": [
               "${workspaceFolder}/dist/**/*.js"
           ]
       }
   ]
}

De esta forma podemos poner puntos de ruptura en nuestro código para que la ejecución se detenga y podamos inspeccionar el contexto de ejecución con Visual Studio Code.

Montar SPA de cero con Vanilla y Jest

Rubén Aguilera Díaz-Heredero — Tue, 01 Jun 2021 07:19:16 +0000

TL;DR

Aquí el repo con el resultado de seguir la guía: https://github.com/raguilera82/vanilla-spa-starter

Introducción

En un mundo frontend dominado actualmente por los tres frameworks: React, Angular y Vue; es importante no perder las bases y ver que nada es magia y que todo se puede hacer con VanillaJS.

En este primer tutorial vamos a ver cómo montar el entorno necesario para comenzar nuestro proyecto sin frameworks, utilizando únicamente alguna librería como Jest para realizar el testing.

Creación del proyecto y primeros ficheros

Partimos de que nuestra máquina de desarrollo cuenta con un runtime de NodeJS y vamos a utilizar la terminal y como editor el Visual Studio Code.

Así que lo primero será abrir la terminal y crear el directorio donde vamos a empezar nuestro proyecto de cero.

$> mkdir /path/vanilla-starter
$> cd /path/vanilla-starter

Ahora para inicializar el proyecto hacemos uso del comando init de npm, y con el modificador -y aceptamos todos los valores por defecto:

$> npm init -y

Para ayudar en la edición de los ficheros vamos a abrir el proyecto con Visual Studio Code y el resto de comandos los ejecutaremos desde el terminal del editor:

$> code .

Nos apoyamos en el editor para crear una carpeta llamada "src" que va a contener inicialmente los ficheros "index.html", "main.css" y "main.js".

El fichero index.html va a tener el siguiente contenido donde no hacemos ninguna referencia al CSS ni al JavaScript, esa será labor de webpack.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vanilla</title>
  </head>
  <body>
    <h1>Vanilla</h1>
  </body>
</html>

En el fichero "main.css" podemos añadir algún estilo:

body {
  background-color: grey;
}

E igual podemos hacer con el fichero "main.js" para ver que vamos bien, si vemos en la consola el mensaje y donde importamos el fichero main.css que luego será reconocido por webpack:

import './main.css';
console.log('Vanilla');

Añadimos webpack al proyecto

A fin de que nuestro proyecto sea una SPA y para realizar todas las operaciones necesarias para su puesta en producción como minificado, tener refresco automático en desarrollo y otras tareas, vamos a incluir webpack como dependencia de desarrollo del proyecto.

$> npm install webpack webpack-cli webpack-dev-server webpack-merge --save-dev

Instalamos también todos los plugins de webpack que inicialmente vamos a utilizar en nuestro proyecto:

$> npm install html-webpack-plugin mini-css-extract-plugin css-loader style-loader html-loader @babel/core @babel/preset-env babel-loader --save-dev

Ahora en el raíz del proyecto vamos a crear un fichero llamado "webpack.common.js" donde vamos a incluir todos los comportamientos que queremos que webpack nos ejecute independiente de que el entorno sea de desarrollo o de producción.

const path = require('path');
const HTMLWebpackPlugin = require('html-webpack-plugin');

module.exports = {
    entry: './src/main.js',
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: 'bundle.js',
        clean: true
    },
    module: {
        rules: [
            {
                test: /\.css$/i,
                use: ['style-loader', 'css-loader']
            },
            {
                test: /\.html$/i,
                loader: 'html-loader'
            },
            {
                test: /\.m?js$/,
                exclude: /node_modules/,
                use: {
                    loader: "babel-loader",
                    options: {
                        presets: ['@babel/preset-env']
                    }
                }
            }
        ]
    },
    plugins: [
        new HTMLWebpackPlugin({
            template: './src/index.html'
        })
    ]
};

Y luego vamos a crear uno para el entorno de desarrollo llamado webpack.dev.js

const { merge } = require('webpack-merge');

const common = require('./webpack.common.js');

module.exports = merge(common, {
  mode: 'development',
  devtool: 'inline-source-map',
  target: 'web',
  devServer: {
    historyApiFallback: true //Evita GET /page not found
  }
});

Y otro con la configuración para producción, llamado webpack.prod.js:

const { merge } = require('webpack-merge');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

const common = require('./webpack.common.js');

module.exports = merge(common, {
  mode: 'production',
  devtool: 'source-map',
  plugins: [new MiniCssExtractPlugin()],
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: [MiniCssExtractPlugin.loader, 'css-loader']
      }
    ]
  }
});

Añadimos los siguientes scripts al fichero package.json, también le vamos a añadir la configuración de browserlist para que la usen las herramientas compatibles como babel-preset-env:

"scripts": {
    "start": "webpack serve --config=webpack.dev.js",
    "build": "webpack --config=webpack.prod.js"
},
"browserslist": [
    "defaults",
    "not IE 11"
],

De forma que cuando estamos desarrollando utilizamos la configuración de desarrollo y cuando construimos el bundle lo hacemos con la configuración para producción.

Para comprobar que la configuración es la correcta podemos arrancar el proyecto:

$> npm run start

y comprobar la URL: http://localhost:8080

Y para ver que nos genera correctamente los ficheros estáticos, ejecutamos:

$> npm run build

y comprobamos que nos genera la carpeta "dist", la cual es buena idea que introduzcamos dentro del fichero .gitignore

node_modules/
dist/

Configuración de pruebas automáticas con Jest

A fin de poder ejecutar pruebas automáticas en el proyecto, añadimos la dependencia de Jest junto con su soporte de babel y la librería que permite pruebas con DOM:

$> npm install jest babel-jest @testing-library/dom --save-dev

creamos el fichero babel.config.json con el siguiente contenido:

{
  "presets": ["@babel/preset-env"]
}

y el siguiente script al fichero package.json, quedando de esta forma:

"scripts": {
    "start": "webpack serve --config=webpack.dev.js",
    "build": "webpack --config=webpack.prod.js",
    "test": "jest --coverage"
},
"jest": {
    "transform": {
      "^.+\\.[t|j]sx?$": "babel-jest"
    }
  }

De forma que podemos ejecutar npm run test para lanzar todas las pruebas del proyecto (cuando las tenga) y recoger el informe de cobertura gracias al modificador --coverage.

Configuración de linters

Linter de código

A fin de que todo el equipo de desarrollo haga uso de una misma guía de estilo, vamos a incluir la dependencia:

$> npm install --save-dev semistandard

y el siguiente script en el fichero package.json, también vamos a añadir configuración para que no marque errores en los tests, quedando de esta forma:

"scripts": {
    "start": "webpack serve --config=webpack.dev.js",
    "build": "webpack --config=webpack.prod.js",
    "test": "jest --coverage",
    "lint": "semistandard --fix"
},
"semistandard": {
    "globals": [
      "describe",
      "context",
      "before",
      "beforeEach",
      "after",
      "afterEach",
      "it",
      "expect"
    ]
  },

Pudiendo ejecutar npm run lint para descubrir las violaciones en las reglas de estilo y con el modificador --fix solucionarlas de forma automática.

Nota: por defecto no se comprobarán los ficheros que estén dentro del fichero .gitignore.

Linter de mensajes de commit

Vamos a añadir a nuestro proyecto la dependencia de husky, la cual nos permitirá establecer una serie de hooks de Git que nos permitan verificar que los mensajes de commit cumplen con el standard de Conventional Commits

$> npm install husky @commitlint/cli @commitlint/config-conventional --save-dev

Creamos en la raíz del proyecto el directorio .husky y dentro creamos el fichero "commit-msg" con el siguiente contenido para comprobar que el mensaje cumple con el formato de Conventional Commits:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install commitlint --edit $1

Y otro llamado "pre-commit" para ejecutar los test antes de hacer un commit:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npm test

Es muy importante darle permisos de ejecución a todos estos ficheros.

$> cd .husky
$> sudo chmod -R +x *
$> cd ..

Y en el fichero package.json incluimos el siguiente script para instalar husky al hacer un prepare del proyecto y añado la siguiente configuración:

"scripts": {
    "prepare": "husky install",
    "start": "webpack serve --config=webpack.dev.js",
    "build": "webpack --config=webpack.prod.js",
    "test": "jest",
    "lint": "semistandard"
},
"commitlint": {
    "extends": "@commitlint/config-conventional"
},

Para probarlo tenemos que inicializar git en el proyecto:

$> git init

Ejecutar un install de npm:

$> npm install

Al tratar de hace un commit tenemos que ver que ejecuta los tests y nos saca un mensaje de error si no se cumple con el formato marcado.

Conclusiones

Con estos pasos ya tenemos preparado nuestro proyecto para poder implementar la solución que necesitemos. En caso estar trabajando con Visual Studio Code, es altamente recomendable las siguientes extensiones:

Jest Runner: para poder ejecutar cualquier test case o test suite de forma aislada al resto.

Añadir soporte de DevTools

Rubén Aguilera Díaz-Heredero — Wed, 03 Mar 2021 22:28:25 +0000

Resumen

En este tutorial vamos a ver cómo integrar nuestra solución de gestión de estado con las DevTools del navegador para poder depurar nuestras aplicaciones de la forma más cómoda.

Entorno

Slimbook Prox15 32 Gb RAM i7
SlimbookOS (Ubuntu 20.04)
RxJS 6.6.2
Visual Studio Code

Introducción

Seguro que a poco que hayas visto algo de Redux y todas sus variantes en los frameworks de turno, te habrá llamado la atención su integración con las DevTools de Chrome donde se puede ver en todo momento una foto del estado, las acciones que se han producido y "viajar" entre ellas.

Así que vamos a ver cómo conseguir esto sin recurrir a ninguna librería, solo nuestro proyecto de gestión de estado con RxJS.

Vamos al lío

Lo primero que vamos a hacer es instalar la siguiente extensión de Chrome que nos añadirá una nueva pestaña llamada "Redux" en las Developer Tools. Esto es tan sencillo como ir a la URL y pulsar en instalar.

Ahora tenemos que hacer alguna modificación en nuestro proyecto para habilitar la conexión a esta extensión y mandar la información. Para habilitar la conexión, vamos a ir a nuestro fichero raíz y vamos a incluir lo siguiente:

const win = window as any;

if (win.__REDUX_DEVTOOLS_EXTENSION__) {
  win.devTools = win.__REDUX_DEVTOOLS_EXTENSION__.connect();
}

En mi caso estoy en un proyecto con TypeScript de ahí que tenga que wrappear el window del navegador.

Para evitar que la aplicación falle en el arranque si previamente no hemos instalado la extensión, vamos a poner un if de guarda a la sentencia que nos permite conectar con la extensión.

Ahora tenemos que ver de qué forma le transmitimos los datos a la extensión, es decir, le informamos a la extensión de las acciones y los cambios de estado que se producen.

Esto lo vamos a hacer en el fichero store.ts que implementamos en los anteriores tutoriales de esta serie. De forma que ahora el store va a recibir el tipo de acción y el estado resultante de aplicar dicha acción, quedando de esta forma:

import { BehaviorSubject, Observable } from 'rxjs';

const win = window as any;

export abstract class Store<T> {
    private state$: BehaviorSubject<T> = new BehaviorSubject(undefined);
    get = (): T => this.state$.getValue();
    get$ = (): Observable<T> => this.state$.asObservable();
    store = (type: string, nextState: T) => {
        if (win.devTools) {
            win.devTools.send(type, nextState);
        }
        return this.state$.next(nextState);
    }
}

Como ves también es conveniente verificar que existe el objeto win.devTool antes de utilizarlo, de otra forma nos daría error, al no estar instalada la extensión.

Esto nos obliga a cambiar la implementación de los métodos del store, ya que ahora es obligatorio pasarle el nombre de la acción antes del store modificado. Como por ejemplo:

export class ApplicationsStoreService extends Store<Application[]> {

  constructor(private service: ApplicationsService) {
    super();
  }

  init(): Promise<Application[]> {
    if (this.get()) { return; }
    return this.service.getApplications().pipe(
      tap((data) => this.store('APPLICATIONS_INIT', data))
    ).toPromise();
  }
}

Este será el nombre que veremos en la extensión de Redux cuando nuestra aplicación ejecuta la acción, como vemos en la siguiente imagen.

Conclusiones

Como ves podemos implementar una solución más sencilla y sobre todo universal, sin perder las ventajas de otras tecnologías más complejas (y completas) como NgRx, Vuex, etc...

Notarás que la extensión muestra los cambios de estado por aplicación como si solo hubiese un store, esto es porque Redux funciona solo con un store. En nuestro caso creamos múltiples stores por lo que realmente la extensión solo nos vale para saber las acciones que se han ejecutado y el orden de ejecución.

La ventaja es que no trabajamos con reducers y nos ahorramos la típica estructura switch con todas las acciones y su lógica asociada.

Ejecutar test e2e en Angular con Cypress y calcular cobertura

Rubén Aguilera Díaz-Heredero — Sun, 25 Oct 2020 22:28:00 +0000

Resumen

En este tutorial vamos a ver cómo ejecutar los tests e2e de nuestras aplicaciones Angular con Cypress en vez de Protractor y cómo configurar el proyecto para obtener la cobertura de los tests de Cypress.

Entorno

Slimbook Prox15 32 Gb RAM i7
SlimbookOS (Ubuntu 20.04)
Angular 9
Cypress 4.5.0
Visual Studio Code

Introducción

A poco que hayas trabajado o estés trabajando con Angular te habrás dado cuenta que por defecto viene configurado para ejecutar los tests con Protractor, una tecnología que adolece de los problemas de inestabilidad y falsos positivos de Selenium y que por ello ahora se prefiere la tecnología de Cypress para este tipo de tests.

Además otro punto interesante es registrar a modo de informe de cobertura que tanto por ciento de mi código ha sido ejecutado con estos tests... pues todo esto lo vamos a ver en este turorial.

Vamos al lío

Partimos de que hemos creado o tenemos ya creado un proyecto con Angular CLI, si lo creamos de cero, solo tenemos que ejecutar:

$> ng new poc

Como ya sabrás esto hace la magía de crearnos un proyecto Angular completamente configurado y listo para entrar en producción.

Pero como ya hemos dicho ahora queremos utilizar Cypress en vez de Protractor para lo cual, y gracias a los schematics de Angular, simplemente y sin preguntar mucho tenemos que ejecutar:

$> ng add @briebug/cypress-schematic

Este comando hace su magia y borra todo lo relacionado con Protractor, añadiendo toda la configuración necesaria para trabajar con Cypress, además respetando TypeScript, ¡qué más podemos pedir!

Ahora cuando ejecutamos los tests e2e con el comando:

$> npm run e2e

Lo que nos aparece es la consola de Cypress, lista para ayudarnos a crear nuestros primeros tests.

Si queremos ejecutar los tests en modo CI, solo tenemos que ejecutar:

$> npm run poc:cypress-run

Ahora vamos a por la segunda parte del tutorial que consiste en registar el cálculo de cobertura de los tests de Cypress. Desafortunadamente, todavía no contamos con un schematics para hacerlo, por lo que vamos a verlo paso a paso:

En primer lugar creamos el fichero cypress/coverage.webpack.js con el siguiente contenido:

module.exports = {
    module: {
      rules: [
        {
          test: /\.(js|ts)$/,
          loader: 'istanbul-instrumenter-loader',
          options: { esModules: true },
          enforce: 'post',
          include: require('path').join(__dirname, '..', 'src'),
          exclude: [
            /\.(e2e|spec)\.ts$/,
            /node_modules/,
            /(ngfactory|ngstyle)\.js/
          ]
        }
      ]
    }
  };

Luego comprobamos si ya existe en nuestro proyecto el fichero cypress/plugins/cy-ts-preprocessor.ts, si no existe lo creamos con el siguiente contenido:

const webpackPreprocessor = require("@cypress/webpack-preprocessor");

const webpackOptions = {
  resolve: {
    extensions: [".ts", ".js"]
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: [/node_modules/],
        use: [
          {
            loader: "ts-loader"
          }
        ]
      }
    ]
  }
};

const options = {
  webpackOptions
};

module.exports = webpackPreprocessor(options);

Ahora añadimos un nuevo builder a nuestro proyecto, ejecutando:

$> npm i -D ngx-build-plus

Y dentro del fichero angular.json buscamos la propiedad "serve" y la configuramos de esta forma:

"serve": {
    "builder": "ngx-build-plus:dev-server",
    "options": {
        "browserTarget": "poc:build",
        "extraWebpackConfig": "./cypress/coverage.webpack.js"
    },
    "configurations": {
        "production": {
            "browserTarget": "poc:build:production"
        },
        "ci": {
            "progress": false
        }
    }
},

Nota: fíjate que "poc" es el nombre del proyecto, tu seguro que tendrás otro.

Hecho esto vamos a añadir la depedencia de istanbul que nos va a ayudar a sacar el reporte de cobertura.

$> npm i -D istanbul-instrumenter-loader

Y añadimos las depedencias que hacer que istanbul entienda TypeScript.

$> npm i -D @istanbuljs/nyc-config-typescript source-map-support ts-node

Tenemos que editar el fichero angular.json para añadir la configuración de nyc que deja de ser el CLI de Istanbul.

...
"nyc": {
    "extends": "@istanbuljs/nyc-config-typescript",
    "all": true
  }
...

Ahora instalamos el plugin de cobertura de Cypress y lo necesario de nyc:

$> npm install -D @cypress/code-coverage nyc istanbul-lib-coverage

Casi por último, editamos el fichero cypress/support/index.ts con el siguiente contenido:

import './commands';

// Import cypress code-coverage collector plugin
import '@cypress/code-coverage/support';

Nota: no importa si el formateador te cambia de orden los imports.

y creamos/editamos el fichero cypress/plugins/index.js, dejándolo con el siguiente contenido:

const cypressTypeScriptPreprocessor = require("./cy-ts-preprocessor");
const registerCodeCoverageTasks = require("@cypress/code-coverage/task");

module.exports = (on, config) => {
  on("file:preprocessor", cypressTypeScriptPreprocessor);

  registerCodeCoverageTasks(on, config);

  return config;

};

Ya hemos terminado pero para facilitar la ejecución de los tests en modo CI, vamos a editar el fichero package.json y añadir el siguiente script de npm:

...
"e2e:run": "ng run poc:cypress-run",
...

De esta forma cuando ejecutamos:

$> npm run e2e:run

Veremos que Cypress se ejecuta en modo CI y después de la ejecución dejará el reporte de cobertura calculado en dentro de la carpeta "coverage" del proyecto.

De esta forma podemos utilizar estos informes para integrarlos con Sonarqube o cualquier otra herramienta de calidad y lo más importante podemos ver que si hay código que no llega a ejecutarse y puede ser eliminado para favorecer la mantenibilidad del proyecto.

Autenticación con JWT en NestJS

Rubén Aguilera Díaz-Heredero — Thu, 10 Sep 2020 19:12:36 +0000

Resumen

Vamos a ver cómo configurar la autenticación para hacer necesario tener un token JWT válido en el acceso a nuestros endpoints más sensibles.

Entorno

Slimbook Prox15 32 Gb RAM i7
SlimbookOS (Ubuntu 20.04)
NestJS 7.0.0
Visual Studio Code

Introducción

La autenticación con token de JWT se ha convertido en un estándar de facto a la hora de proteger los endpoints más sensibles de nuestra aplicación: aquellos que crean, modifican o eliminan recursos de nuestro servidor y otros de consulta que devuelven información sensible que solo debería estar accesible por el usuario en concreto.

De hecho aquí vamos a ver como enviar el id del usuario a través de token, algo mucho más seguro que hacerlo por parámetro en la URL. Imaginad un endpoint que devuelve datos judiciales, y que simplemente cambiando el id por parámetro y volviendo hacer la llamada, devuelve los datos judiciales, que obviamente tienen que ser confidenciales, de cualquier persona que no conoces de nada, pues eso ha pasado....

Vamos al lío

En NodeJS se suele utilizar Passport para la configuración de los métodos de autenticación, por lo que NestJS ya nos ofrece una integración directa con esta librería, simplemente instalando las siguientes dependencias.

$> npm install --save @nestjs/passport passport @nestjs/jwt passport-jwt bcrypt
$> npm install --save-dev @types/passport-jwt @types/bcrypt

Además de Passport también instalamos la dependencia de bcrypt que nos va a permitir codificar la password en base de datos, para que nadie, incluso personas con permisos para ver las tablas de credenciales de usuario pueda conocer tu contraseña.

Siguiendo con la serie de tutoriales tenemos ya en nuestro proyecto un fichero src/users/user.entity.ts que define nuestra entidad de usuario y que vamos a utilizar para asociarle la password que usaremos para comprobar la entidad de la persona en el proceso de login.

Por ello necesitamos añadir la columna password, y dos métodos: uno que se va a ejecutar antes del insert de la entidad y que se va a encargar de codificar la password y otro que usaremos posteriormente para validar que la password del usuario al hacer login es válida, gracias a la librería bcrypt.

La entidad UserEntity quedaría de esta forma:

import * as bcrypt from 'bcrypt';
import { BeforeInsert, Column, Entity, PrimaryGeneratedColumn } from 'typeorm';

@Entity('users')
export class UserEntity {
  @PrimaryGeneratedColumn('uuid')
  readonly userId: string;

  @Column({
    unique: true,
  })
  readonly name: string;

  @Column({ type: 'varchar', length: 70, nullable: true })
  password: string;

  @BeforeInsert()
  async hashPassword() {
    const salt = await bcrypt.genSalt();
    this.password = await bcrypt.hash(this.password, salt);
  }

  async validatePassword(password: string): Promise<boolean> {
    return await bcrypt.compareSync(password, this.password);
  }

  constructor(userId: string, name: string, pass: string) {
    this.userId = userId;
    this.name = name;
    this.password = pass;
  }
}

De la serie de tutoriales ya sabrás que estamos usando migrations de TypeORM, así que este es el momento de generar un nuevo fichero de migración ejecutando el comando:

$> npm run typeorm:migrate add-auth

Ahora vamos al servicio UsersRepository para añadir un nuevo método que me permita recuperar un usuario a partir de su nombre.

getUserByName(name: string): Promise<UserEntity> {
    return this.usersRepository.findOne({ name });
}

Este método va a ser invocado por la capa de servicio, por lo que dentro del servicio UsersService vamos a crear un nuevo método que haga la llamada al repositorio.

async getUserByName(name: string): Promise<UserEntity> {
    return await this.usersRepository.getUserByName(name);
}

Este es un buen momento para ver que todo es correcto, que la migración se aplica correctamente y que todos nuestros tests siguen pasando, así que ejecutamos:

$> npm run verify

Tendremos que ver que todo sigue siendo correcto, aunque ahora tenemos la cobertura un poco más baja al tener nuevo código que no ha sido todavía probado.

Una vez tenemos todo lo necesario para guardar las credenciales de nuestros usuarios, es el momento de crear un nuevo módulo llamado "auth":

$> npx nest generate module auth

Dentro del nuevo módulo vamos a crear el fichero auth.service, el cual va a implementar dos métodos: uno "validateUser" que se va a encargar de validar las credenciales del usuario, es decir, que el username exista en la base de datos y que su password coincida con el rebibido en en el endpoint de login; y otro método "generateAccessToken" que se va encargar de generar el accessToken con la información que queramos guardar en el payload del token JWT, para nuestro caso de uso, hacemos una consulta a la base de datos, para recuperar el id del usuario y guardarlo en el payload del token JWT, que recordemos va en claro, por lo que no hay que almacenar información sensible como dni, números de cuenta, contraseñas, etc...

import { Injectable } from '@nestjs/common';
import { JwtService } from '@nestjs/jwt';
import { UsersService } from 'src/users/users.service';
import { JWTPayload } from './jwt.payload';

@Injectable()
export class AuthService {
  constructor(
    private usersService: UsersService,
    private jwtService: JwtService
  ) {}

  async validateUser(username: string, pass: string): Promise<boolean> {
    const user = await this.usersService.getUserByName(username);
    return await user.validatePassword(pass);
  }

  async generateAccessToken(name: string) {
    const user = await this.usersService.getUserByName(name);
    const payload: JWTPayload = { userId: user.userId };
    return {
      access_token: this.jwtService.sign(payload),
    };
  }
}

Cuando trabajas con TypeScript es buena práctica crear interfaces / clases que guarden el tipado de los objetos que utilizamos. En este caso, vamos a crear el fichero auth/jwt.payload.ts con el siguiente contenido:

export interface JWTPayload {
  userId: string;
}

Igual creamos una clase (para poder hacer uso de las anotaciones de Swagger para la documentación del API) para modelar los datos que vamos a recibir en el body del método POST que implementaremos a continuación para otorgar o no el acceso a través de token al usuario solicitante.

import { ApiProperty } from '@nestjs/swagger';

export class LoginDTO {
  @ApiProperty()
  name: string;

  @ApiProperty()
  pass: string;
}

Y a continuación el controlador que se encargará de recibir las peticiones de login de los usuarios (auth/auth.controller.ts), validar las credenciales y lanzar una excepción en caso de que no se encuentre al usuario o generar el token si el usuario se encuentra y las credenciales son válidas.

import { Body, Controller, Post, UnauthorizedException } from '@nestjs/common';
import { AuthService } from './auth.service';
import { LoginDTO } from './login.dto';

@Controller('login')
export class AuthController {
  constructor(private authService: AuthService) {}

  @Post()
  async login(@Body() loginDTO: LoginDTO): Promise<{ access_token: string }> {
    const { name, pass } = loginDTO;
    const valid = await this.authService.validateUser(name, pass);
    if (!valid) {
      throw new UnauthorizedException();
    }
    return await this.authService.generateAccessToken(name);
  }
}

Para poder hacer uso del servicio JwtService para generar los tokens de JWT, tenemos que importar el módulo JwtModule dentro de AuthModule y establecer el periodo de expiración del token y la palabra secreta para su encriptación. Esta palabra secreta la guardaremos en el fichero .env como variable de entorno, y la cargamos importando el módulo ConfigModule. Además tenemos que registrar como providers todos los servicios implementados, quedando el código de esta forma:

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { JwtModule } from '@nestjs/jwt';
import { UsersModule } from 'src/users/users.module';
import { AuthController } from './auth.controller';
import { AuthService } from './auth.service';

@Module({
  imports: [
    ConfigModule.forRoot(),
    UsersModule,
    JwtModule.register({
      secret: process.env.JWT_SECRET,
      signOptions: { expiresIn: '60s' },
    }),
  ],
  controllers: [AuthController],
  providers: [AuthService],
  exports: [AuthService],
})
export class AuthModule {}

Con esto ya tenemos un endpoint que nos otorga tokens a los usuarios válidos, donde almacenamos su id para evitar tener que pasarlo por URL. Recuerda que el token está firmado y no puede ser manipulado, a no ser que expongas la palabra secreta.

Ahora entramos en la segunda parte del objetivo que es proteger ciertos endpoints para que solo puedan ser ejecutados si el cliente tiene un token JWT válido.

Para eso Passport define distintas estrategías donde una de las más habituales es la de JWT. Creamos el fichero auth/jwt.strategy.ts con el siguiente contenido:

import { Injectable, UnauthorizedException } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { ExtractJwt, Strategy } from 'passport-jwt';
import { UserDTO } from 'src/users/user.dto';
import { UsersService } from 'src/users/users.service';
import { JWTPayload } from './jwt.payload';

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor(private usersService: UsersService) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      ignoreExpiration: false,
      secretOrKey: process.env.JWT_SECRET,
    });
  }

  async validate(payload: JWTPayload): Promise<UserDTO> {
    const user = await this.usersService.getUserById(payload.userId);
    if (!user) {
      throw new UnauthorizedException();
    }
    return user;
  }
}

En este fichero definimos varias cosas, por un lado que el token se va a recibir a través de la cabecera de HTTP llamada Authorization, que no vamos a disparar una excepción cuando el token esté expirado y establecemos va misma variable de entorno para el secreto.

Además implementa el método validate el cual a través del payload del token JWT se va a encargar de determinar si la persona esta o no autorizada, y en caso de estarlo, establecer la información que luego podremos recuperar en la request.

Para registrar esta estrategia tenemos que importar el módulo PassportModule y el provider JwtStrategy en auth.module.ts

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { JwtModule } from '@nestjs/jwt';
import { PassportModule } from '@nestjs/passport';
import { UsersModule } from './../users/users.module';
import { AuthController } from './auth.controller';
import { AuthService } from './auth.service';
import { JwtStrategy } from './jwt.strategy';

@Module({
  imports: [
    ConfigModule.forRoot(),
    UsersModule,
    PassportModule,
    JwtModule.register({
      secret: process.env.JWT_SECRET,
      signOptions: { expiresIn: '60d' },
    }),
  ],
  controllers: [AuthController],
  providers: [AuthService, JwtStrategy],
  exports: [AuthService],
})
export class AuthModule {}

Es el momento de establecer la seguridad en los endpoints, para ello hacemos uso del concepto de guarda de NestJS que permite a través del decorador @UseGuards establecer n guardas que se tienen que cumplir para que el endpoint se pueda ejecutar.

En nuestro caso de ejemplo del crud de usuarios, vamos a establecer la guarda en los métodos de GET, PUT y DELETE by Id quedando el controlador de esta forma:

import {
  Body,
  Controller,
  Delete,
  Get,
  Param,
  Post,
  Put,
  UseGuards,
} from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
import { ApiBearerAuth } from '@nestjs/swagger';
import { ValidUserIdPipe } from './../pipes/valid-user-id.pipe';
import { UserDTO } from './user.dto';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private usersService: UsersService) {}

  @Get()
  async getAllUsers(): Promise<UserDTO[]> {
    return await this.usersService.getAllUsers();
  }

  @Get(':id')
  @ApiBearerAuth()
  @UseGuards(AuthGuard('jwt'))
  async getUserById(@Param('id') id: string): Promise<UserDTO> {
    return await this.usersService.getUserById(id);
  }

  @Post()
  async newUser(@Body() user: UserDTO): Promise<UserDTO> {
    return await this.usersService.newUser(user);
  }

  @Put(':id')
  @ApiBearerAuth()
  @UseGuards(AuthGuard('jwt'))
  async updateUser(
    @Param('id', ValidUserIdPipe) id: string,
    @Body() user: UserDTO
  ): Promise<UserDTO> {
    return await this.usersService.updateUser(id, user);
  }

  @UseGuards(AuthGuard('jwt'))
  @ApiBearerAuth()
  @Delete(':id')
  async deleteUser(@Param('id') id: string): Promise<void> {
    return await this.usersService.deleteUser(id);
  }
}

De esta forma los endpoints solo se pueden ejecutar cuando son llamados con un token válido. Ahora vamos a evitar que en el endpoint de recuperar los datos por id tengamos que pasar el id por parámetro, recuperándolo del token. Para lo que en vez de recuperarlo de la URL lo vamos a hacer de la request donde el método validate del JwtStrategy ha dejado los datos devueltos en una propiedad que podemos consultar llamada "user".

De forma que el controlador quedaría de esta forma:

@Get('/me')
@ApiBearerAuth()
@UseGuards(AuthGuard('jwt'))
async getUserById(@Request() req: any): Promise<UserDTO> {
  const { id } = req.user;
  return await this.usersService.getUserById(id);
}

Otra forma de recuperar la información del usuario, a través del token, es implementar un decorador propio en NestJS. Creamos el fichero "auth/auth.decorator.ts" con el siguiente contenido:

import {
  createParamDecorator,
  ExecutionContext,
  ForbiddenException,
} from '@nestjs/common';
import { JWTPayload } from './jwt.payload';

export const Auth = createParamDecorator(
  (data: unknown, ctx: ExecutionContext): Partial<JWTPayload> => {
    try {
      const request = ctx.switchToHttp().getRequest();
      return request.user;
    } catch (error) {
      throw new ForbiddenException();
    }
  }
);

De forma que ahora podemos utilizarlo en cualquier de los endpoints protegidos para recuperar la información que almacena la estrategia de JWT en la request. Este sería el ejemplo para el caso de devolver un usuario.

@Get('/me')
@ApiBearerAuth()
@UseGuards(AuthGuard('jwt'))
async getUserById(@Auth() { id }: UserDTO): Promise<UserDTO> {
    return await this.usersService.getUserById(id);
}

Ahora nos podemos encontrar con el caso en el que queremos que una persona con un rol de administrador pueda hacer cualquier tipo de operación con cualquier usuario como actualizar sus datos o borrar el usuario.

Creación de un Custom Pipe para validar contra un servicio en NestJS

Rubén Aguilera Díaz-Heredero — Mon, 17 Aug 2020 14:50:27 +0000

Resumen

Vamos a ver cómo implementar una validación contra base de datos a través de la creación de un custom pipe donde se va a inyectar el servicio de comunicación con la base de datos.

Entorno

Slimbook Prox15 32 Gb RAM i7
SlimbookOS (Ubuntu 20.04)
NestJS 7.0.0
Visual Studio Code

Introducción

Si una cosa tiene buena NestJS es su documentación, pero en el caso de los Pipes no encuentras un caso de uso muy común, como es el de validar un dato de entrada contra la base de datos y los ejemplos que vienen pueden llevarnos a equivocarnos o pensar que no se puede, así que vamos a ver que si se puede.

Vamos al lío

Para ilustrar el ejemplo vamos a implementar un custom pipe que dado el valor de un id compruebe si se encuentra en base de datos y si no se encuentra lanzaremos una excepción de "Bad Request" al cliente.

Lo primero que tenemos que hacer es crear nuestro custom pipe, el cual tiene que extender de PipeTransform, lo que nos obliga a implementar nuestra lógica en el método transform que recibe el valor asociado al pipe y el metada de la información. Esta sería la implementación por defecto de cualquier Pipe.

import { PipeTransform, Injectable, ArgumentMetadata } from '@nestjs/common';

@Injectable()
export class ValIdPipe implements PipeTransform {
  transform(value: any, metadata: ArgumentMetadata) {
    return value;
  }
}

Como queremos hacer una consulta a la base de datos con el valor que llega en el argumento "value" tenemos que injectar el servicio a través del constructor, y hacer uso de él, en la lógica del método transform. El servicio nos tendrá que devolver un error cuando el id no se encuentre en base de datos, que capturaremos para lanzar la excepción apropiada. El código podría quedar de esta forma:

import { Dog } from "@entities/dog.entity";
import { ArgumentMetadata, BadRequestException, Injectable, Logger, PipeTransform } from "@nestjs/common";
import { InjectRepository } from "@nestjs/typeorm";
import { Repository } from "typeorm";

@Injectable()
export class ValIdDogPipe implements PipeTransform {

    constructor(@InjectRepository(Dog)
    public dogsRepository: Repository<Dog>) {}

    async transform(value: any, metadata: ArgumentMetadata) {
        try {
            await this.dogsRepository.findOneOrFail(value);
        }catch(err) {
            throw new BadRequestException("Id no existe");
        }

        return value;
    }

}

En el ejemplo estoy inyectando directamente el repository para dejar claro que hace una consulta a base de datos, pero lo normal es que la llamada a base de datos se haga a través de un servicio de negocio o por QueryBus si se está utilizando el módulo de CQRS.

El argumento "metadata" nos ofrece información de contexto como la anotación y el nombre de parámetro que se ha utilizado, que nos puede ser útil, para aplicar una lógica u otra.

Como ves la implementación es muy sencilla. Ahora viene la segunda parte y donde digo que la documentación de NestJS puede llevarnos a equivoco: el momento de hacer uso del custom pipe en el controlador.

Para hacer uso del custom pipe tenemos que anotar el método del controlador con @UsePipes y declarar la clase que acabamos de implementar, el caso es que en la documentación tenemos este ejemplo:

@Post()
@UsePipes(new JoiValidationPipe(createCatSchema))
async create(@Body() createCatDto: CreateCatDto) {
  this.catsService.create(createCatDto);
}

Donde puede parecer que tenemos que hacer un new de la clase para poder utilizarlo, y como nosotros estamos inyectando el servicio, se nos complica la forma de poder pasarle el argumento que requiere al estar en una anotación.

Pero la realidad es que si hacemos uso del tipo y no de la instancia, es decir, quitamos el new y los paréntesis, el framework infiere la inyección y todo funciona a la perfección. Con lo cual para hacer uso del custom pipe solo tenemos que hacer:

@Get(/dogs/:id)
@UsePipes(ValIdDogPipe)
getDogById(@Param('id') id: string) {
  ...
}

Con lo que si el id no existe, el cliente lo que recibirá será una respuesta indicando:

{
    "statusCode": 400,
    "message": "Id no existe",
    "error": "Bad Request"
}

Otro detalle es que haciéndolo a nivel de método, si tenemos más de un parámetro en la URL, el pipe se va a ejecutar tantas veces como parámetros estén definidos, así que una mejor forma, que evita este problema, es declarar el pipe a nivel de parámetro de esta forma:

@Get(/dogs/:id)
getDogById(@Param('id', ValIdDogPipe) id: string) {
  //Code
}

Implementación de un CRUD genérico con RxJS

Rubén Aguilera Díaz-Heredero — Sat, 08 Aug 2020 21:09:58 +0000

Resumen

En este tutorial vamos a ver un ejemplo práctico de aplicación de la forma de gestión de estado que vimos en este tutorial anterior por lo que te recomiendo que lo veas antes de seguir con éste.

Entorno

Slimbook Prox15 32 Gb RAM i7
SlimbookOS (Ubuntu 20.04)
RxJS 6.6.2
Visual Studio Code

Introducción

No hay cosa más tediosa en las aplicaciones, y que tengamos que repetir tanto, que tener que implementar el típico CRUD de una entidad, que por lo general necesita mantener el estado para hacer que la UI sea reactiva ante los cambios de los usuarios.

Así que vamos a ver una forma de hacer más genérico este desarrollo y que una misma implementación nos valga para cualquier entidad.

Vamos al lío

Lo primero que tenemos que hacer es fijar una serie de restricciones en nuestras entidades para hacerlas compatibles. En el caso de TypeScript esto lo podemos conseguir con interfaces y herencia; así que vamos a definir una interfaz "Base" que va a contener un campo id de tipo string o number, y que tendrá que ser heredado por todas las entidades que queramos manejar con esta implementación. La interfaz es tan sencilla como:

export interface Base {
    id?: string | number;
}

Ahora vamos a definir un estado genérico para el manejo de cualquier entidad, lo que vamos a crear es una interfaz que va definir el array de elementos de la entidad y registrar si ha habido algún error. De esta forma:

export interface CrudState<T extends Base> {
    isError?: boolean;
    elems?: T[];
}

Otro de los puntos clave de esta implementación es crear una interfaz con los métodos habituales del CRUD, de forma que la implementación del store no se acople a la forma de recuperar los datos. De esta forma:

import { Observable } from 'rxjs';

export interface CrudRepository<T> {

    getAll(): Observable<T[]>;

    add(elem: T): Observable<T>;

    update(id: string | number, elem: T): Observable<T>;

    delete(id: string | number): Observable<string | number>;

}

Con estos métodos podemos:

(C) crear nuevos elementos
(R) leer elementos ya existentes
(U) actualizar algún elemento existente
(D) borrar algún elemento existente

Con todos estos elementos, estamos en disposición de hacer la implementación de nuestro CRUD genérico con manejo de estado. Esta sería la implementación más básica:

import { catchError, tap } from 'rxjs/operators';
import { Base } from 'src/app/domain/models/base';
import { Store } from '../store';
import { CrudRepository } from './crud-repository';
import { CrudState } from './crud-state';

export class CrudStore<T extends Base> extends Store<CrudState<T>> {

    constructor(public repository: CrudRepository<T>){
        super();
        this.getElems();
    }

    getElems(): Promise<T[]> {
        return this.repository.getAll().pipe(
            tap(elems => {
                const state: CrudState<T> = {
                    isError: false,
                    elems: elems
                }
                this.store(state);
            })
        ).toPromise();
    }

    addElem(elem: T): Promise<T> {
        return this.repository.add(elem).pipe(
            tap(el => {
                const elems = this.get().elems;
                const state: CrudState<T> = {
                    isError: false,
                    elems: [...elems, el]
                };
                this.store(state);
            }),
            catchError(err => {
                this.store({isError: true, elems: []})
                throw err;
            })
        ).toPromise();
    }

    updateElem(id: string | number, elem: T): Promise<T> {
        return this.repository.update(id, elem).pipe(
            tap(() => {
                const elems = this.get().elems;
                const e = Object.assign({}, elem);
                const index = elems.findIndex((el: T) => el.id === id);
                const newElems = [...elems.slice(0, index), e, ...elems.slice(index + 1)];
                const state: CrudState<T> = {
                    isError: false,
                    elems: newElems
                };
                this.store(state);
            })
        ).toPromise();
    }

    deleteElem(id: string | number): Promise<string | number> {
        return this.repository.delete(id).pipe(
            tap(() => {
                const elems = this.get().elems;
                const newElems = elems.filter(elem => elem.id !== id);
                const state: CrudState<T> = {
                    isError: false,
                    elems: newElems
                };
                this.store(state);
            })
        ).toPromise();
    }

}

A destacar:

La clase está parametrizada para recibir una entidad que extienda de Base de forma que nos aseguramos que el campo id, ya sea string o number, va a existir en nuestras operaciones.
La clase extiende de Store para tener todas las propiedades reactivas que vimos en el tutorial anterior y está parametrizado con el tipo de estado que queremos manejar.
A través del constructor inyectamos el repositorio de datos pero a través de su interfaz, de forma que no nos acoplamos a una implementación específica.
Todos los métodos devuelven el observable en forma de promesa, para aprovechar el async/await en cualquier framework que tengamos por encima y olvidarnos de tener que hacer desuscripción explícita.
Es importante resaltar que la suscripción que si hay que eliminar de forma explícita es la que se haga al store a través del método público get$()
Los métodos siempre hacen lo mismo, llaman al método del repositorio correspondiente, si hay un error lo registran en el store, y si no, trabajan con el array en memoria para reflejar el cambio en el store y notificar a los elementos interesados en el cambio.

Creamos un test unitario con una entidad "Example" que hace uso de un repositorio fake en memoria. Este sería el resultado:

import { Observable, of } from 'rxjs';
import { Base } from 'src/app/domain/models/base';
import { CrudRepository } from './crud-repository';
import { CrudState } from './crud-state';
import { CrudStore } from "./crud-store";

describe('CRUD Store Test', () => {


    it('get all elems', async() => {

        const crudStore = new CrudStore<Example>(new FakeRepository());

        await crudStore.getElems();

        const state: CrudState<Example> = crudStore.get();
        expect(state.isError).toBe(false);
        expect(state.elems.length).toBe(2);

    })

    it ('add elem', async() => {

        const crudStore = new CrudStore<Example>(new FakeRepository());
        const addExample = {id:'3', name:'example-3'};

        await crudStore.addElem(addExample);

        const state: CrudState<Example> = crudStore.get();
        expect(state.isError).toBe(false);
        expect(state.elems.length).toBe(3);


    })

    it ('update elem', async() => {

        const exampleName = 'example-test-1'

        const crudStore = new CrudStore<Example>(new FakeRepository());
        const updateElem = {id: '1', name: exampleName};

        await crudStore.updateElem('1', updateElem);

        const state = crudStore.get();
        expect(state.isError).toBe(false);
        expect(state.elems[0].name).toEqual(exampleName);

    })

    it ('delete elem', async () => {
        const crudStore = new CrudStore<Example>(new FakeRepository());
        const deleteId = '1';

        await crudStore.deleteElem(deleteId);

        const state: CrudState<Example> = crudStore.get();
        expect(state.isError).toBe(false);
        expect(state.elems.length).toBe(1);

    })

})

class FakeRepository implements CrudRepository<Example> {

    getAll(): Observable<Example[]> {

        const example1 = {id: '1', name: 'example-1'}
        const example2 = {id: '2', name: 'example-2'}
        const examples = [example1, example2];

        return of(examples);
    }
    add(elem: Example): Observable<Example> {
        return of(elem);
    }
    update(id: string | number, elem: Example): Observable<Example> {
        return of(elem);
    }
    delete(id: string | number): Observable<string | number> {
        return of(id);
    }


}

export interface Example extends Base {
    id: string | number;
    name: string;
}

Ahora crear un CRUD de cualquier entidad de nuestro dominio será tan sencillo como crear un estado especifico donde definiríamos otras propiedades en el estado específicas de esta entidad:

import { Dog } from '../../../domain/models/dog';
import { CrudState } from '../crud-store/crud-state';

export interface DogState extends CrudState<Dog> {}

Crear la interfaz para el repositorio que extienda de la del CRUD genérico de forma que si, por ejemplo, queremos añadir filtros específicos de esta entidad lo hagamos en esta interfaz, de esta forma:

import { Observable } from 'rxjs/internal/Observable';
import { Dog } from '../../../domain/models/dog';
import { CrudRepository } from '../crud-store/crud-repository';

export interface DogsRepository extends CrudRepository<Dog> {

    filterByName(name: string): Observable<Dog[]>;

    filterByBreed(breed: string): Observable<Dog[]>;
}

Y en el store de la entidad solo tendríamos que incluir la implementación de los métodos que son específicos de dicha entidad:

import { tap } from 'rxjs/operators';
import { Dog } from '../../../domain/models/dog';
import { CrudStore } from '../crud-store/crud-store';
import { DogsRepository } from './dogs-repository';
import { DogState } from './dogs-state';

export class DogsStore extends CrudStore<Dog> {

    constructor(public repository: DogsRepository) {
        super(repository);
    }

    filterDogsByName(name: string): Promise<Dog[]> {
        return this.repository.filterByName(name).pipe(
            tap(elems => {
                const state: DogState = {
                    isError: false,
                    elems: elems
                }
                this.store(state);
            })
        ).toPromise()
    }

    filterDogsByBreed(breed: string): Promise<Dog[]> {
        return this.repository.filterByBreed(breed).pipe(
            tap((elems: Dog[]) => {
                const state: DogState = {
                    isError: false,
                    elems: elems
                }
                this.store(state);
            })
        ).toPromise()
    }

}

Y para el caso de Angular, la implementación del repositorio para esta entidad podría quedar de la siguiente forma:

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { of } from 'rxjs';
import { Observable } from 'rxjs/internal/Observable';
import { catchError } from 'rxjs/operators';
import { DogsRepository } from 'src/app/application/stores/dogs-store/dogs-repository';
import { Dog } from '../../domain/models/dog';

@Injectable({ providedIn: 'root' })
export class DogsRepositoryProxy implements DogsRepository {

    constructor(private httpClient: HttpClient) { }

    getAll(): Observable<Dog[]> {
        return this.httpClient.get<Dog[]>('http://localhost:3000/dogs');
    }

    add(elem: Dog): Observable<Dog> {
        return this.httpClient.post<Dog>('http://localhost:3000/dogs', elem).pipe(
            catchError(error => {
                console.log(error);
                throw error;
            })
        );
    }

    update(id: string | number, elem: Dog): Observable<Dog> {
        return of(elem);
    }
    delete(id: string | number): Observable<string | number> {
        return of(id);
    }

    filterByName(name: string): Observable<Dog[]> {
        return this.httpClient.get<Dog[]>('http://localhost:3000/dogs/filter/name/' + name);
    }

    filterByBreed(breed: string): Observable<Dog[]> {
        return this.httpClient.get<Dog[]>('http://localhost:3000/dogs/filter/breed/' + breed);
    }

}

Conclusiones

Como ves un caso tan común como el de hacer un CRUD de una entidad se puede resolver de una forma muy práctica ahorrando mucho código repetitivo, pero dejando la posibilidad de extender las capacidades en función de las necesidadades de la entidad en cuestión.