Forem: Hernani Almeida

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.

Desacoplando frontend com module-federation Angular - Parte 1

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

Ferramentas necessárias:

O conceito Micro frontends e permitir aos desenvolvedores a flexibilidade de solicitar remotamente um módulo na rede e inicializar esse módulo em sua aplicação, podendo assim separar responsabilidades de uma aplicação frontend em varias aplicações.
Os microfrontends podem ajudar os desenvolvedores a focar nos requisitos funcionais e nas necessidades de negócios.
Os microfrontends podem aumentar o reuso de código na empresa e simplificar o processo de desenvolvimento, deixando a aplicação com pouco acoplamento pois possibilita a cada aplicação dentro do ambiente ter sua própria versão, seu próprio framework, seu próprio deploy e no final para o usuário isso se reflete a 1 aplicação.
Construir uma plataforma para microfrontends é muito semelhante ao de uma plataforma para microservices.

Nesse artigo vamos construir um microfrontend utilizando o framework Angular onde através da aplicação main iremos acessar outras duas aplicações remotas utilizando a ferramenta module-federation, dito isso bora codar.

Crie uma pasta artigoMFE e atraves do terminal de sua maquina entre dentro desta pasta vamos criar 3 aplicações angular através do comando ng new mfe-host, após ng new mfe-1 e após ng new mfe-2.

Temos agora 3 projetos angular criado dentro da pasta artigoMFE, digite o seguinte comando cd mfe-host no terminal na raiz da pasta artigoMFE

Dentro da pasta mfe-host digite o seguinte comando para abrir a aplicação dentro do VSCODE code .

Ainda na pasta mfe-host digite o seguinte comando

ng add @angular-architects/module-federation --project mfe-host --port 4200 --type host --skip-confirmation

Esse comando ira instalar a biblioteca do module-federation em nossa aplicação e configurar o arquivo webpack da nossa aplicação.

Feito isso crie um arquivo app-routing.module.ts na sua aplicação de maneira que a estrutura fique o seguinte.

E altere os seguintes arquivos para ficar igual os arquivos abaixo.

app-routing.module.ts

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { loadRemoteModule } from '@angular-architects/module-federation';

const APP_ROUTES: Routes = [
  {
    path: 'mfe-1',
    loadChildren: () =>
      loadRemoteModule({
        type: 'module',
        remoteEntry: 'http://localhost:4201/remoteEntry.js',
        exposedModule: './Module',
      }).then((m) => m.AppModule),
  },
  {
    path: 'mfe-2',
    loadChildren: () =>
      loadRemoteModule({
        type: 'module',
        remoteEntry: 'http://localhost:4202/remoteEntry.js',
        exposedModule: './Module',
      }).then((m) => m.AppModule),
  },
];

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

app.module.ts

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppComponent } from './app.component';
import { AppRoutingModule } from './app-routing.module.';

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

app.component.html

<div>
  <p><a routerLink="/mfe-1">Acesse MFE-1</a></p>
  <p><a routerLink="/mfe-2">Acesse MFE-2</a></p>
</div>
<div>
  <router-outlet></router-outlet>
</div>

Feito isso digite o seguinte comando no terminal npm run start para rodar a aplicação e clique no link abaixo:

Podemos ver na ferramenta da google na aba de Redes que nosso host tentou se comunicar a nossa aplicação remota mfe-1

No próximo artigo vamos implementar as aplicações remotas mfe-1 e mfe-2 para concluir nosso artigo, ate o próximo artigo

Deixo aqui meu linkedin e instagram para quem quiser me adicionar

Armazenando imagens protocolo SFTP com java - Springboot

Hernani Almeida — Sat, 02 Jul 2022 02:22:16 +0000

Ferramentas necessárias:

Java SDK
Docker
Postman
Filezila Client
Ide de sua preferencia
Criar uma aplicação Springboot pelo Spring Initializr

Neste post vamos abordar o armazenamento de imagens utilizando o protocolo SFTP, vamos subir um servidor SFTP utilizando a chave SSH Importante mecanismo de autenticação que asseguram a proteção de dados e informações dentro de um container docker e enviar imagens para este servidor através de uma api rest java.
Crie uma aplicação Springboot, como nosso objetivo e apenas demonstrar o envio de imagens via SFTP não vamos nos preocupar com padrões arquiteturais.
Crie uma pasta na raiz do projeto com o nome de sua escolha e dentro desta pasta um arquivo dockerfile e cole dentro dele os seguintes comandos.
dockerfile

FROM ubuntu:latest

RUN mkdir -p /var/run/sshd

RUN apt update && \
    apt install -y openjdk-8-jdk && \
    apt install -y openssh-server

RUN useradd -rm -d /home/remote_user -s /bin/bash remote_user && \
    echo remote_user:password1234 | chpasswd

RUN mkdir /home/remote_user/.ssh && \
    chmod 700 /home/remote_user/.ssh

COPY id_rsa.pub /home/remote_user/.ssh/authorized_keys

RUN chown remote_user:remote_user -R /home/remote_user/.ssh && \
    chmod 600 /home/remote_user/.ssh/authorized_keys

CMD [ "/usr/sbin/sshd" , "-D"]

E um arquivo com o nome docker-compose.yml com a seguinte configuração no mesmo
docker-compose.yml

version: '3.7'
services:
  app:
    container_name: sftp
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - '58898:22'

Feito isso, via cmd, entre na pasta onde esta localizado os arquivos dockerfile e docker-compose.yml e rode o seguinte comando para criar uma chave de segurança SSH
ssh-keygen -t rsa -m PEM -f id_rsa apos rodar o comando sera pedido para você escrever uma frase e depois confirmar esta frase para gerar o ssh.

Ainda dentro desta pasta via cmd rode o comando docker compose up -d e será criado nosso servidor dentro de um container docker.

Já podemos acessar nosso servidor através do Filezila CLient
*Obs: Password tem que ser o mesmo especificado no dockerfile, neste caso password1234

Vamos utilizar a lib JSch para armazenar a imagem recebida no servidor SFTP, para isto adicione a seguinte dependência em seu projeto.

<!-- https://mavenlibs.com/maven/dependency/org.lucee/jsch -->
<dependency>
    <groupId>org.lucee</groupId>
    <artifactId>jsch</artifactId>
    <version>0.1.55</version>
</dependency>

Crie uma classe de configuração do JSch para acessar nosso servidor junto com os métodos necessarios.
SftpConfig

package com.example.sftp;

import com.jcraft.jsch.*;

import java.io.InputStream;


public class SftpConfig {

    /* criar canal para acessar servidor sftp */
    public static ChannelSftp setupJsch() throws JSchException {

        Session jschSession = null;

        Channel sftp = null;

        JSch jsch = new JSch();
        JSch.setConfig("StrictHostKeyChecking", "no");
        //jsch.setKnownHosts("/home/remote_user/.ssh/known_hosts");
        jschSession = jsch.getSession("remote_user", "localhost", 58898);

        // authenticate using private key
        // jsch.addIdentity(<destino da chave ssh>);

        // authenticate using password
        jschSession.setPassword("password1234");

        // 10 seconds session timeout
        jschSession.connect(100000);

        sftp = jschSession.openChannel("sftp");

        return  (ChannelSftp) sftp;

    }

    /* armazenar imagem servidor SFTP */
    public static void salvarImagemSftp(InputStream storedImage, String originalFilename) throws SftpException, JSchException {

        Session jschSession = null;

        Channel sftp = null;
        // transfer file from local to remote server
        ChannelSftp channelSftp = setupJsch();
        channelSftp.connect(50000);

        channelSftp.put(storedImage,channelSftp.getHome() + "/" + originalFilename );

        channelSftp.exit();

        System.out.println("Done");

    }

    /* buscar imagem servidor sftp e transferir para pasta local */
    public static void buscarImagemSftp(String originalFilename) throws SftpException, JSchException {

        Session jschSession = null;

        Channel sftp = null;
        // transfer file from local to remote server
        ChannelSftp channelSftp = setupJsch();
        channelSftp.connect(50000);

        channelSftp.get(channelSftp.getHome() + "/" + originalFilename, "C:\\Users\\Dell\\Desktop\\testeImagem" );

        channelSftp.exit();

        System.out.println("Done");

    }

    /* deletar imagem servidor sftp */
    public static void deletarImagemSftp(String nomeImagem) throws SftpException, JSchException {

        Session jschSession = null;

        Channel sftp = null;
        // transfer file from local to remote server
        ChannelSftp channelSftp = setupJsch();
        channelSftp.connect(50000);

        channelSftp.rm(channelSftp.getHome() + "/" + nomeImagem);

        channelSftp.exit();

        System.out.println("Done");

    }
}

Agora vamos criar uma classe controller para testarmos o envio de imagens para nosso servidor SFTP e uma classe model para mapear a imagem que vamos receber pelo input via controller.
Imagem

import org.springframework.web.multipart.MultipartFile;

@Data
@AllArgsConstructor
@NoArgsConstructor
public class Imagem {

    private MultipartFile file;
}
```


`ImagemController`


```
package com.example.sftp;

import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.io.InputStream;

@RestController
public class ImagemController {

    @PostMapping("/imagem")
    public void armazenarImagemApenasSftp(Imagem imagem) throws IOException {
        InputStream image = imagem.getFile().getInputStream();

        try{
            SftpConfig.salvarImagemSftp(image, imagem.getFile().getOriginalFilename() );
        }catch (Exception e){
            System.out.println(e.getMessage());
            throw new IOException("Erro ao salvar imagem no cdn");
        }
    }

    @GetMapping("/imagem")
    public void buscarImagemSftp() throws IOException {

        try{
            SftpConfig.buscarImagemSftp("tcc.png");
        }catch (Exception e){
            System.out.println(e.getMessage());
            throw new IOException("Erro ao salvar imagem no cdn");
        }
    }

    @DeleteMapping("/imagem")
    public void deletarImagemSftp() throws IOException {

        try{
            SftpConfig.deletarImagemSftp("tcc.png");
        }catch (Exception e){
            System.out.println(e.getMessage());
            throw new IOException("Erro ao salvar imagem no cdn");
        }
    }
}
```



Vamos testar nossa aplicação via postman.

**requisicao para salvar imagem**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fn561t1ghl208t8ud61t.png)

**imagem salva em nosso servidor**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vpyej4732rthm2qqoz9q.png)

**requisicao para buscar imagem servidor SFTP e tranferir pasta local**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ku0cmt2ouqe6d5uwezh0.png)


**imagem salva na pasta passada como path**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/akeaxhfmdgxbdv8afnma.png)

**requisicao para deletar imagem servidor SFTP**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pu3gdxicmwyr8t0igmcr.png)

**imagem deletada do servidor SFTP**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jnc1ofj88ixxyhegacn2.png)

E isso ai devs mas um conhecimento passado, deixarei no meu [github](https://github.com/2020nani/sftp-springboot) para quem quiser acessar o projeto
Deixo aqui também meu [linkedin](https://www.linkedin.com/in/nanialmeida/) para quem quiser me adicionar, grato a todos que leram este artigo e bora aprender galera.