DEV Community: Hernani Almeida

Angular 21 + Native Federation — Parte 2: Integração, Debug e Boas Práticas

Hernani Almeida — Tue, 06 Oct 2026 03:02:06 +0000

Na primeira parte, vimos como criar uma arquitetura de Micro Frontends utilizando Angular 21 e Native Federation.

Nesta segunda parte, vamos aprofundar a integração entre Host e Remote, entendendo o que acontece por trás da configuração e, principalmente, alguns pontos que podem gerar erros durante a implementação.

A ideia é sair de uma configuração que simplesmente "funciona" para entender por que ela funciona.

1. Arquitetura que vamos construir

Teremos dois projetos:

angular-micro-frontends/
│
├── mfe-host-2/
│   └── Angular 21
│       └── Host
│
└── mfe-remote-2/
    └── Angular 21
        └── Remote

Durante o desenvolvimento:

Host
http://localhost:4200

Remote
http://localhost:4201

O fluxo será:

                 HOST
              localhost:4200
                   │
                   │
                   ▼
       federation.manifest.json
                   │
                   │
                   ▼
              Remote :4201
                   │
                   ▼
           remoteEntry.json
                   │
                   ▼
             ./Component
                   │
                   ▼
                 App

O ponto importante é entender que o Host não importa diretamente o arquivo app.ts do Remote.

Ele conhece apenas o nome do Remote e o módulo que o Remote decidiu expor.

2. O papel do federation.config.js

No Remote temos:

const {
  withNativeFederation,
  shareAll
} = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({
  name: 'mfe-remote-2',

  exposes: {
    './Component': './src/app/app.ts',
  },

  shared: {
    ...shareAll({
      singleton: true,
      strictVersion: true,
      requiredVersion: 'auto',
    }),
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
  ],

  features: {
    ignoreUnusedDeps: true,
  },
});

Aqui temos uma das partes mais importantes da configuração:

exposes: {
  './Component': './src/app/app.ts',
}

Isso significa:

"Quando outro aplicativo solicitar ./Component, entregue o módulo localizado em ./src/app/app.ts."

O nome ./Component é um nome de exposição, não precisa ser igual ao nome do arquivo.

Por exemplo, também poderíamos ter:

exposes: {
  './Products': './src/app/pages/products/products.ts',
}

E no Host:

loadRemoteModule('mfe-remote-2', './Products')

3. `./Component` não é o nome da classe

Esse é um ponto que pode gerar bastante confusão.

Temos:

exposes: {
  './Component': './src/app/app.ts',
}

e dentro do arquivo:

export class App {
}

No Host:

loadRemoteModule('mfe-remote-2', './Component')
  .then((m) => m.App);

São três coisas diferentes:

mfe-remote-2
     │
     └── nome do Remote

./Component
     │
     └── nome da exposição

App
     │
     └── exportação JavaScript/TypeScript

Podemos visualizar assim:

Host
 │
 │ mfe-remote-2
 │
 ▼
Remote
 │
 │ ./Component
 │
 ▼
src/app/app.ts
 │
 │ export class App
 │
 ▼
m.App

Portanto, se seu componente se chama:

export class App {
}

o correto é:

.then((m) => m.App)

e não:

.then((m) => m.AppComponent)

4. O papel do federation.manifest.json

No Host criamos:

public/
└── assets/
    └── federation.manifest.json

Com:

{
  "mfe-remote-2": "http://localhost:4201/remoteEntry.json"
}

Esse arquivo funciona como um catálogo dos Remotes que o Host conhece.

Podemos ter vários:

{
  "mfe-1": "http://localhost:4201/remoteEntry.json",
  "mfe-2": "http://localhost:4202/remoteEntry.json",
  "mfe-3": "http://localhost:4203/remoteEntry.json"
}

Isso facilita bastante a configuração de uma arquitetura com vários Micro Frontends.

5. Cuidado com o caminho do manifest

No main.ts do Host:

import { initFederation } from '@angular-architects/native-federation';

initFederation('/assets/federation.manifest.json')
  .catch((err) => console.error(err))
  .then(() => import('./bootstrap'))
  .catch((err) => console.error(err));

Prefira:

/assets/federation.manifest.json

em vez de:

../assets/federation.manifest.json

O motivo é simples: o primeiro é resolvido a partir da raiz da aplicação.

Se o Host estiver rodando em:

http://localhost:4200

o navegador buscará:

http://localhost:4200/assets/federation.manifest.json

Podemos validar isso diretamente no navegador.

Se retornar:

{
  "mfe-remote-2": "http://localhost:4201/remoteEntry.json"
}

o manifest está sendo servido corretamente.

6. `remoteEntry.json` é diferente do antigo `remoteEntry.js`

Quem está acostumado com Webpack Module Federation pode estranhar isso.

No modelo tradicional era comum encontrar:

remoteEntry.js

No Native Federation trabalhamos com:

remoteEntry.json

Por exemplo:

http://localhost:4201/remoteEntry.json

Esse arquivo contém as informações necessárias para que o runtime do Native Federation descubra os módulos expostos pelo Remote.

Por isso, uma boa estratégia de debug é sempre testar:

http://localhost:4201/remoteEntry.json

Se ele não abrir, não adianta investigar a rota do Host ainda.

Primeiro precisamos resolver o Remote.

7. A rota do Host

No Angular 21 podemos utilizar componentes standalone diretamente:

import { loadRemoteModule } from '@angular-architects/native-federation';
import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: 'mfe-1',
    loadComponent: () =>
      loadRemoteModule('mfe-remote-2', './Component')
        .then((m) => m.App),
  },
];

Quando o usuário acessa:

http://localhost:4200/mfe-1

o Angular executa:

/mfe-1
   │
   ▼
loadComponent()
   │
   ▼
loadRemoteModule()
   │
   ▼
mfe-remote-2
   │
   ▼
./Component
   │
   ▼
App

8. `path` precisa bater com o link

Um erro simples, mas fácil de passar despercebido.

Se temos:

{
  path: 'mfe-2',
  loadComponent: () =>
    loadRemoteModule('mfe-remote-2', './Component')
      .then((m) => m.App),
}

o link precisa ser:

<a routerLink="/mfe-2">
  Acesse MFE-2
</a>

Não:

<a routerLink="/mfe-1">
  Acesse MFE-2
</a>

Parece óbvio, mas em uma aplicação com vários MFEs esse tipo de erro pode fazer parecer que o Federation não está funcionando.

9. Não esquecer o RouterOutlet

O Host precisa ter onde renderizar o componente remoto.

No app.html:

<div>
  <h1>Angular 21 - Micro Frontends</h1>

  <nav>
    <a routerLink="/mfe-1">
      Acesse MFE-1
    </a>

    <br />

    <a routerLink="/mfe-2">
      Acesse MFE-2
    </a>
  </nav>
</div>

<hr />

<router-outlet></router-outlet>

E como estamos usando standalone components:

import { Component } from '@angular/core';
import { RouterLink, RouterOutlet } from '@angular/router';

@Component({
  selector: 'app-root',
  imports: [
    RouterLink,
    RouterOutlet
  ],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
}

Não basta configurar:

provideRouter(routes)

Também precisamos que o template possua:

<router-outlet></router-outlet>

10. Não esquecer o `provideRouter`

No app.config.ts:

import {
  ApplicationConfig,
  provideBrowserGlobalErrorListeners
} from '@angular/core';

import { provideRouter } from '@angular/router';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideBrowserGlobalErrorListeners(),
    provideRouter(routes)
  ]
};

A cadeia completa fica:

main.ts
   │
   ▼
bootstrap
   │
   ▼
app.config.ts
   │
   ▼
provideRouter(routes)
   │
   ▼
app.routes.ts
   │
   ▼
loadRemoteModule()

Se qualquer uma dessas partes estiver faltando, a rota pode não funcionar.

11. O Remote também pode funcionar sozinho

Uma das características mais interessantes dessa arquitetura é que o Remote não precisa existir somente dentro do Host.

Podemos acessar:

http://localhost:4201/

diretamente.

O mesmo componente:

export class App {
}

pode ser usado como aplicação independente.

E também:

http://localhost:4200/mfe-1

como Micro Frontend.

Visualmente:

                    App
                     │
             ┌───────┴────────┐
             │                │
             ▼                ▼
       Acesso direto       Federation
       :4201               :4200/mfe-1

Isso é muito útil durante o desenvolvimento porque o time responsável pelo MFE pode trabalhar sem precisar subir toda a aplicação Host.

12. SSE: o que significa?

Durante o desenvolvimento podemos encontrar no terminal:

[Federation SSE] Client connected.
Active connections: 1

Isso é esperado.

SSE significa:

Server-Sent Events.

O Native Federation utiliza esse mecanismo para comunicação entre o servidor de desenvolvimento e o navegador.

Uma mensagem como:

[Federation SSE] Client connected.

significa que o navegador conseguiu estabelecer a conexão.

Portanto, essa mensagem isoladamente não representa um erro.

Se aparecer:

[Federation SSE] Client connected.

temos uma indicação positiva de que o canal de desenvolvimento foi estabelecido.

13. Como fazer troubleshooting

Quando o MFE não aparece, evite alterar várias configurações ao mesmo tempo.

Faça os testes em ordem.

Passo 1 — Remote

Abra:

http://localhost:4201/

O Remote deve funcionar sozinho.

Passo 2 — remoteEntry

Abra:

http://localhost:4201/remoteEntry.json

Deve retornar o metadata do Remote.

Passo 3 — Manifest

Abra:

http://localhost:4200/assets/federation.manifest.json

Deve retornar:

{
  "mfe-remote-2": "http://localhost:4201/remoteEntry.json"
}

Passo 4 — Host

Abra:

http://localhost:4200/

ou a rota correspondente:

http://localhost:4200/mfe-1

Passo 5 — DevTools

Abra:

F12

e verifique a aba:

Network

Procure por:

federation.manifest.json
remoteEntry.json

Se ambos carregarem, o próximo ponto a investigar é a resolução do módulo exposto.

14. Um erro importante: `404` no manifest

Um erro como:

GET http://localhost:4200/assets/federation.manifest.json 404

significa que o navegador não encontrou o manifest.

Uma configuração comum no Angular 21 é:

"assets": [
  {
    "glob": "**/*",
    "input": "public"
  }
]

Nesse caso, o arquivo precisa estar em:

public/assets/federation.manifest.json

e não necessariamente em:

src/assets/

Portanto:

mfe-host-2/
│
├── public/
│   └── assets/
│       └── federation.manifest.json
│
└── src/
    └── app/

15. CSS em Micro Frontends

Outro ponto importante é o isolamento dos estilos.

Imagine que o Remote tenha:

src/
└── app/
    ├── app.ts
    ├── app.html
    └── app.css

Podemos utilizar:

@Component({
  selector: 'app-root',
  imports: [],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
}

A recomendação para um MFE é priorizar estilos associados aos próprios componentes.

Por exemplo:

.container {
  padding: 20px;
}

.title {
  font-size: 32px;
}

Evite, quando possível, que o MFE altere globalmente:

body {
  ...
}

* {
  ...
}

html {
  ...
}

porque o Remote pode ser executado dentro de outro aplicativo.

16. Por que evitar CSS global no MFE?

Imagine:

Host
│
├── Header
├── Menu
│
└── MFE
     │
     └── styles.css

Se o MFE possui:

body {
  margin: 0;
  background: black;
}

esse estilo pode interferir na aplicação Host.

Por isso, uma boa regra é:

O Host controla o layout global da aplicação. O MFE controla o visual dos componentes que ele entrega.

Isso permite que o mesmo MFE seja executado:

localhost:4201

ou:

localhost:4200/mfe-1

sem depender de um CSS global específico do Host.

17. Um Remote pode expor mais de um componente

Não precisamos expor apenas o App.

Podemos ter:

Desacoplando Frontend com Module Federation no Angular 21 — Parte 1

Hernani Almeida — Tue, 06 Oct 2026 03:01:12 +0000

Neste artigo vamos atualizar o conceito apresentado no artigo original "Desacoplando frontend com module-federation Angular - Parte 1", adaptando o projeto para o Angular 21 e para a arquitetura moderna de Micro Frontends.

Nota: no Angular moderno, a abordagem recomendada para manter o conceito de Module Federation sem depender do Webpack é utilizar o Native Federation. Ele utiliza ES Modules, Import Maps e integra-se ao Application Builder baseado em esbuild do Angular.

O objetivo continua sendo o mesmo:

Criar uma aplicação Shell/Host;
Criar aplicações Remote/Micro Frontends;
Permitir que o Shell carregue os Micro Frontends em runtime;
Manter cada aplicação com seu próprio código e deploy;
Reduzir o acoplamento entre as aplicações.

O que são Micro Frontends?

O conceito de Micro Frontends é semelhante ao conceito de Microservices.

Em vez de termos uma única aplicação frontend grande, podemos dividir a aplicação em partes menores, cada uma responsável por uma determinada área funcional.

Por exemplo:

                    ┌─────────────────────┐
                    │      SHELL          │
                    │     Angular 21      │
                    └──────────┬──────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
              ▼                ▼                ▼
        ┌───────────┐    ┌───────────┐    ┌───────────┐
        │   MFE 1   │    │   MFE 2   │    │   MFE 3   │
        │  Crédito  │    │   Conta   │    │   Growth  │
        └───────────┘    └───────────┘    └───────────┘

Cada Micro Frontend pode possuir:

seu próprio código;
seu próprio pipeline;
seu próprio deploy;
sua própria equipe;
seu próprio ciclo de desenvolvimento.

Para o usuário final, entretanto, tudo pode aparecer como uma única aplicação.

O que mudou desde o Angular utilizado no artigo original?

No artigo original utilizamos:

Angular
   +
Webpack
   +
Module Federation
   +
AppModule
   +
AppRoutingModule

No Angular 21, temos uma arquitetura mais moderna:

Angular 21
   +
Standalone Components
   +
Application Builder / esbuild
   +
Native Federation
   +
ES Modules
   +
Import Maps

O Native Federation mantém a mesma ideia conceitual do Module Federation, mas não depende do Webpack. A implementação utiliza padrões nativos do navegador, como ES Modules e Import Maps.

Ferramentas necessárias

Para acompanhar este exemplo, recomendo:

Node.js
Angular CLI
VS Code
npm

Verifique as versões:

node -v

npm -v

ng version

Neste exemplo vamos utilizar:

Angular 21
Angular CLI 21
TypeScript compatível com Angular 21

1. Criando o workspace

Vamos criar uma pasta para nosso exemplo:

mkdir artigo-mfe

cd artigo-mfe

Agora vamos criar nossa aplicação Shell:

ng new mfe-host

Durante a criação, podemos utilizar:

Routing: Yes
Stylesheet: CSS

Entre no projeto:

cd mfe-host

Abra o projeto no VS Code:

code .

2. Criando os Micro Frontends

Vamos voltar para a pasta principal:

cd ..

Agora criaremos dois Micro Frontends:

ng new mfe-1

ng new mfe-2

Ao final teremos:

artigo-mfe/
│
├── mfe-host/
│
├── mfe-1/
│
└── mfe-2/

Nosso objetivo será:

mfe-host
   │
   ├── /mfe-1 → mfe-1
   │
   └── /mfe-2 → mfe-2

3. Configurando o MFE-1

Entre no projeto:

cd mfe-1

Agora vamos adicionar o Native Federation:

ng add @angular-architects/native-federation --project mfe-1 --port 4201 --type remote

O ng add configura automaticamente a aplicação para atuar como um Remote.

O pacote fornece integração com o Angular CLI e com o Application Builder baseado em esbuild.

4. Configurando o MFE-2

Volte para a raiz:

cd ..

Entre no segundo Micro Frontend:

cd mfe-2

Execute:

ng add @angular-architects/native-federation --project mfe-2 --port 4202 --type remote

Agora temos:

mfe-1 → http://localhost:4201

mfe-2 → http://localhost:4202

5. Configurando o Shell

Volte para a raiz:

cd ..

Entre no Shell:

cd mfe-host

Agora configuraremos o projeto como um Dynamic Host:

ng add @angular-architects/native-federation --project mfe-host --port 4200 --type dynamic-host

O dynamic-host é importante porque permite que os Micro Frontends sejam definidos através de um manifesto.

Essa abordagem também permite alterar os endpoints dos Micro Frontends durante o deploy sem precisar recompilar o Shell.

6. Estrutura do projeto

Depois da configuração teremos aproximadamente:

mfe-host/
│
├── src/
│   ├── app/
│   ├── assets/
│   │   └── federation.manifest.json
│   │
│   ├── main.ts
│   └── bootstrap.ts
│
├── federation.config.js
└── package.json

A configuração de federation ficará separada da configuração normal do Angular.

7. Configurando o MFE-1

No projeto mfe-1, teremos um arquivo:

federation.config.js

Uma configuração semelhante a:

const {
  withNativeFederation,
  shareAll,
} = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({

  name: 'mfe-1',

  exposes: {
    './Component': './src/app/app.component.ts',
  },

  shared: {
    ...shareAll({
      singleton: true,
      strictVersion: true,
      requiredVersion: 'auto',
    }),
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
  ],

});

O ponto mais importante aqui é:

exposes: {
  './Component': './src/app/app.component.ts',
}

Estamos dizendo:

Quando outro aplicativo solicitar ./Component, entregue o AppComponent deste Micro Frontend.

O host não precisa conhecer o caminho físico do arquivo.

Ele conhece apenas:

./Component

Essa é uma das ideias fundamentais da Federation.

8. Configurando o MFE-2

No projeto mfe-2, faça a mesma configuração:

const {
  withNativeFederation,
  shareAll,
} = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({

  name: 'mfe-2',

  exposes: {
    './Component': './src/app/app.component.ts',
  },

  shared: {
    ...shareAll({
      singleton: true,
      strictVersion: true,
      requiredVersion: 'auto',
    }),
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
  ],

});

Agora temos dois Remotes:

mfe-1
  └── ./Component

mfe-2
  └── ./Component

9. Configurando o Manifest

Agora vamos para o projeto:

mfe-host

Procure:

src/assets/federation.manifest.json

Configure:

{
  "mfe-1": "http://localhost:4201/remoteEntry.json",
  "mfe-2": "http://localhost:4202/remoteEntry.json"
}

O Manifest funciona como um mapa:

mfe-1 → http://localhost:4201/remoteEntry.json

mfe-2 → http://localhost:4202/remoteEntry.json

Uma diferença importante em relação ao artigo original é que agora não trabalhamos diretamente com:

remoteEntry.js

como acontecia no Module Federation baseado em Webpack.

O Native Federation utiliza metadados e módulos ES, sendo o remoteEntry.json utilizado pelo mecanismo para descobrir os recursos publicados pelo Remote.

10. Como o Manifest funciona?

O fluxo é aproximadamente:

                  Browser
                     │
                     ▼
                federation
                 manifest
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
       mfe-1                 mfe-2
          │                     │
          ▼                     ▼
 remoteEntry.json        remoteEntry.json
          │                     │
          ▼                     ▼
    Component              Component

O Shell não precisa conhecer previamente todo o código dos Micro Frontends.

Ele conhece apenas:

nome do remote
        +
endereço do remote
        +
nome do recurso exposto

11. Inicialização do Federation

O ng add também configura o processo de inicialização.

O main.ts terá uma estrutura semelhante a:

import { initFederation } from '@angular-architects/native-federation';

initFederation('/assets/federation.manifest.json')
  .catch((err) => console.error(err))
  .then(() => import('./bootstrap'))
  .catch((err) => console.error(err));

O processo é:

main.ts
   │
   ▼
initFederation()
   │
   ▼
federation.manifest.json
   │
   ├── mfe-1
   │
   └── mfe-2
   │
   ▼
bootstrap.ts
   │
   ▼
Angular Application

A inicialização do Federation acontece antes do bootstrap da aplicação Angular.

12. Configurando as rotas do Shell

Agora vamos configurar o carregamento dos Micro Frontends.

No Angular 21 podemos utilizar Standalone APIs.

Crie ou altere:

src/app/app.routes.ts

Utilize:

import { Routes } from '@angular/router';
import { loadRemoteModule } from '@angular-architects/native-federation';

export const routes: Routes = [

  {
    path: 'mfe-1',
    loadComponent: () =>
      loadRemoteModule('mfe-1', './Component')
        .then((m) => m.AppComponent),
  },

  {
    path: 'mfe-2',
    loadComponent: () =>
      loadRemoteModule('mfe-2', './Component')
        .then((m) => m.AppComponent),
  },

];

Observe a diferença em relação ao artigo original.

Antes tínhamos:

loadChildren()

AppModule

Agora podemos trabalhar diretamente com:

loadComponent()

AppComponent

Isso acontece porque o Angular moderno utiliza Standalone Components como abordagem principal.

O Native Federation suporta esse modelo diretamente.

13. Configurando o AppComponent do Shell

No:

mfe-host/src/app/app.component.html

podemos utilizar:

<div>
  <h1>Angular 21 - Micro Frontends</h1>

  <nav>
    <a routerLink="/mfe-1">
      Acesse MFE-1
    </a>

    <br />

    <a routerLink="/mfe-2">
      Acesse MFE-2
    </a>
  </nav>
</div>

<hr />

<router-outlet></router-outlet>

Agora teremos:

Angular 21 - Micro Frontends

Acesse MFE-1

Acesse MFE-2

14. Configurando o MFE-1

Vamos alterar o componente do mfe-1.

Por exemplo:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div>
      <h2>MFE-1</h2>

      <p>
        Este conteúdo foi carregado remotamente.
      </p>
    </div>
  `,
})
export class AppComponent {
}

15. Configurando o MFE-2

No mfe-2:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div>
      <h2>MFE-2</h2>

      <p>
        Este conteúdo também foi carregado remotamente.
      </p>
    </div>
  `,
})
export class AppComponent {
}

16. Subindo os projetos

Agora precisamos executar os três projetos.

Terminal 1 — MFE-1

cd mfe-1

ng serve

Aplicação:

http://localhost:4201

Terminal 2 — MFE-2

cd mfe-2

ng serve

Aplicação:

http://localhost:4202

Terminal 3 — Shell

cd mfe-host

ng serve

Aplicação:

http://localhost:4200

17. Testando

Abra:

http://localhost:4200

Clique:

Acesse MFE-1

O Shell irá executar:

loadRemoteModule('mfe-1', './Component')

O Native Federation irá localizar:

mfe-1

no:

federation.manifest.json

e descobrir:

http://localhost:4201/remoteEntry.json

Depois carregará:

./Component

que aponta para:

mfe-1/src/app/app.component.ts

O resultado será:

┌──────────────────────────────────┐
│          MFE-HOST                │
│                                  │
│  Acesse MFE-1                    │
│  Acesse MFE-2                    │
│                                  │
│  ┌────────────────────────────┐  │
│  │           MFE-1            │  │
│  │                            │  │
│  │ Conteúdo carregado         │  │
│  │ remotamente                │  │
│  └────────────────────────────┘  │
│                                  │
└──────────────────────────────────┘

18. O que está acontecendo por baixo?

Quando acessamos:

http://localhost:4200/mfe-1

o Angular Shell não possui necessariamente o código do mfe-1 no bundle inicial.

O fluxo é:

Browser
   │
   ▼
Angular Shell
   │
   ▼
Router
   │
   ▼
loadRemoteModule()
   │
   ▼
federation.manifest.json
   │
   ▼
mfe-1
   │
   ▼
remoteEntry.json
   │
   ▼
./Component
   │
   ▼
AppComponent

Isso permite que o Micro Frontend seja desenvolvido e publicado separadamente.

19. Compartilhamento de dependências

Outro ponto importante da Federation é o compartilhamento de dependências.

Nossa configuração possui:

shared: {
  ...shareAll({
    singleton: true,
    strictVersion: true,
    requiredVersion: 'auto',
  }),
}

Isso permite compartilhar bibliotecas entre o Shell e os Micro Frontends.

Por exemplo:

Shell
 └── Angular

MFE-1
 └── Angular

MFE-2
 └── Angular

Em vez de necessariamente carregar múltiplas cópias das mesmas dependências, o Federation pode compartilhar essas bibliotecas.

O singleton: true é especialmente importante para bibliotecas que devem possuir uma única instância no runtime, como as principais bibliotecas do Angular.

20. Por que utilizar Native Federation no Angular 21?

No artigo original utilizamos:

Webpack Module Federation

Essa abordagem continua sendo importante e o ecossistema de Module Federation continua evoluindo.

Porém, para um projeto novo utilizando Angular 21, o Native Federation é uma opção muito interessante porque:

integra-se ao Application Builder do Angular;
utiliza esbuild;
trabalha com ES Modules;
utiliza Import Maps;
não depende diretamente do Webpack;
mantém o modelo mental do Module Federation;
suporta Standalone Components;
suporta SSR;
possui versões alinhadas às versões do Angular.

21. Estrutura final

Ao final desta primeira parte teremos:

artigo-mfe/
│
├── mfe-host/
│   │
│   ├── src/
│   │   ├── app/
│   │   │   ├── app.component.ts
│   │   │   └── app.routes.ts
│   │   │
│   │   ├── assets/
│   │   │   └── federation.manifest.json
│   │   │
│   │   ├── main.ts
│   │   └── bootstrap.ts
│   │
│   ├── federation.config.js
│   └── package.json
│
├── mfe-1/
│   │
│   ├── src/
│   │   └── app/
│   │       └── app.component.ts
│   │
│   ├── federation.config.js
│   └── package.json
│
└── mfe-2/
    │
    ├── src/
    │   └── app/
    │       └── app.component.ts
    │
    ├── federation.config.js
    └── package.json

Conclusão

Neste artigo configuramos uma arquitetura de Micro Frontends utilizando Angular 21 + Native Federation.

Criamos:

                 Angular 21
                     │
                     ▼
              ┌─────────────┐
              │    HOST     │
              │    :4200    │
              └──────┬──────┘
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
   ┌─────────────┐       ┌─────────────┐
   │    MFE-1    │       │    MFE-2    │
   │    :4201    │       │    :4202    │
   └─────────────┘       └─────────────┘

O Shell é responsável pela experiência principal da aplicação, enquanto os Micro Frontends podem ser desenvolvidos e publicados de forma independente.

Na próxima parte podemos avançar para uma arquitetura mais próxima de um cenário real, trabalhando com:

múltiplas páginas dentro de cada Micro Frontend;
loadChildren() com rotas remotas;
comunicação entre Shell e Micro Frontends;
compartilhamento de serviços;
autenticação;
Angular Material;
gerenciamento de estado;
deploy independente;
ambientes DEV, HML e PROD;
versionamento dos Micro Frontends;
tratamento de indisponibilidade de um Remote;
arquitetura recomendada para projetos corporativos.

Troubleshooting — Problemas na instalação do Native Federation

Durante a configuração do Native Federation, o comando apresentado no artigo pode apresentar erro dependendo da versão do Angular instalada no ambiente.

O comando inicial utilizado no artigo é:

ng add @angular-architects/native-federation --project mfe-remote-2 --port 4201 --type remote

Em alguns ambientes, o Angular CLI pode não conseguir encontrar automaticamente uma versão compatível do pacote.

Um exemplo de erro é:

Could not find a compatible version with `latest`.
Searching for a compatible version.

Cannot read properties of undefined (reading 'latest')

An unhandled exception occurred:
Cannot read properties of undefined (reading 'latest')

Esse problema está relacionado à resolução automática da versão do pacote e não necessariamente a um problema no projeto Angular.

1. Verifique a versão do Angular

Antes de corrigir o problema, execute:

ng version

Por exemplo:

Angular CLI       : 21.2.25
Angular           : 21.2.25
Node.js           : 24.15.0
Package Manager   : npm 12.2.0

A versão do Angular deve ser utilizada para escolher uma versão compatível do Native Federation.

2. Instale uma versão compatível manualmente

Caso o ng add apresente o erro descrito acima, em vez de utilizar o latest, instale explicitamente uma versão compatível.

Para um projeto utilizando Angular 21.2.x, por exemplo:

npm install @angular-architects/native-federation@21.2.6 --save-dev

Depois execute o schematic:

ng generate @angular-architects/native-federation:init \
  --project mfe-remote-2 \
  --port 4201 \
  --type remote

No Windows/Git Bash, o comando também pode ser executado em uma única linha:

ng generate @angular-architects/native-federation:init --project mfe-remote-2 --port 4201 --type remote

3. Regra geral

A ideia é utilizar uma versão do Native Federation compatível com a versão principal do Angular do projeto.

Por exemplo:

Angular 21.x
     ↓
Native Federation 21.x

Portanto, se estiver utilizando outra versão do Angular, primeiro verifique:

ng version

e então consulte a versão do @angular-architects/native-federation compatível com essa versão.

Evite simplesmente instalar a versão latest quando o Angular CLI não conseguir determinar automaticamente uma versão compatível.

4. Caso tenha instalado uma versão incorreta

Se uma tentativa anterior instalou uma versão incompatível, remova o pacote:

npm uninstall @angular-architects/native-federation

Limpe a instalação:

rm -rf node_modules package-lock.json

No Windows PowerShell, utilize:

Remove-Item -Recurse -Force node_modules
Remove-Item package-lock.json

Depois reinstale as dependências:

npm install

E instale novamente a versão compatível:

npm install @angular-architects/native-federation@21.2.6 --save-dev

Por fim:

ng generate @angular-architects/native-federation:init --project mfe-remote-2 --port 4201 --type remote

5. Resumo

Se o comando original funcionar:

ng add @angular-architects/native-federation --project mfe-remote-2 --port 4201 --type remote

continue normalmente com o tutorial.

Caso apareça:

Could not find a compatible version with `latest`

faça:

ng version

identifique a versão do Angular e instale manualmente uma versão compatível do Native Federation:

npm install @angular-architects/native-federation@<versao-compativel> --save-dev

e execute o schematic:

ng generate @angular-architects/native-federation:init \
  --project mfe-remote-2 \
  --port 4201 \
  --type remote

Importante: as versões dos pacotes podem mudar ao longo do tempo. Portanto, sempre verifique a compatibilidade entre a versão do Angular instalada no projeto e a versão do Native Federation utilizada.

Link parte 2

Referências

Artigo original: Desacoplando frontend com module-federation Angular - Parte 1.

Angular Architects — Micro Frontends with Modern Angular.

Angular Architects — Native Federation.

Documentação do @angular-architects/native-federation.

Implementando Singleton, Factory e Observer com novas features versoes recentes Java

Hernani Almeida — Sun, 13 Apr 2025 21:41:51 +0000

Neste post vamos aprender 3 dos design patterns essenciais para o desenvolvimento de software utilizando a linguagem ´Java´ e novas features adicionadas na versão 21 e 24 do java.
Este projeto simula um sistema de cadastro de usuários, utilizando os padrões de design Singleton, Factory e Observer. Cada padrão foi escolhido para resolver problemas específicos dentro da arquitetura.
Primeiro criamos a classe UsuarioController que tera a responsabilidade de expor nossa api para ser acessada via rest através do meto http POST.
UsuarioController

package com.designpatterns.application.controller;

import com.designpatterns.application.mapper.input.UsuarioRequest;
import com.designpatterns.application.mapper.output.UsuarioResponse;
import com.designpatterns.core.usuario.UsuarioService;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class UsuarioController {
    private final UsuarioService usuarioService;

    public UsuarioController(UsuarioService usuarioService) {
        this.usuarioService = usuarioService;
    }

    @PostMapping("usuario")
    public UsuarioResponse cadastraUsuario(@RequestBody UsuarioRequest request) {
        return usuarioService.createUser(request.converteUsuario()).converteResponse();
    }
}

A classe UsuarioController depende de um objeto do tipo UsuarioService para realizar suas operações. Em vez de criar diretamente uma instância de UsuarioService (o que resultaria em alto acoplamento), definimos essa dependência como um parâmetro no construtor utilizando a injeção de dependência do spring, quando o Spring Container detecta essa classe, ele identifica o construtor e injeta automaticamente uma instância de UsuarioService, que já foi configurada no contexto da aplicação (geralmente definida como um Bean no Spring).
Observação: Nesse momento já estamos utilizando o design pattern Singleton pois o Spring fornece essa instância única em toda a aplicação, que já foi criada e gerenciada pelo Container Spring, caso fosse necessário que tivesses uma classe nova todas as vezes que instanciada em um constructor e necessário utilizarmos a annotation @Scope("prototype") para referenciar esse contexto ao Spring conforme a imagem abaixo.

Logo mais veremos outra forma de utilizar o design pattern Singleton.
UsuarioService

package com.designpatterns.core.usuario;

import org.springframework.context.ApplicationEventPublisher;
import org.springframework.stereotype.Service;

@Service
public class UsuarioService {
    private final ApplicationEventPublisher eventPublisher;

    public UsuarioService(ApplicationEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }


    public Usuario createUser(Usuario usuario) {
        System.out.println("Usuário cadastrado com sucesso: " + usuario.nome());
        eventPublisher.publishEvent(new UsuarioCadastradoEvent(this, usuario));
        return usuario;
    }
}

Dentro da nossa classe de serviço UsuarioService encontramos outro design pattern que podemos utilizar, o Observer.
O Observer é utilizado para desacoplar o envio de notificações do fluxo de cadastro de usuário. Quando um usuário é cadastrado, múltiplos observadores podem reagir a esse evento de maneira independente.
Temos injetado em nossa classe de serviço a classe ApplicationEventPublisher que é uma interface do Spring Framework responsável por publicar eventos dentro do contexto da aplicação, nos permitindo que o UsuarioService publique eventos de forma desacoplada. Ou seja, o service não precisa conhecer diretamente os objetos que vão reagir ao evento.
OBS: A implementação do padrão Observer utilizando o ApplicationEventPublishere uma abordagem moderna e desacoplada provida pelo Spring. Com isso, sempre que um novo usuário é cadastrado, um evento do tipo UsuarioCadastradoEvent é publicado.

Esse evento sera tratado pela classe UsuarioEventListener, que atua como "observador", reagindo ao evento publicado para enviar notificações com base na preferência do usuário (SMS ou E-mail).

Essa abordagem traz os benefícios do padrão Observer (desacoplamento e reatividade), utilizando os recursos do próprio Spring.

Nesse caso, ela dispara o evento UsuarioCadastradoEvent com o usuário recém-criado. O Spring então notifica automaticamente qualquer classe anotada com @EventListener e que esteja ouvindo esse tipo de evento.
Vamos criar entao a classe UsuarioCadastradoEvent e também o listener responsável por ouvir esse evento e implementar o envio de notificação de email/sms.
UsuarioCadastradoEvent

package com.designpatterns.core.usuario;

import org.springframework.context.ApplicationEvent;

public class UsuarioCadastradoEvent extends ApplicationEvent {

    private final Usuario usuario;
    public UsuarioCadastradoEvent(Object source, Usuario usuario) {
        super(source);
        this.usuario = usuario;
    }

    public Usuario getUsuario() { return usuario; }
}

UsuarioEventListener

package com.designpatterns.core.usuario;

import com.designpatterns.core.notification.EmailNotification;
import com.designpatterns.core.notification.NotificationFactory;
import com.designpatterns.core.notification.SmsNotification;
import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Component;

@Component
public class UsuarioEventListener {
    private final NotificationFactory factory;

    public UsuarioEventListener(NotificationFactory factory) {
        this.factory = factory;
    }

    @EventListener
    public void handle(UsuarioCadastradoEvent event) {
        Usuario usuario = event.getUsuario();
        factory.getNotificationsFor(usuario.preferencia())
               .forEach(n -> {
                   if (n instanceof EmailNotification email) {
                       email.notificate(usuario, "E-mail: Bem-vindo, " + usuario.nome() + "!");
                   } else if (n instanceof SmsNotification sms) {
                       sms.notificate(usuario, "SMS: Bem-vindo, " + usuario.nome() + "!");
                   }
               });
    }
}

Observação: Note que utilizamos o instanceof com pattern matching, o uso de pattern matching com instanceof facilita muito o código ao evitar castings explícitos. Isso torna o código mais legível, seguro e moderno, nos permitindo acessar diretamente a instância com cast implícito e mais legibilidade sendo muito útil quando queremos tratar notificações de forma personalizada por tipo uma das melhorias de linguagem do Java 24

Queremos em nosso sistema notificar o usuário via email e sms que o cadastro foi efetuado com sucesso.
Vamos utilizar um novo design pattern dentro da classe que esta ouvindo o email através da classe NotificationFactory
No projeto, a classe NotificationFactory contem instâncias de diferentes tipos de notificadores, como EmailNotification e SmsNotification, sem que o código cliente precise conhecer os detalhes específicos de cada implementação. Isso é alcançado através do design pattern Factory, que promove a criação de objetos de forma encapsulada e flexível.

🧱 Factory Pattern com switch expression e Injeção de Dependência
Aqui, vamos implementar uma Factory que retorna uma lista de notificações com base na preferência do usuário, como Email, SMS, ou ambos. Vamos usar o padrão Factory para encapsular a lógica de criação dessas instâncias.
NotificationFactory

package com.designpatterns.core.notification;

import org.springframework.stereotype.Component;

import java.util.List;

@Component
public class NotificationFactory {

    private final EmailNotification email;
    private final SmsNotification sms;

    public NotificationFactory(EmailNotification email, SmsNotification sms) {
        this.email = email;
        this.sms = sms;
    }
    public List<Notification> getNotificationsFor(String preferencia) {
        return switch (preferencia.toLowerCase()) {
            case "email" -> List.of(email);
            case "sms" -> List.of(sms);
            case "ambos" -> List.of(email, sms);
            default -> List.of();
        };
    }
}

🏭 O que essa Factory faz?
A NotificationFactory decide, com base na preferência do usuário (se ele deseja receber notificações por email, SMS ou ambos), qual(is) instância(s) de notificação retornar. A implementação do switch expression torna o código mais limpo, sem a necessidade de múltiplos if ou else.

💡 O que foi aplicado de moderno aqui?
Injeção de Dependência com Spring (@Component): As instâncias de EmailNotification e SmsNotification são injetadas automaticamente pelo Spring, facilitando o gerenciamento das dependências.

switch expression (Java 14+): Melhorias no Java que tornam a seleção de valores mais legível e com menos código boilerplate, comparado ao switch tradicional.

✅ Exemplo de uso da Factory:

NotificationFactory factory = new NotificationFactory(email, sms);
List<Notification> notifications = factory.getNotificationsFor("ambos");

notifications.forEach(notification -> notification.send());

🔄 O que mais podemos fazer?
Flexibilidade: Caso surjam novos tipos de notificação, como Push ou WhatsApp, podemos facilmente estender a Factory para lidar com esses novos tipos.

Extensibilidade: Adicionar novas opções ao método getNotificationsFor se torna trivial, mantendo o código limpo e expansível.

Observação: Criaremos a interface Notification e as classes EmailNotification e 'SmsNotification' que implementam essa interface.

No projeto, usamos a seguinte construção moderna das versões recentes do java para criar a interface Notification

Essa linha define uma interface selada (sealed interface), que traz uma poderosa funcionalidade: restringir quais classes podem implementar ou estender a interface.

Notification

package com.designpatterns.core.notification;

import com.designpatterns.core.usuario.Usuario;

public sealed interface Notification permits EmailNotification, SmsNotification {
    void notificate(Usuario usuario, String mensagem);
}

Agora vamos criar as classes EmailNotification e SmsNotification que implementam a interface Notification e através do método notificate enviam a mensagem ao usuário.
EmailNotification

package com.designpatterns.core.notification;

import com.designpatterns.core.usuario.Usuario;
import org.springframework.stereotype.Component;

@Component
public final class EmailNotification implements Notification {
    public void notificate(Usuario usuario, String mensagem) {
        System.out.printf("Enviando EMAIL para %s (%s): %s%n",
                usuario.nome(), usuario.email(), mensagem);
    }
}

SmsNotification

package com.designpatterns.core.notification;

import com.designpatterns.core.usuario.Usuario;
import org.springframework.stereotype.Component;

@Component
public final class SmsNotification implements Notification {
    public void notificate(Usuario usuario, String mensagem) {
        System.out.printf("Enviando SMS para %s (%s): %s%n",
                usuario.nome(), usuario.telefone(), mensagem);
    }
}

Podemos agora testar nossa aplicação e validar o envio das notificações de email e sms quando um usuário e cadastrado.

Este projeto demonstra como combinar design patterns clássicos com os novos recursos das versoes mais recentes do Java, usando um sistema simples de cadastro de usuários com notificações via e-mail e SMS.

🔧 Padrões Utilizados

🔒 Singleton

O padrão Singleton foi aplicado com o uso do Spring Boot para garantir que o serviço UsuarioService tenham apenas uma instância durante todo o ciclo de vida da aplicação.

🏭 Factory

Utilizamos uma NotificationFactory para encapsular a criação das instâncias de notificações (EmailNotification e SmsNotification) com base em um tipo definido na escolha do usuario.

👀 Observer

O padrão Observer permite que diferentes canais de notificação sejam observadores do evento de cadastro de usuário. Assim, sempre que um novo usuário é registrado, todos os canais registrados recebem a notificação.

🆕 Features das versoes recentes do Java

sealed interface: restringe quais classes podem implementar uma interface, trazendo mais segurança e controle ao design.
Pattern matching com instanceof: permite validações de tipo mais limpas e seguras.
switch com enum: possibilita o tratamento completo dos tipos permitidos com checagem de exaustividade pelo compilador.

📦 Classes Principais

Usuario: representa o modelo de dados do usuário, contendo informações como nome e preferência de notificação (e-mail ou SMS).
Notification: interface selada (sealed interface) que define o contrato para os tipos de notificação. Ela é implementada por:
- EmailNotification: responsável por enviar notificações por e-mail.
- SmsNotification: responsável por enviar notificações via SMS.
NotificationFactory: aplica o padrão Factory, sendo responsável por fornecer a instância correta de Notification com base na preferência informada pelo usuário (por exemplo, "email" ou "sms").
NotificationService: atua como publisher de eventos no padrão Observer moderno via ApplicationEventPublisher, enviando eventos de forma desacoplada para serem tratados por listeners.
UsuarioService: encapsula a lógica de cadastro de usuários e é responsável por acionar a notificação através da publicação de um evento (UsuarioCadastradoEvent) que será capturado posteriormente pelo listener.
UsuarioEventListener: classe que observa os eventos de usuários cadastrados. Utiliza pattern matching com switch para tratar dinamicamente o tipo de notificação a ser enviada, de forma segura e moderna.
UsuarioCadastradoEvent: classe que representa o evento de domínio publicado após o cadastro de um novo usuário. Contém os dados do usuário para consumo pelos observers.

✅ Conclusão

A combinação dos padrões de projeto com os novos recursos das recentes versões do Java trouxe maior robustez, legibilidade e extensibilidade ao projeto. Essa abordagem é ideal para arquiteturas modernas e escaláveis.

O projeto está disponível no GitHub. Sua estrela é muito bem-vinda se você achou o conteúdo relevante:
🔗 DesignPatterns
Desenvolvido para fins educacionais por Hernani Almeida

Solucionar erro imagem module-federation

Hernani Almeida — Tue, 10 Dec 2024 00:07:29 +0000

Este artigo visa corrigir o erro que temos quando utilizamos module-federation para configurar aplicações micro-frontends com angular
Resumindo o erro ocorre pois quando rodamos as aplicações e o angular vai buscar o path da imagem, automaticamente, ele assume o path do host como base e, caso a imagem não esteja alocada no host, não encontra o caminho da imagem.
Isso pode interferir nas vantagens de uso do microfrontend que seriam:

Independência Total: Cada equipe poder trabalhar em um microfrontend de forma autônoma, pois no caso de imagens teriam que estar adicionando a imagem na aplicação host.
Deploy Independente: Cada microfrontend poder ser deployado de forma independente, pois sempre haverá a dependência de deploy da app host em caso de mudar ou adicionar imagens. Veja este exemplo, tenho na aplicação MFE a imagem e o path da imagem passado de maneira correta.

Porem quando acesso a aplicação rodando recebo um erro 404 ao buscar o caminho da imagem

Note na imagem que a aplicação utilizou o base path da aplicação host para buscar a imagem http://localhost:4200/, onde não temos a imagem alocada, por isso recebemos o erro.

Bora lá resolver isso então, vamos criar um pipe UrlFormatterPipe na aplicação mfe para forçarmos o angular utilizar o path correto ao buscar a imagem.

import { Pipe, PipeTransform } from '@angular/core';

@Pipe({
  name: 'urlFormatter'
})
export class UrlFormatterPipe implements PipeTransform {

  transform(value: string): string {
    return __webpack_public_path__ + value;
  }

}

Resumindo o que estamos fazendo no pipe e buscar o path publico da aplicação mfe através da variável global webpack_public_path (ou seja mesmo em ambiente produtivo ira nos retornar o base path da aplicação mfe rodando) e concatenamos com o path da imagem que recebemos dentro do parametro value.
Vamos utilizar o pipe no path da imagem agora e ver o resultado.

Voalá imagem apareceu com sucesso e podemos confirmar no devTools que o base path esta vindo da aplicação mfe

E isso ai devs mas um conhecimento passado, deixarei aqui link do artigo que mostro como configurar um micro frontend angular utilizando module federation, aplicação utilizada para explicar a correção do path da imagem, e link do repositório no meu github para quem quiser acessar o projeto
Deixo aqui também meu linkedin e instagram para quem quiser me adicionar, grato a todos que leram este artigo e bora aprender galera.

Api Rest .Net completa com JwtToken integração com api ViaCep utilizando padrão de arquitetura clean architecture - parte 3

Hernani Almeida — Thu, 01 Aug 2024 02:57:04 +0000

Ferramentas necessárias:

Seguimos com a construção da nossa api, neste artigo vamos estruturar a parte de segurança de nossa api, bloqueando acesso de quem não esta autenticado ou sem autorização para acessar algum recurso.
Para realizar essa proteção vamos utilizar a autenticação via JWT JSON WEB TOKEN bora la.
Para iniciar vamos instalar as bibliotecas necessárias, conforme vimos nos artigos anteriores vamos utilizar o gerenciador de pacotes do Nuget

Dentro do gerenciador busque e instale essas duas bibliotecas

Feito isso, dentro da pasta Controllers que fica na camada de Infrastructure de nossa api (vide artigo 1 para entender a definição da arquitetura escolhida) vamos proteger nossas classes de acesso conforme imagem abaixo.

Observação: Como passamos a anotação [Authorize(Roles = "ADMIN")] acima do nome da nossa classe isso faz com que todos os endpoints de acesso sejam protegidos, atraves do JWTToken e a role de permissão concedida ao usuario, caso passemos a anotação acima de um método especifico dentro da nossa classe (conforme imagem abaixo) apenas esse método será protegido o acesso.

Feito isso e necessário mais uma configuração dentro na nossa classe Program.cs, dentro do metodo Main vamos instanciar uma variável secretKey, essa assinatura é utilizada para garantir a integridade do token, no caso, se ele foi modificado e se realmente foi gerado por você, você pode gerar um Guid para garantir a integridade dessa chave e que ninguem a conheça para decodificar seu token.

Logo acima da configuração app.UseAuthorization() instancia a config app.UseAuthentication()

Agora adicionamos a configuração para geração do token conforme imagem abaixo.

ValidateIssuer = true: Configura que na geração do token seja validado se o Issuer contido no token e igual ao que passamos na config ValidIssuer.
ValidateAudience= true: : Configura que na geração do token seja validado se o Audience contido no token e igual ao que passamos na config ValidAudience.
ValidateLifetime = true: Configura a validação de expiração do token gerado.
ValidateIssuerSigningKey: Valida se a chave secreta contida na geração do token e a mesma que passamos na variavel secretKey

Nossa classe Main ficara conforme abaixo:


using FirstApi.Application.UseCases.CasesEmployer.ConsultEmployer;
using FirstApi.Application.UseCases.CasesEmployer.DeleteEmployer;
using FirstApi.Application.UseCases.CasesEmployer.Register;
using FirstApi.Application.UseCases.CasesEmployer.UpdateEmployer;
using FirstApi.Application.UseCases.CasesUser.ConsultUser;
using FirstApi.Application.UseCases.CasesUser.DeleteUser;
using FirstApi.Application.UseCases.CasesUser.RegisterUser;
using FirstApi.Application.UseCases.CasesUser.UpdateUser;
using FirstApi.Application.UseCases.PasswordHasher;
using FirstApi.Domain.Repositories;
using FirstApi.Infrastructure.Data;
using FirstApi.Infrastructure.Handler;
using FirstApi.Infrastructure.Integration.ViaCep;
using FirstApi.Infrastructure.Integration.ViaCep.Refit;
using FirstApi.Infrastructure.Repositories;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.EntityFrameworkCore;
using Microsoft.IdentityModel.Tokens;
using Refit;
using System.Text;

namespace FirstApi
{
    public class Program
    {

        public static void Main(string[] args)
        {
            string secretKey = "e0606215-c2e4-46fe-8d73-a77e1fa4f45a";
            var builder = WebApplication.CreateBuilder(args);
            // Configure logging
            builder.Logging.ClearProviders();
            builder.Logging.AddConsole();
            builder.Logging.AddDebug();
            // Configure data base access
            builder.Services.AddDbContext<SystemDbContext>(
                options => options.UseNpgsql(builder.Configuration.GetConnectionString("DefaultConnection")));
            // Add repositories to the container.
            builder.Services.AddScoped<IEmployerRepository, EmployerRepository>();
            builder.Services.AddScoped<IUserRepository, UserRepository>();
            // Add services to the container.
            // employer
            builder.Services.AddScoped<IRegisterEmployerService, RegisterEmployerService>();
            builder.Services.AddScoped<IUpdateEmployerService, UpdateEmployerService>();
            builder.Services.AddScoped<IConsultEmployerService, ConsultEmployerService>();
            builder.Services.AddScoped<IDeleteEmployerService, DeleteEmployerService>();
            // user
            builder.Services.AddScoped<IRegisterUserService, RegisterUserService>();
            builder.Services.AddScoped<IUpdateUserService, UpdateUserService>();
            builder.Services.AddScoped<IConsultUserService, ConsultUserService>();
            builder.Services.AddScoped<IDeleteUserService, DeleteUserService>();
            builder.Services.AddScoped<IPasswordHasher, PasswordHasher>();
            // client viacep
            builder.Services.AddScoped<IViaCepIntegrationService, ViaCepIntegrationService>();
            // Add client refit
            builder.Services.AddRefitClient<IViaCepIntegrationRefit>().ConfigureHttpClient(c =>
            {
                c.BaseAddress = new Uri("https://viacep.com.br");
            }
            );

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            // Config authentication
            builder.Services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            }).AddJwtBearer(options =>
            {
                options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters()
                {
                    ValidateIssuer = true,
                    ValidateAudience= true,
                    ValidateLifetime = true,
                    ValidateIssuerSigningKey = true,
                    ValidIssuer = "emprise",
                    ValidAudience = "firstApi",
                    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(secretKey))
                };
            });

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();
            app.UseAuthentication();
            app.UseAuthorization();

            // global error handler
            app.UseMiddleware<GlobalExceptionHandler>();

            app.MapControllers();

            app.Run();
        }
    }
}

Pronto nossa api ja esta protegida, se fizermos um request sem passar o token de acesso vamos receber um status code 401.

Vamos agora implementar um endpoint para criar um login e gerar um JsonToken para acessarmos nossa api, na nossa camada Application vamos criar um caso de uso PasswordHasher responsavel por criptografar o password do usuario e armazenar banco de dados e mais um caso de uso chamado Login conforme imagens abaixo.

IPasswordHasher

namespace FirstApi.Application.UseCases.PasswordHasher
{
    public interface IPasswordHasher
    {
        public string Hash(string password);

        public bool Verify(string passwordHash, string password);
    }
}

PasswordHasher

using System.Security.Cryptography;

namespace FirstApi.Application.UseCases.PasswordHasher
{
    public class PasswordHasher : IPasswordHasher
    {
        private int SaltSize = 128 / 8;
        private int KeySize = 256 / 8;
        private int Iterations = 10000;
        private static HashAlgorithmName _hash = HashAlgorithmName.SHA256;
        private char Delimiter = ';'; 
        string IPasswordHasher.Hash(string password)
        {
            var salt = RandomNumberGenerator.GetBytes(SaltSize);
            var hash = Rfc2898DeriveBytes.Pbkdf2(password, salt, Iterations,_hash, KeySize);
            return string.Join(Delimiter, Convert.ToBase64String(salt), Convert.ToBase64String(hash));
        }

        bool IPasswordHasher.Verify(string passwordHash, string password)
        {
            var elements = passwordHash.Split(Delimiter);
            var salt = Convert.FromBase64String(elements[0]);
            var hash = Convert.FromBase64String(elements[1]);
            var hashInput = Rfc2898DeriveBytes.Pbkdf2(password, salt, Iterations, _hash, KeySize);
            return CryptographicOperations.FixedTimeEquals(hash, hashInput);
        }
    }
}

ILoginService

namespace FirstApi.Application.UseCases.CasesAuth.Login
{
    public interface ILoginService
    {
        public LoginOutput Execute(LoginInput input);
    }
}

LoginService

using FirstApi.Application.UseCases.PasswordHasher;
using FirstApi.Domain.Entities;
using FirstApi.Domain.Enums;
using FirstApi.Domain.Repositories;
using FirstApi.Infrastructure.CustomException;
using Microsoft.IdentityModel.Tokens;
using System.IdentityModel.Tokens.Jwt;
using System.Linq;
using System.Security.Claims;
using System.Text;

namespace FirstApi.Application.UseCases.CasesAuth.Login
{
    public class LoginService : ILoginService
    {
        private readonly IUserRepository _userRepository;
        private readonly IPasswordHasher _passwordHasher;

        public LoginService(IUserRepository userRepository, IPasswordHasher passwordHasher)
        {
            _userRepository = userRepository;
            _passwordHasher = passwordHasher;
        }

        LoginOutput ILoginService.Execute(LoginInput input)
        {
            User user = _userRepository.FindUserByEmail(input.Email).Result;
            if (user == null || user.Password == null || user.Email == null)
            {
                throw new AppNotFoundException("Credenciais Invalidas teste");
            }

            if (_passwordHasher.Verify(user.Password, input.Password))
            {
                return new LoginOutput().Convert(user, this.generateJwtToken(user.Roles));
            }

            throw new BadHttpRequestException("Credenciais Invalidas");

        }

        private string generateJwtToken(List<Roles> roles)
        {
            string secretKey = "e0606215-c2e4-46fe-8d73-a77e1fa4f45a";
            var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(secretKey));
            var claims = new List<Claim>
            {
                new Claim("login","admin"),
                new Claim("name", "System Administrator")
            };

            claims.AddRange(roles.Select(role => new Claim(ClaimTypes.Role, role.ToString())));

            var token = new JwtSecurityToken(
                issuer: "emprise",
                audience: "firstApi",
                claims: claims,
                expires: DateTime.UtcNow.AddHours(2),
                signingCredentials: new SigningCredentials(key, SecurityAlgorithms.HmacSha256)
                );

            return new JwtSecurityTokenHandler().WriteToken(token);
        }
    }
}

LoginInput

namespace FirstApi.Application.UseCases.CasesAuth.Login
{
    public class LoginInput
    {
        public required string Email { get; set; }
        public required string Password { get; set; }


    }
}

LoginOutput

using FirstApi.Domain.Entities;

namespace FirstApi.Application.UseCases.CasesAuth.Login
{
    public class LoginOutput
    {
        public int Id { get; set; }
        public string? UserName { get; set; }
        public string? AccessToken { get; set; }

        internal LoginOutput Convert(User user, string token)
        {
            Id = user.Id;
            UserName = user.Name;
            AccessToken = token;
            return this;
        }
    }
}

Obs: Duvida sobre a implementação veja a primeira parte do artigo pois explico a responsabilidade de cada classe construido dentro do caso de uso.

Será necessário também mudarmos nossa entity User.cs pois precisamos adicionar uma lista de Roles para cada usuário salvo que será as permissões de acessos que esse usuário possui mesmo tendo um token JwtToken gerado.
Mude a classe User.cs para que fique assim

using FirstApi.Domain.Enums;
using FirstApi.Domain.ValueObjects;
using FirstApi.Infrastructure.Integration.ViaCep;

namespace FirstApi.Domain.Entities
{
    public class User
    {
        public int Id { get; set; }
        public string? Name { get; set; }
        public string? Email { get; set; }
        public string? Password { get; set; }
        public List<Roles>? Roles { get; set; }
        public Endereco? Endereco { get; set; }

        public Endereco GetEndereco(ViaCepResponse response)
        {
            Endereco endereco = new Endereco();
            if(response is null)
            {
                return endereco;
            }
            endereco.Complemento = response.Complemento;
            endereco.Cep = response.Cep;
            endereco.Bairro = response.Bairro;
            endereco.Logradouro = response.Logradouro;
            endereco.Localidade = response.Localidade;
            endereco.Cep = response.Cep;
            endereco.Unidade = response.Unidade;
            endereco.Uf = response.Uf;
            return endereco;
        }
    }
}

Crie o enum contendo as roles de permissões que seu sistema possui conforme exemplo abaixo.

Obs: Como estamos mudando nossa entity será necessário mudar o mapeamento dessa tabela na classe UserMap.cs.

UserMap

using FirstApi.Domain.Entities;
using FirstApi.Domain.Enums;
using FirstApi.Domain.ValueObjects;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;
using Microsoft.EntityFrameworkCore.Storage.ValueConversion;

namespace FirstApi.Infrastructure.Data.Map
{
    public class UserMap : IEntityTypeConfiguration<User>
    {
        public void Configure(EntityTypeBuilder<User> builder)
        {
           var userRolesConverter = new ValueConverter<List<Roles>, string>(
           v => string.Join(',', v.Select(e => e.ToString())),
           v => v.Split(new[] { ',' }, StringSplitOptions.None)
           .Select(e => (Roles)Enum.Parse(typeof(Roles), e)).ToList());
            builder.HasKey(x => x.Id);
            builder.Property(x => x.Name).IsRequired().HasMaxLength(255);
            builder.Property(x => x.Email).IsRequired();
            builder.Property(x => x.Password).IsRequired();
            builder.Property(x => x.Roles).HasConversion(userRolesConverter).IsRequired();
            builder.ToTable("Users")
                .OwnsOne(x => x.Endereco, x =>
                {
                    x.Property(a => a.Unidade)
                    .HasColumnName("unidade")
                    .IsRequired();
                    x.Property(a => a.Complemento)
                    .HasColumnName("complemento")
                    .IsRequired();
                    x.Property(a => a.Cep)
                    .HasColumnName("cep")
                    .IsRequired();
                    x.Property(a => a.Bairro)
                    .HasColumnName("bairro")
                    .IsRequired();
                    x.Property(a => a.Logradouro)
                    .HasColumnName("logradouro")
                    .IsRequired();
                    x.Property(a => a.Uf)
                    .HasColumnName("uf")
                    .IsRequired();
                    x.Property(a => a.Localidade)
                    .HasColumnName("localidade")
                    .IsRequired();
                });
        }
    }
}

Feito isso, para facilitar, apague todas as tabelas do seu banco de dados e exclua a pasta ´Migrations´ do seu projeto, apos isso rode os seguintes comandos em ordem dentro do console gerenciador de pacotes.

1- Add-Migration InitialDB -Context <nome do contexto a ser migrado>
2- Update-Database -Context <nome do contexto a ser migrado>

Como citamos nos artigos anteriores, por ter construído nossa app utilizando o padrão Clean Architecture e o conceito de domínio não amenico, nos traz uma facilidade de mudar alguma logica em nossa api. Precisamos mudar a logica de salvar o usuário em nosso banco de dados, pois e necessário agora salvar também as Roles de acesso que esse usuário terá para acessar nossa aplicação, para isso vamos fazer apenas mudanças na classe de input e output desse caso de uso, que ficara assim.
RegisterUserInput

using FirstApi.Application.CustomValidations;
using FirstApi.Application.UseCases.PasswordHasher;
using FirstApi.Domain.Entities;
using FirstApi.Domain.Enums;
using FirstApi.Infrastructure.Integration.ViaCep;
using System.ComponentModel.DataAnnotations;

namespace FirstApi.Application.UseCases.CasesUser.RegisterUser
{
    public class RegisterUserInput
    {
        public string? Name { get; set; }

        [EmailAddress(ErrorMessage = "Invalid email address.")]
        public required string Email { get; set; }
        [Password(ErrorMessage = "Password must be at least 8 characters long and contain an uppercase letter, a lowercase letter, a number, and a special character.")]
        public string? Password { get; set; }
        public List<Roles>? Roles { get; set; }
        public string? Cep { get; set; }

        public User Convert(IPasswordHasher hasher, ViaCepResponse response)
        {

            User user = new User();
            user.Name = Name;
            user.Password = hasher.Hash(Password);
            user.Email = Email;
            user.Roles = Roles;
            user.Endereco = user.GetEndereco(response);
            return user;
        }
    }
}

RegisterUserOutput

using FirstApi.Domain.Entities;
using FirstApi.Domain.ValueObjects;

namespace FirstApi.Application.UseCases.CasesUser.RegisterUser
{
    public class RegisterUserOutput
    {
        public int Id { get; set; }
        public string? Name { get; set; }
        public string? Email { get; set; }
        public Endereco? Endereco { get; set; }

        public List<string>? Roles { get; set; }

        public RegisterUserOutput Convert(User user)
        {
            Id = user.Id;
            Name = user.Name;
            Email = user.Email;
            Endereco = user.Endereco;
            Roles = user.Roles.Select(x => x.ToString()).ToList();
            return this;
        }
    }
}

Pronto, feito isso vamos implementar agora na camada de acesso externo de nossa aplicação um controller para fazer a autenticação/autorização do usuário.

AuthController

using FirstApi.Application.UseCases.CasesAuth.Login;
using Microsoft.AspNetCore.Mvc;

namespace FirstApi.Infrastructure.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class AuthController
    {
        private ILoginService _loginService;

        public AuthController(ILoginService loginService)
        {
            _loginService = loginService;
        }

        [HttpPost]
        public LoginOutput Login(LoginInput login)
        {
            return _loginService.Execute(login);
        }

    }
}

Como adicionamos interfaces de services e necessário configurar a inejçao de dependência destes na nossa classe Program.cs e também adicionar uma configuração para que o swagger entenda o fluxo de autenticação da nossa api. Sua classe Program.cs devera ficar assim.


using FirstApi.Application.UseCases.CasesAuth.Login;
using FirstApi.Application.UseCases.CasesEmployer.ConsultEmployer;
using FirstApi.Application.UseCases.CasesEmployer.DeleteEmployer;
using FirstApi.Application.UseCases.CasesEmployer.Register;
using FirstApi.Application.UseCases.CasesEmployer.UpdateEmployer;
using FirstApi.Application.UseCases.CasesUser.ConsultUser;
using FirstApi.Application.UseCases.CasesUser.DeleteUser;
using FirstApi.Application.UseCases.CasesUser.RegisterUser;
using FirstApi.Application.UseCases.CasesUser.UpdateUser;
using FirstApi.Application.UseCases.PasswordHasher;
using FirstApi.Domain.Repositories;
using FirstApi.Infrastructure.Data;
using FirstApi.Infrastructure.Handler;
using FirstApi.Infrastructure.Integration.ViaCep;
using FirstApi.Infrastructure.Integration.ViaCep.Refit;
using FirstApi.Infrastructure.Repositories;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.EntityFrameworkCore;
using Microsoft.IdentityModel.Tokens;
using Microsoft.OpenApi.Models;
using Refit;
using System.Text;

namespace FirstApi
{
    public class Program
    {

        public static void Main(string[] args)
        {
            string secretKey = "e0606215-c2e4-46fe-8d73-a77e1fa4f45a";
            var builder = WebApplication.CreateBuilder(args);
            // Configure logging
            builder.Logging.ClearProviders();
            builder.Logging.AddConsole();
            builder.Logging.AddDebug();
            // Configure data base access
            builder.Services.AddDbContext<SystemDbContext>(
                options => options.UseNpgsql(builder.Configuration.GetConnectionString("DefaultConnection")));
            // Add repositories to the container.
            builder.Services.AddScoped<IEmployerRepository, EmployerRepository>();
            builder.Services.AddScoped<IUserRepository, UserRepository>();
            // Add services to the container.
            // employer
            builder.Services.AddScoped<IRegisterEmployerService, RegisterEmployerService>();
            builder.Services.AddScoped<IUpdateEmployerService, UpdateEmployerService>();
            builder.Services.AddScoped<IConsultEmployerService, ConsultEmployerService>();
            builder.Services.AddScoped<IDeleteEmployerService, DeleteEmployerService>();
            // user
            builder.Services.AddScoped<IRegisterUserService, RegisterUserService>();
            builder.Services.AddScoped<IUpdateUserService, UpdateUserService>();
            builder.Services.AddScoped<IConsultUserService, ConsultUserService>();
            builder.Services.AddScoped<IDeleteUserService, DeleteUserService>();
            builder.Services.AddScoped<IPasswordHasher, PasswordHasher>();
            builder.Services.AddScoped<ILoginService,LoginService>();
            // client viacep
            builder.Services.AddScoped<IViaCepIntegrationService, ViaCepIntegrationService>();
            // Add client refit
            builder.Services.AddRefitClient<IViaCepIntegrationRefit>().ConfigureHttpClient(c =>
            {
                c.BaseAddress = new Uri("https://viacep.com.br");
            }
            );

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen(sw =>
            {
                sw.SwaggerDoc("v1", new Microsoft.OpenApi.Models.OpenApiInfo {
                    Title = "ApiFirst", Version = "v1"
                });
                var securitySchema = new OpenApiSecurityScheme
                {
                    Name = "Jwt Authentication",
                    Description = "Enter with your Jwt Bearer Token",
                    In = ParameterLocation.Header,
                    Type = SecuritySchemeType.Http,
                    Scheme = "Bearer",
                    Reference = new OpenApiReference
                    {
                        Id = JwtBearerDefaults.AuthenticationScheme,
                        Type = ReferenceType.SecurityScheme
                    }
                };
                sw.AddSecurityDefinition(JwtBearerDefaults.AuthenticationScheme, securitySchema);
                sw.AddSecurityRequirement(new OpenApiSecurityRequirement
                {
                    { securitySchema, new string[] { } }
                });
            });

            // Config authentication
            builder.Services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            }).AddJwtBearer(options =>
            {
                options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters()
                {
                    ValidateIssuer = true,
                    ValidateAudience= true,
                    ValidateLifetime = true,
                    ValidateIssuerSigningKey = true,
                    ValidIssuer = "emprise",
                    ValidAudience = "firstApi",
                    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(secretKey))
                };
            });

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();
            app.UseAuthentication();
            app.UseAuthorization();

            // global error handler
            app.UseMiddleware<GlobalExceptionHandler>();

            app.MapControllers();

            app.Run();
        }
    }
}

Pronto, agora e só rodar a aplicação e testarmos a parte de segurança no swagger.

Teste usuario com token mas sem role de acesso
Dados usuarios

Gerando token usuario id 3, sem role de Admin

Request endpoint lista usuários, necessário role de Admin para acesso
Retorno statuscode 403, ou seja estamos autenticado porem nao autorizados a acessar o recurso.

Teste usuario com token e role de acesso
Vamos utilizar o mesmo token gerado com user id = 3, que possui a role USERCOMMON solicitada para buscar os dados de Employers.

Request endpoint lista employers, necessário role de USERCOMMON para acesso
Retorno statuscode 200, ou seja estamos autenticado e autorizados a acessar o recurso.

Finalizamos por aqui galerinha, deixe seu feedback por favor sobre o artigo e deixo aqui minhas redes sociais para quem quiser me adicionar e trocar uma ideia sobre desenvolvimento de softwares para aprendermos juntos, ate a próxima.

linkedin
github

Api Rest .Net completa com JwtToken, integração com api ViaCep utilizando padrão de arquitetura clean architecture

Hernani Almeida — Sat, 27 Jul 2024 01:50:21 +0000

Ferramentas necessárias:

Neste artigo vamos implementar uma api rest utilizando o padrao Clean Architecture, nessa api iremos integrar com uma api externa para buscar dados, configurar e acessar banco de dados postgres fazendo mapeamento e relacionamento de tabelas, criptografar dados para salvar banco de dados e configurar o swagger para realizar a autenticação e o crud em nossa api, bora la.
Para iniciar e necessário fazer o download e instalar o Sdk do .net e a ide Visual Studio Community, links logo acima.
Dentro do terminal digite o comando dotnet --version e devera retornar a versão instalada do sdk que você tem instalada.

Feito isso abra o Visual Studio e crie um novo projeto api web conforme o passo a passo abaixo.

Abra esse projeto dentro do visual studio e ele ira ter a seguinte estrutura

Antes de iniciarmos, ja vamos instalar dependencias que iremos utilizar em nossa aplicação que serão as seguintes

Instale cada uma delas seguindo o passo a passo abaixo
Clique botão direito na raiz da aplicação e entre em Gerenciar pacotes do nuget

Na aba que ira abrir vá em Procurar e digite cada dependencia acima para instalar ao projeto conforme abaixo

Vamos estruturar nossa api utilizando o padrão de arquitetura ´Clean Architecture´ o que nos possibilita ter um sistema coeso e de baixo acoplamento, trabalhando a separação de responsabilidades ao nosso sistema,o que facilita a manutenabilidade de um sistema complexo e robusto.
Para isso vamos ter 3 camadas em nossa api fazendo a separação da mesma nas seguintes estruturas.
Domain Estrutura que será o nosso core, ou seja o núcleo da nossa api, dentro dela era conter o domínio da nossa aplicação e essa camada não depende de nenhuma camada do nosso sistema.
Application Essa camada conterá os casos de usos da nossa aplicação, contendo os serviços que manipulara o nosso domínio para realizar as transações de nossa api.
Observação: Essa camada depende da camada de domínio porem não pode ter nenhuma dependência com a camada seguinte.
Infrastructure Essa camada conterá toda parte de tecnologia/infraestrutura do nosso sistema e será a camada responsável por disponibilizar acesso externo a nossa api.
Observação: Essa camada tem dependência com as outras duas camadas citadas.
Vamos seguir com nossa api, vamos criar 3 pastas em nossa aplicação que ira simbolizar as camadas citadas acima, a estrutura do nosso sistema devera ficar conforme a imagem abaixo.

Vamos iniciar nossa aplicação definindo nossa camada de Domínio, vamos definir nossa entity Employer conforme abaixo.
Employer

using FirstApi.Domain.ValueObjects;

namespace FirstApi.Domain.Entities
{
    public class Employer
    {
        public int Id { get; set; }
        public string? Nome { get; set; }
        public string? Cargo { get; set; }

        public Payment? Payment { get; set; }
        public double? PaymentTotal { get; set; }

        public void AddPaymentByPremiation(double premiation)
        {
            PaymentTotal = PaymentTotal + premiation;
        }
    }
}

**Observação: **Note que temos o método addPaymentByPremiation em nossa entity, método e responsável por adicionar uma premiação ao pagamento do funcionário, ou seja, nossa classe de domínio não será anêmica.

Vamos definir também em nossa camada de Domínio uma interface com o contrato do nosso repositório ligado a entidade Employer e uma classe Payment que e um value-object da classe Employer.
IEmployerRepository

using FirstApi.Domain.Entities;

namespace FirstApi.Domain.Repositories
{
    public interface IEmployerRepository
    {
        Task<List<Employer>> FindEmployers();
        Task<Employer> FindEmployer(int id);
        Task<Employer> Register(Employer employer);
        Task<Employer> UpdateEmployer(Employer employer);
        void DeleteEmployer(Employer employer);
    }
}

Payment

namespace FirstApi.Domain.ValueObjects
{
    public class Payment
    {
        public double Salary { get; set; }
        public double Benefits { get; set; }

        public double getPaymentTotal()
        {
            return Salary + Benefits;
        }
    }

}

A estrutura do nosso projeto agora ficou conforme a imagem abaixo, nossa camada de Domain é o núcleo da nossa api, portanto, ela não tem dependência com nenhuma outra camada do nosso sistema.

Seguimos agora para a camada Application que e a responsável pelos serviços e implementação da regra de negocio de nossa api, na Clean Architecture utilizamos UseCases,ou seja, casos de uso para implementar e realizar uma ação em nossa api, nessa ação definimos o que iremos receber de dados em nossa request para realizar a ação e o que vamos retornar após a ação realizada, isso nos da a facilidade para alterarmos, se necessário, tanto os dados de entrada como os de saída da nossa api tornando nossa aplicação resiliente a mudanças.
Para não estender o artigo não vou seguir passo a passo mas o codigo dessa camada pode ser visualizado no repositorio
Nossa camada de Application sera implementado 4 casos de uso ligados a entity Employer e ficara implementado conforme abaixo.

Observação: Como já citamos antes essa camada tem dependência com a camada de Domain pois utilizamos a entity Employer e a interface IEmployerRepository definida na camada de domínio que será implementada na camada mais externa da nossa aplicação, ou seja, a Infrastructure.
Para realizarmos a injeção da classe IEmployerRepository e dos services de cada casos de uso via construtor temos que adiciona-los ao escopo da nossa aplicação dentro da classe Program.cs, que ficara conforme abaixo.

using FirstApi.Application.UseCases.CasesEmployer.ConsultEmployer;
using FirstApi.Application.UseCases.CasesEmployer.DeleteEmployer;
using FirstApi.Application.UseCases.CasesEmployer.Register;
using FirstApi.Application.UseCases.CasesEmployer.UpdateEmployer;
using FirstApi.Domain.Repositories;
using FirstApi.Infrastructure.Data;
using FirstApi.Infrastructure.Handler;
using FirstApi.Infrastructure.Repositories;
using Microsoft.EntityFrameworkCore;

namespace FirstApi
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            // Add services to the container.
            builder.Services.AddScoped<IEmployerRepository, EmployerRepository>();
            builder.Services.AddScoped<IRegisterEmployerService, RegisterEmployerService>();
            builder.Services.AddScoped<IUpdateEmployerService, UpdateEmployerService>();
            builder.Services.AddScoped<IConsultEmployerService, ConsultEmployerService>();
            builder.Services.AddScoped<IDeleteEmployerService, DeleteEmployerService>();

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();

            app.UseAuthorization();

            // global error handler
            app.UseMiddleware<GlobalExceptionHandler>();

            app.MapControllers();

            app.Run();
        }
    }
}
A classe EmployerRepository iremos construir na camada de Infrastructure

Após definirmos nossos Usecases vamos seguir agora para a camada seguinte da nossa aplicação, a camada Infrastructure, responsável pela parte tecnológica do nosso sistema e por disponibilizar acesso externo a nossa api, nessa camada fica as classes de Controllers, configurações banco de dados, implementações dos repositórios para acesso a transações no banco de dados, fluxo de mensagerias e etc...
Vamos configurar agora a conexão ao nossa database postgres, vamos criar uma pasta Data e dentro dela uma classe SystemDbContext.cs que ira configurar um DbContext, um tipo de ORM em dotnet.
SystemDbContext

using FirstApi.Domain.Entities;
using FirstApi.Infrastructure.Data.Map;
using Microsoft.EntityFrameworkCore;

namespace FirstApi.Infrastructure.Data
{
    public class SystemDbContext : DbContext
    {
        public SystemDbContext(DbContextOptions<SystemDbContext> options)
            : base(options)
        {

        }

        public DbSet<Employer> Employers { get; set; }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.ApplyConfiguration(new EmployerMap());
            base.OnModelCreating(modelBuilder);
        }
    }
}

Dentro da pasta Data crie uma nova pasta Map e dentro dela uma classe EmployerMap.cs que ira mapear a tabela Employer para ser criada em nosso database.

using Microsoft.EntityFrameworkCore.Metadata.Builders;
using Microsoft.EntityFrameworkCore;
using FirstApi.Domain.Entities;

namespace FirstApi.Infrastructure.Data.Map
{
    public class EmployerMap : IEntityTypeConfiguration<Employer>
    {
        public void Configure(EntityTypeBuilder<Employer> builder)
        {
            builder.HasKey(x => x.Id);
            builder.Property(x => x.Nome).IsRequired().HasMaxLength(255);
            builder.Property(x => x.Cargo).IsRequired().HasMaxLength(255);
            builder.Property(x => x.PaymentTotal).IsRequired();
            builder.ToTable("Employers")
                .OwnsOne(x => x.Payment, x =>
                {
                    x.Property(a => a.Salary)
                    .HasColumnName("salary")
                    .IsRequired();
                    x.Property(a => a.Benefits)
                    .HasColumnName("benefits")
                    .IsRequired()
                    .HasDefaultValue(0);
                });
        }
    }
}

Após isso temos que definir nossa string de conexão ao database no arquivo appsetings.Development.json que ficara assim.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "ConnectionStrings": {
    "DefaultConnection": "Host=localhost;Port=5433;Database=net;Username=admin;Password=password"
  }
}

Vamos configurar na classe main da nossa aplicação Program.cs as configurações de acesso ao banco conforme abaixo.

Agora vamos rodar dois comandos dentro do console Gerenciador de pacotes que ira criar uma migration e criar nossa tabela dentro do database.
Va no console Gerenciador de pacotes que entre com o comando Add-Migration InitialDB -Context SystemDbContext

Danto tudo certo, em seguida entre com o comando Update-Database -Context SystemDbContext

Crie uma pasta Repositories e dentro dela a classe EmployerRepository que ira implementar a classe IEmployerRepository definida em nosso dominio.

using FirstApi.Domain.Entities;
using FirstApi.Domain.Repositories;
using FirstApi.Infrastructure.Data;
using Microsoft.EntityFrameworkCore;

namespace FirstApi.Infrastructure.Repositories
{
    public class EmployerRepository : IEmployerRepository
    {
        private readonly SystemDbContext _Dbcontext;

        public EmployerRepository(SystemDbContext context)
        {
            _Dbcontext = context;
        }

        async Task<Employer> IEmployerRepository.Register(Employer employer)
        {
            await _Dbcontext.Employers.AddAsync(employer);
            _Dbcontext.SaveChanges();
            return employer;
        }

        async void IEmployerRepository.DeleteEmployer(Employer employer)
        {
            _Dbcontext.Employers.Remove(employer);
            await _Dbcontext.SaveChangesAsync();
        }

        async Task<Employer> IEmployerRepository.UpdateEmployer(Employer employer)
        {
            _Dbcontext.Employers.Update(employer);
            await _Dbcontext.SaveChangesAsync();
            return employer;
        }

        async Task<Employer> IEmployerRepository.FindEmployer(int id)
        {
            return await _Dbcontext.Employers.FirstOrDefaultAsync(u => u.Id == id);
        }

        async Task<List<Employer>> IEmployerRepository.FindEmployers()
        {
            return await _Dbcontext.Employers.ToListAsync();
        }

    }
}

Crie agora uma pasta Controllers e dentro a classe EmployerController.cs que será a responsável por disponibilizar acesso externo a nossa api via chamadas Http e ficara conforme abaixo.

using FirstApi.Application.UseCases.CasesEmployer;
using FirstApi.Application.UseCases.CasesEmployer.ConsultEmployer;
using FirstApi.Application.UseCases.CasesEmployer.DeleteEmployer;
using FirstApi.Application.UseCases.CasesEmployer.Register;
using FirstApi.Application.UseCases.CasesEmployer.UpdateEmployer;
using FirstApi.Domain.Entities;
using Microsoft.AspNetCore.Mvc;

namespace FirstApi.Infrastructure.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class EmployerController
    {
        private  IRegisterEmployerService _registerService;
        private IUpdateEmployerService _updateService;
        private IConsultEmployerService _consultService;
        private IDeleteEmployerService _deleteService;

        public EmployerController(
            IRegisterEmployerService service,
            IUpdateEmployerService updateService,
            IConsultEmployerService consultService,
            IDeleteEmployerService deleteService)
        {
            _registerService = service;
            _updateService = updateService;
            _consultService = consultService;
            _deleteService = deleteService;
        }

        [HttpPost]
        public RegisterEmployerOutput Post([FromBody] RegisterEmployerInput input)
        {
            return _registerService.Execute(input);
        }

        [HttpPut]
        public UpdateEmployerOutput Put([FromBody] UpdateEmployerInput input)
        {
            return _updateService.Execute(input);
        }

        [HttpGet("{id}")]
        public ConsultEmployerOutput findEmployer(int id)
        {
            return _consultService.FindEmployerById(id);
        }

        [HttpGet]
        public List<ConsultEmployerOutput> findEmployers()
        {
            return _consultService.FindEmployers();
        }

        [HttpDelete("{id}")]
        public string Delete(int id)
        {
            return _deleteService.DeleteEmployer(id);
        }
    }
}

Nossa camada Infrastructure ficara assim.

Crie um arquivo com o nome docke-compose.yaml na raiz do projeto, vamos configurar esse arquivo para subir um DB Postgres no docker.

version: '3'

services:

 postgres:
   image: 'postgres:alpine'
   volumes:
     - postgres-volume:/var/lib/postgresql/data
   ports:
     - 5433:5432
   environment:
     POSTGRES_USER: admin
     POSTGRES_PASSWORD: password
     POSTGRES_DB: net
volumes:
  postgres-volume:

Na pasta raiz rode o comando docker-compose up -d conforme abaixo para subir o database no docker.

Vamos rodar nossa aplicação clicando nesse botao que fica na parte de cima do visual studio

E já podemos ver o swagger da nossa aplicação.

Vamos testar nossa aplicação, primeiro vou realizar um registro

Agora vou buscar esse registro pelo Id

Para seguirmos o projeto vamos ter a segunda parte desse artigo, onde vamos criar um fluxo para salvar um usuário obtendo seus dados de Endereço através de uma integração da nossa api com a api ViaCep, ate la.

Parte 2

linkedin
github

Api Rest .Net completa com JwtToken integração com api ViaCep utilizando padrão de arquitetura clean architecture - parte 2

Hernani Almeida — Sat, 27 Jul 2024 01:47:48 +0000

Ferramentas necessárias:

Seguimos com a construção da nossa api, neste artigo vamos estruturar nossa api para salvar um usuário integrando com a api ViaCep para buscar os dados de endereço desse usuário através do Cep.
Vamos criar estrutura para salvar um usuário, vamos criar a entity User que ira conter os dados de endereço do usuário através da classe Endereco.

User

using FirstApi.Domain.ValueObjects;
using FirstApi.Infrastructure.Integration.ViaCep;

namespace FirstApi.Domain.Entities
{
    public class User
    {
        public int Id { get; set; }
        public string? Name { get; set; }
        public string? Email { get; set; }
        public string? Password { get; set; }
        public Endereco? Endereco { get; set; }

        public Endereco GetEndereco(ViaCepResponse response)
        {
            Endereco endereco = new Endereco();
            if(response is null)
            {
                return endereco;
            }
            endereco.Complemento = response.Complemento;
            endereco.Cep = response.Cep;
            endereco.Bairro = response.Bairro;
            endereco.Logradouro = response.Logradouro;
            endereco.Localidade = response.Localidade;
            endereco.Cep = response.Cep;
            endereco.Unidade = response.Unidade;
            endereco.Uf = response.Uf;
            return endereco;
        }
    }
}

Endereco

using FirstApi.Infrastructure.Integration.ViaCep;

namespace FirstApi.Domain.ValueObjects
{
    public class Endereco
    {
        public string? Cep { get; set; }
        public string? Logradouro { get; set; }
        public string? Complemento { get; set; }
        public string? Unidade { get; set; }
        public string? Bairro { get; set; }
        public string? Localidade { get; set; }
        public string? Uf { get; set; }

    }
}

A estrutura vamos seguir a mesma que a parte 1 desse artigo, ou se preferir pode visitar o repositorio contendo o código para usar como referencia.
Na classe de entrada de dados para registrar nosso usuário vamos receber um parâmetro Cep, através desse parâmetro vamos realizar uma chamada para a api ViaCep para preencher os dados de endereço do usuário, vamos utilizar a lib Refit para realizar essa integração.
Conforme vimos no artigo anterior vamos instalar essas duas dependências no projeto.

Feito isso, seguindo o padrão da Clean Architecture na camada de Infrastructure vamos criar uma pasta Integration e a seguinte estrutura dentro dela.

ViaCepResponse classe que mapeara o response oriundo da api ViaCep

namespace FirstApi.Infrastructure.Integration.ViaCep
{
    public class ViaCepResponse
    { 
        public string? Cep { get; set; }
        public string? Logradouro { get; set; }
        public string? Complemento { get; set; }
        public string? Unidade { get; set; }
        public string? Bairro { get; set; }
        public string? Localidade { get; set; }
        public string? Uf {  get; set; }

}
}

IViaCepIntegrationRefit classe onde configuramos o client de acesso ao endpoint da api ViaCep

using Refit;

namespace FirstApi.Infrastructure.Integration.ViaCep.Refit
{
    public interface IViaCepIntegrationRefit
    {
        [Get("/ws/{cep}/json/")]
        public Task<ApiResponse<ViaCepResponse>> FindEnderecoByCep(string cep);
    }
}

IViaCepIntegrationService contrato do serviço que utilizara o client para realizar a chamada em nossa logica.

namespace FirstApi.Infrastructure.Integration.ViaCep
{
    public interface IViaCepIntegrationService
    {
        public Task<ViaCepResponse> FindEnderecoByCep(string cep);
    }
}

ViaCepIntegrationService serviço que implementa o serviço para buscar os dados de Endereço do usuário.


using FirstApi.Infrastructure.CustomException;
using FirstApi.Infrastructure.Integration.ViaCep.Refit;

namespace FirstApi.Infrastructure.Integration.ViaCep
{
    public class ViaCepIntegrationService : IViaCepIntegrationService
    {
        private readonly IViaCepIntegrationRefit _refit;

        public ViaCepIntegrationService(IViaCepIntegrationRefit refit)
        {
            _refit = refit;
        }

        async Task<ViaCepResponse> IViaCepIntegrationService.FindEnderecoByCep(string cep)
        {
            var responseData = await _refit.FindEnderecoByCep(cep);
            if(responseData is null || !responseData.IsSuccessStatusCode)
            {
                throw new AppException("Error on integration with extern api");
            }

            return responseData.Content;
        }
    }
}

Vamos agora adicionar o escopo de cada serviço na nossa classe Program.cs, para podermos realizar a injeção de dependência, e configurar o RefitClient também em nossa classe Program.cs.

Nossa classe Program.cs ficara assim.


using FirstApi.Application.UseCases.CasesEmployer.ConsultEmployer;
using FirstApi.Application.UseCases.CasesEmployer.DeleteEmployer;
using FirstApi.Application.UseCases.CasesEmployer.Register;
using FirstApi.Application.UseCases.CasesEmployer.UpdateEmployer;
using FirstApi.Application.UseCases.CasesUser.ConsultUser;
using FirstApi.Application.UseCases.CasesUser.DeleteUser;
using FirstApi.Application.UseCases.CasesUser.RegisterUser;
using FirstApi.Application.UseCases.CasesUser.UpdateUser;
using FirstApi.Application.UseCases.PasswordHasher;
using FirstApi.Domain.Repositories;
using FirstApi.Infrastructure.Data;
using FirstApi.Infrastructure.Handler;
using FirstApi.Infrastructure.Integration.ViaCep;
using FirstApi.Infrastructure.Integration.ViaCep.Refit;
using FirstApi.Infrastructure.Repositories;
using Microsoft.EntityFrameworkCore;
using Refit;

namespace FirstApi
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);
            // Configure logging
            builder.Logging.ClearProviders();
            builder.Logging.AddConsole();
            builder.Logging.AddDebug();
            // Configure data base access
            builder.Services.AddDbContext<SystemDbContext>(
                options => options.UseNpgsql(builder.Configuration.GetConnectionString("DefaultConnection")));
            // Add repositories to the container.
            builder.Services.AddScoped<IEmployerRepository, EmployerRepository>();
            builder.Services.AddScoped<IUserRepository, UserRepository>();
            // Add services to the container.
            // employer
            builder.Services.AddScoped<IRegisterEmployerService, RegisterEmployerService>();
            builder.Services.AddScoped<IUpdateEmployerService, UpdateEmployerService>();
            builder.Services.AddScoped<IConsultEmployerService, ConsultEmployerService>();
            builder.Services.AddScoped<IDeleteEmployerService, DeleteEmployerService>();
            // user
            builder.Services.AddScoped<IRegisterUserService, RegisterUserService>();
            builder.Services.AddScoped<IUpdateUserService, UpdateUserService>();
            builder.Services.AddScoped<IConsultUserService, ConsultUserService>();
            builder.Services.AddScoped<IDeleteUserService, DeleteUserService>();
            builder.Services.AddScoped<IPasswordHasher, PasswordHasher>();
            // client viacep
            builder.Services.AddScoped<IViaCepIntegrationService, ViaCepIntegrationService>();
            // Add client refit
            builder.Services.AddRefitClient<IViaCepIntegrationRefit>().ConfigureHttpClient(c =>
            {
                c.BaseAddress = new Uri("https://viacep.com.br");
            }
            );

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();

            app.UseAuthorization();

            // global error handler
            app.UseMiddleware<GlobalExceptionHandler>();

            app.MapControllers();

            app.Run();
        }
    }
}

Dentro do nosso UserController chamamos a api ViaCep para popularmos nosso objeto ViaCepResponse, que e passada como parâmetro para nosso serviço junto com o input de entrada de dados.

Dentro do nosso serviço utilizamos o método Convert implementado dentro da nossa classe de entrada de dados, seguindo o conceito de não termos classes anêmicas em nosso projeto, que ira retornar um objeto User.

Lembre-se de seguir o passo a passo do artigo 1 pois será necessário mapear a entity User e criar a tabela Users no nosso database, feito isso tudo já esta pronto para testarmos nossa api.

Requisição POST

Retorno da Api com os dados completos do usuário, inclusive endereço

Registro salvo banco de dados.

Na próxima parte vamos implementar a parte de segurança da nossa api utilizando o JWt Token, ate lá.

Parte 3

linkedin
github

Saga Pattern in Microservices

Hernani Almeida — Tue, 12 Mar 2024 02:15:36 +0000

Neste post vamos desmistificar o design do padrão saga, vamos construir um sistema de microsserviços que estará salvando dados completos do usuário onde usaremos o Orchestration Saga Pattern, abaixo vemos o fluxograma do projeto.

UserService - Essa API (Java) ira receber a requisição via rest http de um cadastro de usuário e produzir uma mensagem em um tópico Kafka para que a mesma seja consumida pela aplicação orquestradora.
Orchestrator - Essa API (Java) recebe a mensagem produzida pela API acima através de um Listener de um tópico KAFKA que estará captando as mensagem produzidas por este tópico e realiza a orquestração de todo fluxo da transação para os serviços seguintes atraves da (Events-Driven Architecture), ou seja via eventos, para garantir o sucesso da transação e o rolback da mesma caso exista alguma falha.
AdressService - Essa API (Java - Webflux) recebe a mensagem produzida pela API Orchestrator pelo listener do tópico kafka e através do cep passado na requisição faz uma integração via webclient (Api de Data que iremos construir utilizando nodejs(Graphql) para buscar o endereço desse usuário e adicionar esses dados na transação.
ValidatedService - Essa API (Kotlin) recebe a mensagem produzida pela API Orchestrator pelo listener do tópico kafka e valida se o cpf do usuário esta apto para ser cadastrado através da api de Data construida em graphql.
UserRegistration - Essa API (Kotlin) recebe a mensagem produzida pela API Orchestrator pelo listener do tópico kafka e persiste os dados completos do usuario no banco de dados.
DataService - Essa API (Nodejs/Graphql) ira nos fornecer dados relacionados ao usuário, como endereço a partir do cep e validar se o documento passado na requisição não esta numa lista de documentos bloqueados.

Nesse artigo vamos utilizar o Saga Pattern Orchestration, que consiste em ter um microsserviço orquestrador para garantir a execução com sucesso ou rollback dessa transação garantindo sua atomicidade. Há também o Saga Pattern Choreography que pretendo fazer outro post para aprendermos juntos sobre ele.

Vamos utilizar apis em Java, Kotlin e nodejs(graphql) para deixar essas integrações mais interessante e demonstrar o poder do conceito de microsservices, onde podemos ter aplicações de varias linguagens se integrando uma com as outras, bora la que vai ser bem bacana.

OBS: Esse fluxo partiu da minha ideia e de longe não seria necessário utilizar o Saga Pattern, porem este artigo tem a finalidade de entendermos melhor o funcionamento e o conceito dessa ferramenta em microsserviços.

Parte 2

linkedin
github

Saga Pattern in Microservices - Parte 2

Hernani Almeida — Tue, 12 Mar 2024 02:11:35 +0000

Ferramentas necessárias:

Java
Docker
IDE de sua preferencia

Para iniciarmos nossa aplicação, será necessário preparar o ambiente local para termos acessos as tecnologias utilizadas, vamos utilizar a magia do Docker e rodar o kafka, mongodb e postgres.
Crie uma pasta com o nome a seu gosto e dentro da mesma crie um arquivo com o nome docker-compose.yaml e dentro deste arquivo copie o seguinte codigo.

version: '3'

services:

  user-db:
    image: mongo:latest
    container_name: user-db
    restart: always
    networks:
      - orchestrator-saga
    environment:
      - MONGO_INITDB_ROOT_USERNAME=admin
      - MONGO_INITDB_ROOT_PASSWORD=123456
    ports:
      - 27017:27017

  adress-db:
    image: 'postgres:alpine'
    container_name: adress-db
    volumes:
      - adress-volume:/var/lib/postgresql/data
    ports:
      - 5433:5432
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: password
      POSTGRES_DB: adress-db
      POSTGRES_HOST: adress-db
    networks:
      - orchestrator-saga

  userregistration-db:
    image: 'postgres:alpine'
    container_name: userregistration-db
    volumes:
      - userregistration-volume:/var/lib/postgresql/data
    ports:
      - 5434:5432
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: password
      POSTGRES_DB: userregistration-db
      POSTGRES_HOST: userregistration-db
    networks:
      - orchestrator-saga

  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    networks:
      - orchestrator-saga
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - 22181:2181

  kafka:
    image: confluentinc/cp-kafka:latest
    container_name: kafka
    depends_on:
      - zookeeper
    restart: "no"
    ports:
      - "2181:2181"
      - "9092:9092"
    networks:
      - orchestrator-saga
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:29092,PLAINTEXT_HOST://localhost:9092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

  redpanda-console:
    container_name: redpanda
    image: docker.redpanda.com/vectorized/console:latest
    restart: on-failure
    entrypoint: /bin/sh
    command: -c "echo \"$$CONSOLE_CONFIG_FILE\" > /tmp/config.yml; /app/console"
    ports:
      - "8087:8087"
    networks:
      - orchestrator-saga
    environment:
      CONFIG_FILEPATH: /tmp/config.yml
      CONSOLE_CONFIG_FILE: |
        kafka:
          brokers: ["kafka:29092"]
    depends_on:
      - "kafka"

volumes:
  adress-volume:
  userregistration-volume:

networks:
  orchestrator-saga:
    driver: bridge

Agora dentro da pasta execute o seguinte comando docker-compose up -d

Dentro da interface visual do docker você devera visualizar os containers rodando para cada tecnologia que utilizaremos.

Agora vamos utilizar o spring starter para criar nossa primeira estrutura de API.

Vamos adicionar uma nova lib no nosso arquivo pom.xml para que seja gerado automaticamente a documentação via swagger da nossa api.

<!-- https://mvnrepository.com/artifact/org.springdoc/springdoc-openapi-starter-webmvc-ui -->
        <dependency>
            <groupId>org.springdoc</groupId>
            <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
            <version>2.0.4</version>
        </dependency>

Feito isso, vamos configurar nosso tópicos kafka e acesso ao mongoDb através do arquivo de properties da aplicação, defina o arquivo de application.properties igual o código abaixo.

server.port=3000

spring.kafka.bootstrap-servers=${KAFKA_BROKER:localhost:9092}
spring.kafka.topic.start-saga=start-saga
spring.kafka.topic.notify-ending=notify-ending
spring.kafka.consumer.group-id=user-group
spring.kafka.consumer.auto-offset-reset=latest

spring.data.mongodb.database=admin
spring.data.mongodb.uri=${MONGO_DB_URI:mongodb://admin:123456@localhost:27017}

logging.level.org.apache.kafka=OFF

para configurar nosso topico Kafka vamos criar uma classe de configuração contendo as seguintes config.

package br.com.userservice.infrastructure.kafka;

import lombok.RequiredArgsConstructor;
import org.apache.kafka.clients.admin.NewTopic;
import org.apache.kafka.clients.consumer.ConsumerConfig;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.common.serialization.StringDeserializer;
import org.apache.kafka.common.serialization.StringSerializer;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.kafka.annotation.EnableKafka;
import org.springframework.kafka.config.TopicBuilder;
import org.springframework.kafka.core.*;

import java.util.HashMap;
import java.util.Map;

@EnableKafka
@Configuration
@RequiredArgsConstructor
public class KafkaConfig {

    private static final Integer PARTITION_COUNT = 1;
    private static final Integer REPLICA_COUNT = 1;

    @Value("${spring.kafka.bootstrap-servers}")
    private String bootstrapServers;

    @Value("${spring.kafka.consumer.group-id}")
    private String groupId;

    @Value("${spring.kafka.consumer.auto-offset-reset}")
    private String autoOffsetReset;

    @Value("${spring.kafka.topic.start-saga}")
    private String startSagaTopic;

    @Value("${spring.kafka.topic.notify-ending}")
    private String notifyEndingTopic;

    @Bean
    public ConsumerFactory<String, String> consumerFactory() {
        return new DefaultKafkaConsumerFactory<>(consumerProps());
    }

    private Map<String, Object> consumerProps() {
        var props = new HashMap<String, Object>();
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        props.put(ConsumerConfig.GROUP_ID_CONFIG, groupId);
        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
        props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, autoOffsetReset);
        return props;
    }

    @Bean
    public ProducerFactory<String, String> producerFactory() {
        return new DefaultKafkaProducerFactory<>(producerProps());
    }

    private Map<String, Object> producerProps() {
        var props = new HashMap<String, Object>();
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        return props;
    }

    @Bean
    public KafkaTemplate<String, String> kafkaTemplate(ProducerFactory<String, String> producerFactory) {
        return new KafkaTemplate<>(producerFactory);
    }

    private NewTopic buildTopic(String name) {
        return TopicBuilder
                .name(name)
                .partitions(PARTITION_COUNT)
                .replicas(REPLICA_COUNT)
                .build();
    }

    @Bean
    public NewTopic startSagaTopic() {
        return buildTopic(startSagaTopic);
    }

    @Bean
    public NewTopic notifyEndingTopic() {
        return buildTopic(notifyEndingTopic);
    }
}

Após isto criamos uma classe controller que ira receber a requisição via http e chamar uma classe service para enviar uma mensagem com dados para nosso servico Orchestrator que ira start/comandar/finalizar todo resto de envio de mensagens via topico Kafka para finalizar a transação de salvar um usuário.

Uma classe Service que ira agregar/gerir a regra de negocio relacionada a transação, nesse caso enviar a mensagem com os dados para o serviço de orquestração.

O codigo dessa aplicação ficara assim.
API Saga Pattern - User Service

Parte 3

linkedin
github

Saga Pattern in Microservices - Parte 3

Hernani Almeida — Tue, 12 Mar 2024 02:10:42 +0000

Ferramentas necessárias:

Java
Docker
IDE de sua preferencia
Configuração do ambiente conforme a parte 2 do artigo

Vamos criar uma aplicação com o nome de Orchestrator no spring starter com as seguintes dependências necessárias

Essa api realizara todo o controle de eventos da nossa transação de cadastro de usuário através da (Events-Driven Architecture), nela ira conter a logica de envio de mensagens para seguir com a saga de cadastrar usuário ou para finalizar/realizar rolback conforme os tópicos de cada aplicação.
Conforme a api anterior nessa api teremos o application.yml contendo as configs do tópico kafka e também a classe de configuração do Kafka e tópicos.
A saga e iniciada na api orquestradora através de um listener do kafka que recebe a mensagem enviada pela api User-Service, nessa classe SagaOrchestratorConsumer também estão configurados os listeners que continua a saga e que finalizam a saga com sucesso ou falha.

package br.com.orchestrator.application.consumer;

import br.com.orchestrator.core.service.OrchestrationService;
import br.com.orchestrator.core.utils.JsonUtil;
import lombok.AllArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.stereotype.Component;

@Slf4j
@Component
@AllArgsConstructor
public class SagaOrchestratorConsumer {

    private final OrchestrationService service;
    private final JsonUtil jsonUtil;

    @KafkaListener(
        groupId = "${spring.kafka.consumer.group-id}",
        topics = "${spring.kafka.topic.start-saga}"
    )
    public void consumeStartSagaEvent(String payload) {
        log.info("Receiving event {} from start-saga topic", payload);
        var event = jsonUtil.toEvent(payload);
        service.startSaga(event);
    }

    @KafkaListener(
        groupId = "${spring.kafka.consumer.group-id}",
        topics = "${spring.kafka.topic.orchestrator}"
    )
    public void consumeOrchestratorEvent(String payload) {
        log.info("Receiving event {} from orchestrator topic", payload);
        var event = jsonUtil.toEvent(payload);
        service.continueSaga(event);
    }

    @KafkaListener(
        groupId = "${spring.kafka.consumer.group-id}",
        topics = "${spring.kafka.topic.finish-success}"
    )
    public void consumeFinishSagaSuccessEvent(String payload) {
        log.info("Receiving event {} from finish-success topic", payload);
        var event = jsonUtil.toEvent(payload);
        service.finishSagaSuccess(event);
    }

    @KafkaListener(
        groupId = "${spring.kafka.consumer.group-id}",
        topics = "${spring.kafka.topic.finish-fail}"
    )
    public void consumeFinishSagaFailEvent(String payload) {
        log.info("Receiving event {} from finish-fail topic", payload);
        var event = jsonUtil.toEvent(payload);
        service.finishSagaFail(event);
    }
}

Após receber a mensagem chamamos nosso service conforme a regra de negocio recebida via tópico kafka que utiliza a classe SagaExecutionController para seguir com o fluxo da saga via event driven conforme veremos logo mais abaixo.

package br.com.orchestrator.core.service;

import br.com.orchestrator.application.dto.Event;
import br.com.orchestrator.application.dto.History;
import br.com.orchestrator.application.producer.SagaOrchestratorProducer;
import br.com.orchestrator.application.saga.SagaExecutionController;
import br.com.orchestrator.core.enums.ETopics;
import br.com.orchestrator.core.utils.JsonUtil;
import lombok.AllArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;

import java.time.LocalDateTime;

import static br.com.orchestrator.core.enums.EEventSource.ORCHESTRATOR;
import static br.com.orchestrator.core.enums.ESagaStatus.FAIL;
import static br.com.orchestrator.core.enums.ESagaStatus.SUCCESS;

@Slf4j
@Service
@AllArgsConstructor
public class OrchestrationService {

    private final SagaOrchestratorProducer producer;
    private final JsonUtil jsonUtil;
    private final SagaExecutionController sagaExecutionController;

    public void startSaga(Event event) {
        event.setSource(ORCHESTRATOR);
        event.setStatus(SUCCESS);
        var topic = getTopic(event);
        log.info("SAGA STARTED!");
        addHistory(event, "Saga started!");
        sendToProducerWithTopic(event, topic);
    }

    public void finishSagaSuccess(Event event) {
        event.setSource(ORCHESTRATOR);
        event.setStatus(SUCCESS);
        log.info("SAGA FINISHED SUCCESSFULLY FOR EVENT {}!", event.getId());
        addHistory(event, "Saga finished successfully!");
        notifyFinishedSaga(event);
    }

    public void finishSagaFail(Event event) {
        event.setSource(ORCHESTRATOR);
        event.setStatus(FAIL);
        log.info("SAGA FINISHED WITH ERRORS FOR EVENT {}!", event.getId());
        addHistory(event, "Saga finished with errors!");
        notifyFinishedSaga(event);
    }

    public void continueSaga(Event event) {
        var topic = getTopic(event);
        log.info("SAGA CONTINUING FOR EVENT {}", event.getId());
        sendToProducerWithTopic(event, topic);
    }

    private ETopics getTopic(Event event) {
        return sagaExecutionController.getNextTopic(event);
    }

    private void addHistory(Event event, String message) {
        var history = new History(event.getSource(), event.getStatus(), message, LocalDateTime.now());
        event.addToHistory(history);
    }

    private void sendToProducerWithTopic(Event event, ETopics topic) {
        producer.sendEvent(jsonUtil.toJson(event), topic.getTopic());
    }

    private void notifyFinishedSaga(Event event) {
        producer.sendEvent(jsonUtil.toJson(event), ETopics.NOTIFY_ENDING.getTopic());
    }
}

Nessa api teremos uma classe SagaHandler que terá um método estático que retornara um vetor de uma matriz, utilizaremos essa matriz para que a api orquestradora entenda qual tópico ira enviar a mensagem para dar seguimento a saga de cadastro de usuário.

package br.com.orchestrator.application.saga;


import static br.com.orchestrator.core.enums.EEventSource.*;
import static br.com.orchestrator.core.enums.ESagaStatus.*;
import static br.com.orchestrator.core.enums.ETopics.*;

public final class SagaHandler {

    private SagaHandler() {

    }

    public static final Object[][] SAGA_HANDLER = {
        { ORCHESTRATOR, SUCCESS, ADRESS_VALIDATION_SUCCESS },
        { ORCHESTRATOR, FAIL, FINISH_FAIL },

        { ADRESS_VALIDATION_SERVICE, ROLLBACK_PENDING, ADRESS_VALIDATION_FAIL },
        { ADRESS_VALIDATION_SERVICE, FAIL, FINISH_FAIL },
        { ADRESS_VALIDATION_SERVICE, SUCCESS, VALIDATED_SUCCESS },

        { VALIDATED_SERVICE, ROLLBACK_PENDING, VALIDATED_FAIL },
        { VALIDATED_SERVICE, FAIL, ADRESS_VALIDATION_FAIL },
        { VALIDATED_SERVICE, SUCCESS, REGISTRATION_SUCCESS },

        { REGISTRATION_SERVICE, ROLLBACK_PENDING, REGISTRATION_FAIL },
        { REGISTRATION_SERVICE, FAIL, REGISTRATION_FAIL },
        { REGISTRATION_SERVICE, SUCCESS, FINISH_SUCCESS }
    };

    public static final int EVENT_SOURCE_INDEX = 0;
    public static final int SAGA_STATUS_INDEX = 1;
    public static final int TOPIC_INDEX = 2;
}

Criaremos uma classe SagaExecutionController que ira ser utilizada para controlar toda a execução da saga, nesta classe que utilizamos a matriz acima para saber qual tópico kafka será enviada a mensagem para seguir saga.

package br.com.orchestrator.application.saga;

import br.com.orchestrator.application.dto.Event;
import br.com.orchestrator.application.exception.ValidationException;
import br.com.orchestrator.core.enums.ETopics;
import lombok.AllArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;

import java.util.Arrays;

import static br.com.orchestrator.application.saga.SagaHandler.*;
import static java.lang.String.format;
import static org.springframework.util.ObjectUtils.isEmpty;

@Slf4j
@Component
@AllArgsConstructor
public class SagaExecutionController {

    private static final String SAGA_LOG_ID = "USER ID: %s | TRANSACTION ID %s | EVENT ID %s";

    public ETopics getNextTopic(Event event) {
        if (isEmpty(event.getSource()) || isEmpty(event.getStatus())) {
            throw new ValidationException("Source and status must be informed.");
        }
        var topic = findTopicBySourceAndStatus(event);
        logCurrentSaga(event, topic);
        return topic;
    }

    private ETopics findTopicBySourceAndStatus(Event event) {
        return (ETopics) (Arrays.stream(SAGA_HANDLER)
            .filter(row -> isEventSourceAndStatusValid(event, row))
            .map(i -> i[TOPIC_INDEX])
            .findFirst()
            .orElseThrow(() -> new ValidationException("Topic not found!")));
    }

    private boolean isEventSourceAndStatusValid(Event event,
                                                Object[] row) {
        var source = row[EVENT_SOURCE_INDEX];
        var status = row[SAGA_STATUS_INDEX];
        return source.equals(event.getSource()) && status.equals(event.getStatus());
    }

    private void logCurrentSaga(Event event, ETopics topic) {
        var sagaId = createSagaId(event);
        var source = event.getSource();
        switch (event.getStatus()) {
            case SUCCESS -> log.info("### CURRENT SAGA: {} | SUCCESS | NEXT TOPIC {} | {}",
                source, topic, sagaId);
            case ROLLBACK_PENDING -> log.info("### CURRENT SAGA: {} | SENDING TO ROLLBACK CURRENT SERVICE | NEXT TOPIC {} | {}",
                source, topic, sagaId);
            case FAIL -> log.info("### CURRENT SAGA: {} | SENDING TO ROLLBACK PREVIOUS SERVICE | NEXT TOPIC {} | {}",
                source, topic, sagaId);
        }
    }

    private String createSagaId(Event event) {
        return format(SAGA_LOG_ID,
            event.getPayload().getId(), event.getTransactionId(), event.getId());
    }
}

O codigo dessa aplicação ficara assim.
API Saga Pattern - Orchestrator

Parte 4

linkedin
github

Saga Pattern in Microservices - Parte 4

Hernani Almeida — Tue, 12 Mar 2024 02:09:56 +0000

Ferramentas necessárias:

Java
Docker
IDE de sua preferencia
Configuração do ambiente conforme a parte 2 do artigo

Vamos criar três aplicações com os nomes de Adress-Service(Java), UserRegistration e Validated-Document-Service(Kotlin) no spring starter com as seguintes dependências necessárias

Essas apis receberam o payload via tópico kafka conforme listener do kafka configurado nelas e integrarão com outro service nosso construído em Nodejs/Graph que nos retornara os dados que precisamos, a AdressService ira buscar e adicionar o endereço do usuário no payload enquanto que a Validated-Document-Service ira validar se o documento do usuário não esta guardado dentro de uma lista de documentos bloqueados.
Feito isso a mensagem e enviada para o topico a api User-Registration que com o payload com os dados completo do usuário armazeno-os no banco de dados postgres.
Abaixo deixarei o link para acessar o código das aplicações no github.

API Saga Pattern - AdressService(Java)
API Saga Pattern - ValidatedService(Kotlin)
API Saga Pattern - UserRegistration(Kotlin)

Essas apis integrarão com outra api nossa construído em Nodejs/Graphql que nos fornecerão os dados de endereço do usuário e a lista de documentos bloqueados.
API Saga Pattern - DataService(Nodejs/Graphql)

Podemos testar agora a saga para cadastrar um usuário e validar o comportamento dos microservices se integrando entre si através da orientação a eventos.
Acesse nossa primeira api atraves do swagger por este link.

No endpoint /user vamos fazer a requisição inicial passando nome, cpf valido e o cep do usuario.

Logs do fluxo da nossa saga na api orquestradora

Vamos pegar o transactionId no payload de retorno da requisição que fizemos acima e consultar via endpoint /user/event

Isso nos retornara todo o processo que aconteceu na nossa transação com sucesso.

{
  "id": "65efb539e7a8223c9344944f",
  "userId": "65efb538e7a8223c9344944e",
  "transactionId": "1710208312995_b931560b-58d2-4d8a-8351-3abdcf2e7268",
  "payload": {
    "id": "65efb538e7a8223c9344944e",
    "transactionId": "1710208312995_b931560b-58d2-4d8a-8351-3abdcf2e7268",
    "name": "Teste",
    "document": "91549825020",
    "cep": "18608-456",
    "createdAt": "2024-03-12T01:51:52.996"
  },
  "source": "ORCHESTRATOR",
  "status": "SUCCESS",
  "eventHistory": [
    {
      "source": "ORCHESTRATOR",
      "status": "SUCCESS",
      "message": "Saga started!",
      "createdAt": "2024-03-11T22:51:53.032"
    },
    {
      "source": "ADRESS_VALIDATION_SERVICE",
      "status": "SUCCESS",
      "message": "adress was validated successfully! {}",
      "createdAt": "2024-03-11T22:51:53.188"
    },
    {
      "source": "VALIDATED_SERVICE",
      "status": "SUCCESS",
      "message": "Document was validated successfully! {}",
      "createdAt": "2024-03-11T22:51:53.287"
    },
    {
      "source": "REGISTRATION_SERVICE",
      "status": "SUCCESS",
      "message": "user persisted with successfully! {}",
      "createdAt": "2024-03-11T22:51:54.476"
    },
    {
      "source": "ORCHESTRATOR",
      "status": "SUCCESS",
      "message": "Saga finished successfully!",
      "createdAt": "2024-03-11T22:51:54.741"
    }
  ],
  "createdAt": "2024-03-12T01:51:54.999"
}

Vamos repetir esse processo porem passando um cpf que contem na lista de documentos bloqueados

Veja pelos logs da nossa api orquestradora que ocorreu um erro na api de validated-document e que a partir dai foi enviada, via kafka, uma mensagem de rollback para api validated-service e adress-service para que ambas apaguem o que já haviam feito nessa transação

Vamos pegar o transactionId no payload de retorno da requisição que fizemos acima e consultar via endpoint /user/event o retorno dessa saga.

{
  "id": "65efb708e7a8223c93449451",
  "userId": "65efb708e7a8223c93449450",
  "transactionId": "1710208776483_c53613c4-4779-4402-9702-77f9e376c2a5",
  "payload": {
    "id": "65efb708e7a8223c93449450",
    "transactionId": "1710208776483_c53613c4-4779-4402-9702-77f9e376c2a5",
    "name": "Teste",
    "document": "86060970044",
    "cep": "18608-490",
    "createdAt": "2024-03-12T01:59:36.483"
  },
  "source": "ORCHESTRATOR",
  "status": "FAIL",
  "eventHistory": [
    {
      "source": "ORCHESTRATOR",
      "status": "SUCCESS",
      "message": "Saga started!",
      "createdAt": "2024-03-11T22:59:36.507"
    },
    {
      "source": "ADRESS_VALIDATION_SERVICE",
      "status": "SUCCESS",
      "message": "adress was validated successfully! {}",
      "createdAt": "2024-03-11T22:59:36.579"
    },
    {
      "source": "VALIDATED_SERVICE",
      "status": "ROLLBACK_PENDING",
      "message": "Fail to validate adress: Document {} has some pendency in our base",
      "createdAt": "2024-03-11T22:59:36.635"
    },
    {
      "source": "VALIDATED_SERVICE",
      "status": "FAIL",
      "message": "Rollback executed on validated-document validation!",
      "createdAt": "2024-03-11T22:59:36.733"
    },
    {
      "source": "ADRESS_VALIDATION_SERVICE",
      "status": "FAIL",
      "message": "Rollback executed on adress validation!",
      "createdAt": "2024-03-11T22:59:36.876"
    },
    {
      "source": "ORCHESTRATOR",
      "status": "FAIL",
      "message": "Saga finished with errors!",
      "createdAt": "2024-03-11T22:59:36.933"
    }
  ],
  "createdAt": "2024-03-12T01:59:36.955"
}

Vlw pessoal por visualizarem mais esse artigo e deixo aqui minhas redes sociais para quem quiser me adicionar e trocar uma ideia sobre desenvolvimento de softwares para aprendermos juntos.

linkedin
github

Desacoplando frontend com module-federation Angular - Parte 2

Hernani Almeida — Sat, 03 Jun 2023 13:29:40 +0000

Ferramentas necessárias:

Vamos continuar a implementação da nossa aplicação, abra o terminal na pasta mfe-1 e rode o seguinte comando para instalar a lib do module-federation e configurar o webpack da aplicação.

ng add @angular-architects/module-federation --project mfe-1 --port 4201 --type remote --skip-confirmation

Logo apos digite code . para abrir o vscode e vermos o codigo de nossa aplicação.

Mude os seguintes arquivos dentro do código.
app.component.html

<h1>Aqui e o Mfe-1</h1>

app.module.ts

import { NgModule } from '@angular/core';

import { AppComponent } from './app.component';
import { CommonModule } from '@angular/common';
import { AppRoutingModule } from './app-routing.module';

@NgModule({
  declarations: [AppComponent],
  imports: [CommonModule, AppRoutingModule],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

Detalhe que veja que passamos no import desse module o CommomModule pois esse module da aplicação e um module filho da nossa aplicação host.

app-routing.module.ts

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { AppComponent } from './app.component';

const MFE1_ROUTES: Routes = [
  {
    path: '',
    component: AppComponent,
  },
];

@NgModule({
  imports: [RouterModule.forChild(MFE1_ROUTES)],
  exports: [RouterModule],
})
export class AppRoutingModule {}

Outro detalhe aqui tambem, passamos no nosso RouterModule como RouterModule.forChild pois essa rota será filha da rota root da nossa aplicação host.
webpack.config.js

const {
  shareAll,
  withModuleFederationPlugin,
} = require("@angular-architects/module-federation/webpack");

module.exports = withModuleFederationPlugin({
  name: "mfe-1",

  exposes: {
    "./Module": "./src/app/app.module.ts",
  },

  shared: {
    ...shareAll({
      singleton: true,
      strictVersion: true,
      requiredVersion: "auto",
 },
});

Feito isso digite o seguinte comando no terminal para rodar a aplicação npm run start e acesse nosso host e clique no link Acesse Mfe-1 e podemos ver nosso mfe sendo acessado via host.

Siga os mesmos passos dentro da pasta onde foi criado o projeto mfe-2, porem para instalar a lib do module-federation e configurar o webpack digite o seguinte comando no terminal.
ng add @angular-architects/module-federation --project mfe-2 --port 4202 --type remote --skip-confirmation
Após isso ajuste os seguintes arquivos para ficar assim.
Mude os seguintes arquivos dentro do código.

app.component.html

<h1>Aqui e o Mfe-2</h1>

app.module.ts

import { NgModule } from '@angular/core';

import { AppComponent } from './app.component';
import { CommonModule } from '@angular/common';
import { AppRoutingModule } from './app-routing.module';

@NgModule({
  declarations: [AppComponent],
  imports: [CommonModule, AppRoutingModule],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

Detalhe que veja que passamos no import desse module o CommomModule pois esse module da aplicação e um module filho da nossa aplicação host.

app-routing.module.ts

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { AppComponent } from './app.component';

const MFE2_ROUTES: Routes = [
  {
    path: '',
    component: AppComponent,
  },
];

@NgModule({
  imports: [RouterModule.forChild(MFE2_ROUTES)],
  exports: [RouterModule],
})
export class AppRoutingModule {}

Outro detalhe aqui tambem, passamos no nosso RouterModule como RouterModule.forChild pois essa rota será filha da rota root da nossa aplicação host.

webpack.config.js

const {
  shareAll,
  withModuleFederationPlugin,
} = require("@angular-architects/module-federation/webpack");

module.exports = withModuleFederationPlugin({
  name: "mfe-2",

  exposes: {
    "./Module": "./src/app/app.module.ts",
  },

  shared: {
    ...shareAll({
      singleton: true,
      strictVersion: true,
      requiredVersion: "auto",
 },
});

Feito isso digite o seguinte comando no terminal para rodar a aplicação npm run start e acesse nosso host e clique no link Acesse Mfe-2 e podemos ver nosso mfe sendo acessado via host.

Podemos agora a cada clique no link acessar remotamente nossas aplicações mfe-1 e mfe-2 o que nos possibilita, por exemplo fazer alterações e subir um deploy na aplicação mfe-1 sem que isso interfira na aplicação mfe-2 pois e um outro codigo totalmente independente.

E isso ai devs mas um conhecimento passado, deixarei no meu github para quem quiser acessar o projeto
Deixo aqui também meu linkedin e instagram para quem quiser me adicionar, grato a todos que leram este artigo e bora aprender galera.
*Observação: * Como um plus numa terceira parte irei me desafiar a construir um componente angular utilizando module-federation para servir como lib de algum componente para se usar nas aplicações, exemplo um botão padrão para usar em todas as aplicações, e compartilho aqui numa terceira parte.

DEV Community: Hernani Almeida

Angular 21 + Native Federation — Parte 2: Integração, Debug e Boas Práticas

1. Arquitetura que vamos construir

2. O papel do federation.config.js

3. ./Component não é o nome da classe

4. O papel do federation.manifest.json

5. Cuidado com o caminho do manifest

6. remoteEntry.json é diferente do antigo remoteEntry.js

7. A rota do Host

8. path precisa bater com o link

9. Não esquecer o RouterOutlet

10. Não esquecer o provideRouter

11. O Remote também pode funcionar sozinho

12. SSE: o que significa?

13. Como fazer troubleshooting

Passo 1 — Remote

Passo 2 — remoteEntry

Passo 3 — Manifest

Passo 4 — Host

Passo 5 — DevTools

14. Um erro importante: 404 no manifest

15. CSS em Micro Frontends

16. Por que evitar CSS global no MFE?

17. Um Remote pode expor mais de um componente

Desacoplando Frontend com Module Federation no Angular 21 — Parte 1

O que são Micro Frontends?

O que mudou desde o Angular utilizado no artigo original?

Ferramentas necessárias

1. Criando o workspace

2. Criando os Micro Frontends

3. Configurando o MFE-1

4. Configurando o MFE-2

5. Configurando o Shell

6. Estrutura do projeto

7. Configurando o MFE-1

8. Configurando o MFE-2

9. Configurando o Manifest

10. Como o Manifest funciona?

11. Inicialização do Federation

12. Configurando as rotas do Shell

13. Configurando o AppComponent do Shell

14. Configurando o MFE-1

15. Configurando o MFE-2

16. Subindo os projetos

Terminal 1 — MFE-1

Terminal 2 — MFE-2

Terminal 3 — Shell

17. Testando

18. O que está acontecendo por baixo?

19. Compartilhamento de dependências

20. Por que utilizar Native Federation no Angular 21?

21. Estrutura final

Conclusão

Troubleshooting — Problemas na instalação do Native Federation

1. Verifique a versão do Angular

2. Instale uma versão compatível manualmente

3. Regra geral

4. Caso tenha instalado uma versão incorreta

5. Resumo

Implementando Singleton, Factory e Observer com novas features versoes recentes Java

🔧 Padrões Utilizados

🔒 Singleton

🏭 Factory

👀 Observer

🆕 Features das versoes recentes do Java

📦 Classes Principais

✅ Conclusão

Solucionar erro imagem module-federation

Api Rest .Net completa com JwtToken integração com api ViaCep utilizando padrão de arquitetura clean architecture - parte 3

Api Rest .Net completa com JwtToken, integração com api ViaCep utilizando padrão de arquitetura clean architecture

Api Rest .Net completa com JwtToken integração com api ViaCep utilizando padrão de arquitetura clean architecture - parte 2

Saga Pattern in Microservices

Saga Pattern in Microservices - Parte 2

Saga Pattern in Microservices - Parte 3

Saga Pattern in Microservices - Parte 4

Desacoplando frontend com module-federation Angular - Parte 2

3. `./Component` não é o nome da classe

6. `remoteEntry.json` é diferente do antigo `remoteEntry.js`

8. `path` precisa bater com o link

10. Não esquecer o `provideRouter`

14. Um erro importante: `404` no manifest