DEV Community: Jordi Henrique Silva

Como utilizar o Type aliases do Kotlin para facilitar o Design de Código

Jordi Henrique Silva — Mon, 30 Sep 2024 15:59:24 +0000

No último ano pude trabalhar em diferentes projetos que utilizaram Kotlin como linguagem principal, nisso aprendi diferentes funcionalidades que impactaram em maior facilidade de escrita de código mais legível e manutenível. Uma das funcionalidades que me chamaram a atenção foi Type aliases que permite a nomeação para outros tipos já existentes, facilitando o uso em qualquer ponto do sistema. Como, por exemplo, quando você tem dados como Email e CPF mapeados como tipo primitivo string, mas que poderiam ter seus próprios tipos dado suas características específicas.

Como uso o Type aliases para melhorar meu código?

Bom imagine que você tenha que representar uma Pessoa no sistema, e a mesma deve ter nome, cpf e email como dados. Abaixo tem um exemplo de como poderia ser modelada a classe Pessoa.

class Person(val name: String, val cpf: String, val email: String)

Este mapeamento já é suficiente para que o sistema funcione, porém, no desenvolvimento do projeto, outros diversos pontos do sistema, iram trabalhar com conceito de email e cpf. Então utilizaremos o type aliases para definir um tipo para cada um dos conceitos.

typealias Email = String
typealias Cpf= String

Agora em qualquer ponto do sistema é possível declarar os tipos de Email e Cpf. Veja como fica a declaração da classe pessoa com os novos tipos.

class Person(val name: String, val cpf: Cpf, val email: Email)

Legal né? Isso abre muitas possibilidades de uso, até mesmo para aplicação de Polimorfismo.

Olhá só o que aconteceu comigo...

Estava realizando a correção de um débito técnico, na situação era um sistema em Spring Boot com Kotlin, e a tarefa era fazer com que uma API de atualização existente fosse mais dinâmica. O que quero dizer com mais dinâmica, é que a API no momento recebia um contrato com N critérios de atualização, porém, conforme a quantidade de critérios crescia, o código tornava-se mais difícil e longo de ser lido. E para piorar, o comportamento da função não era alterado!!

@Service
public class UpdatePersonService(
  @Autowired
  val manager: EntityManager
){

  @Transactional
  fun update(personId: Long,  updateModel: UpdatePersonModel){
      val person = manager.find(Person::class.java, personId)

      if(updateModel.hasName){
          person.name = updateModel.name
      }

      if(updateModel.hasCpf){
          person.cpf=updateModel.cpf
      }

      if(updateModel.hasEmail){
          person.email=updateModel.email
      }

  }

}

O código acima ilustra a situação, onde a função update() tem a responsabilidade de atualizar os dados da entidade Pessoa, cada dado para ser atualizado, deve atender o seu critério, como, por exemplo, para atualizar o cpf, a propriedade hasCpf deverá ser verdadeira. e assim sucessivamente até o fim dos critérios. O comportamento desta função é garantir que o contrato de atualização entre Person e UpdatePersonModel esta sendo cumprido.

Foi aí que vi a oportunidade de combinar as coisas...

Ao observar o código podemos visualizar cada condição com o seguinte contrato de função.

(person: Person, updateModel: UpdatePersonModel) -> Unit

E após visualizá-los, percebi que o código poderia ser refatorado para possibilitar o crescimento de critérios sem causar mais alterações no código da função update(). Então, o primeiro passo foi transformar cada condição em uma função, e organizá-las em um arquivo chamado UpdatePersonFunction.kt.

  fun updateName(person: Person, updateModel: UpdatePersonModel){
    if(updateModel.hasName){
        person.name = updateModel.name
    }
  }
  fun updateDocument(person: Person, updateModel: UpdatePersonModel){
    if(updateModel.hasDocument){
        person.document=updateModel.document
    }
  }
  fun updateAddress(person: Person, updateModel: UpdatePersonModel){
    if(updateModel.hasAddress){
          person.address=updateModel.address
    }
  }

Em seguida, utilizei o type aliases do kotlin para definir o contrato da função como tipo UpdatePersonAction, que representa uma função que receba dois argumentos, um do tipo Person e outro do tipo UpdatePersonModel, e não possui retorno.

private typealias UpdatePersonAction = (person: Person, updateModel: UpdatePersonModel) -> Unit

Após a definição do tipo, bastou criar uma coleção de funções do tipo UpdatePersonAction, e adicionar a referência de cada uma delas.

@Service
public class UpdatePersonService(
@PersistenceContext val   manager: EntityManager
){
  private val updatePersonFunctions = listOf<UpdatePersonAction>(
      ::updateName,
      ::updateDocument,
      ::updateAddress
  )

  @Transactional
  fun update(personId: Long,  updateModel: UpdatePersonModel){
      val person = manager.find(Person::class.java, personId);

      updatePersonFunctions.forEach(updateAction ->{
          updateAction.invoke(person, updateModel)
          }
      );
  }  
}

E por fim, alterar o código da função update(), para percorrer a coleção, e fazer a invocação da cada função com os argumentos. Desta forma, às funções que atenderem seus critérios serão aplicadas e as demais não.

Espero que este artigo sirva de alguma inspiração para você explorar novas funções e cada vez mais escrever códigos que sejam fáceis de serem lidos e entendidos.

E você já utilizou o type aliases em algum projeto? Deixa nos cometários como foi sua experiência!

Evoluindo sua estratégia de Testes para FileUpload com Spring Test e Amazon S3

Jordi Henrique Silva — Wed, 10 Jul 2024 11:15:01 +0000

Em meu último artigo, discutimos como pode ser implementado um serviço de file upload utilizando Spring Boot e Amazon S3. Lá entendemos quais são as preocupações e ferramentas necessárias para permitir que você customize as regras de como gerenciar seus arquivos. Se você não leu ainda, recomendo que o faça, antes de ler este artigo.

Desvendando o Segredo: Como Implementar File Upload com Spring Boot e Amazon S3

Jordi Henrique Silva ・ Jun 20

#aws #spring #java #amazons3

Após publicar o artigo, percebi que diversas pessoas tinham dúvidas de quais os possíveis caminhos para escrever testes que tragam segurança e confiabilidade para o File Upload.

Dado a isso, hoje vamos bater um papo sobre como podemos evoluir a estratégia de testes, partindo dos testes unitários até os queridos testes de integração.

OBS: A escolha da estratégia de testes pode variar dado contexto, como, por exemplo, familiaridade da equipe com tecnologia, conhecimento técnico, limitação do ambiente, etc.

Escrevendo Testes de Unidade

Essa é de longe a estratégia mais utilizada pelos Dev's e Empresas, e seu principal objetivo é validar se cada pedaço de código isolado funciona como esperado. Então é comum que nessa técnica as características estruturais do código sejam validadas, esta técnica é indicada para sistemas que possuem logicas complexas, como, por exemplo: cálculo de juros, folha de ponto, e qualquer outro sistema que possua logica com alto uso de estrutura de decisão e repetição.

Outro ponto interessante sobre os testes de unidade, é que como seu objetivo é validar a menor unidade de código possível, normalmente quando a classe ou método que esta sendo testado possui dependências internas ou externas costuma-se simular esse comportamento, e isso é o que chamamos de Mock's ou Dublê. Normalmente quando se escreve testes desta categoria, utilizamos ferramentas como JUnit, Hamcrast, assertJ e Mockito.

Vamos ver como funciona na prática

Antes de iniciar a construção do teste, vamos relembrar o código de produção, que foi divido em duas classes, a classe FileUpload representa o arquivo que será armazenado no S3, e FileStorageService que representa o serviço que se integrará com Amazon S3 e fará o upload dos arquivos.




public record FileUpload(MultipartFile data){}

@Service
public class FileStorageService {
    @Autowired
    private S3Template template;

    private String bucket = "myBucketName";

    public String upload(FileUpload fileUpload) {

        try (var file = fileUpload.data().getInputStream()) {
            String key = UUID.randomUUID().toString();
            S3Resource uploaded = template.upload(bucket, key, file);
            return key;
        } catch (IOException ex) {
            throw new RuntimeException("Não foi possivel realizar o upload do documento");
        }
    }
}

O código acima pode ser resumido em, inicialmente, o método upload() recebe uma instância da classe FileUpload que carrega um MultipartFile recebido mediante uma chamada HTTP. Em seguida, o arquivo a ser salvo no bucket, é aberto dentro do try-with-resources, caso alguma exceção seja lançada na abertura do arquivo, a mesma é tratada, e a streaming de dados é fechada automaticamente, causando a interrupção da execução do método. Caso contrário é criado uma chave de acesso ao arquivo, e envia respectivamente o arquivo para o Amazon S3, finalizando o método retornando sua chave de acesso.



@ExtendWith(MockitoExtension.class)
class FileStorageServiceUnitTest {
    @Mock
    private S3Template s3Template;
    @Mock
    private MultipartFile file;
    @Mock
    private S3Resource uploaded;
    private String bucketName = "myBucketName";

    @Test
    @DisplayName("Deve fazer o upload de um arquivo")
    void t0() {
        //cenario
        FileUpload fileUpload = new FileUpload(file);
        FileStorageService fileStorageService = new FileStorageService(s3Template, bucketName);
        when(s3Template.upload(any(), any(), any())).thenReturn(uploaded);

        //acao
        String acesseKeyFile = fileStorageService.upload(fileUpload);

        //validacao
        assertNotNull(acesseKeyFile);
    }

}

Iniciamos a escrita dos testes unitários, definindo a classe que será responsável por agrupar os casos de testes, a mesma deve ser preparada para oferecer suporte a execução do Mockito junto a ferramenta JUnit. Dado a isso, o primeiro passo será anotar a classe com @ExtendWith(MockitoExtension.class), que permitirá a definição de dubles (Mocks) através das anotações @Mock e @Spy. Em seguida cuidamos de provisionar as dependências do S3Template e MultipartFile, como não iremos provisionar o contexto do Spring, precisaremos definir os comportamentos das mesmas, então definimos as mesmas como Mocks, anotando previamente cada atributo com @Mock. Também iremos precisar de simular a resposta do S3Template, que retorna um objeto do tipo S3Resource, então também declaramos um atributo previamente anotado com @Mock.

O próximo passo é a definição do nosso caso de teste, então separamos o testes em 3 etapas, sendo elas: cenário, ação e validação. Na etapa cenário vamos definir as dependências que o teste precisa para executar, então é inicialmente criado uma instância do FileUpload, que recebe o duble do MultipartFile que definimos anteriormente. Como o FileStorageService executa o método upload() do S3Template precisamos definir este comportamento através da API de When do Mockito, que cria um gatilho para que Quando o método s3Template.upload() seja chamado, com qualquer entrada, o objeto S3Resource seja retornado na resposta. Por fim, instanciamos a FileStorageService que recebe via construtor o nome do bucket e o duble do S3Template.

Já na etapa de ação, é onde vamos executar o nosso código de produção para colher o resultado e aplicar uma validação de modo a garantir que o resultado é equivalente ao esperado. Então simplesmente invocamos o método fileStorageService.upload() e armazenamos sua resposta a fim de executar as validações na próxima etapa. Na etapa de validação, vamos validar se realmente existe uma chave de acesso ao recurso criado, e para isso utilizaremos o assertNotNull já que a criação da chave de acesso não está em nosso controle.

Ai eu te pergunto, como esse teste me ajuda a garantir que o FileUpload funciona como deveria?

Em suma, esse teste ajuda muito pouco a trazer segurança e qualidade ao desenvolvimento da funcionalidade, já que o mesmo, busca cobrir apenas características estruturais do código, como operadores If, Else, For, Try, entre outros. Sem falar que um teste de unidade, toda execução é feita em memória, o que torna o extremamente rápido, porém, como nem tudo são flores, deixamos de validar toda a configuração da integração com Spring Cloud AWS e Amazon S3. Sem falar que a integração propriamente dita nem é executada, podendo ocasionar em erros não esperados durante a execução em produção.

A solução para o problema descrito acima, é aproximar o cenário do teste ao ambiente de produção, e a boa notícia é que o Spring Test fornece uma ampla gama de ferramentas que permitem executar o contexto do framework e se integrar a containers e dependências externas, como eu disse em:

3 dicas para criar uma estratégia moderna de Testes para Microsserviços Spring Boot

Jordi Henrique Silva ・ Feb 19

#spring #testing #integrationtests #microservices

Evoluindo para um Teste de Integração com Spring Test, Test Containers e LocalStack

Antes de sair modificando o teste, precisamos adequar nossas dependências, então já adicione em sua ferramenta de build, as dependências de Spring Test Containers, TestContainers JUnit e LocalStack.



@SpringBootTest
@Testcontainers
@ActiveProfiles("test")
class FileStorageServiceTest {
    @Autowired
    private S3Template s3Template;
    @Value("${s3.bucket.name}")
    private String bucketName;
    @Value("classpath:uploads/file.txt")
    private Resource file;
    @Autowired
    private FileStorageService fileStorageService;

    @Container
    static LocalStackContainer LOCALSTACK_CONTAINER = new LocalStackContainer(
            DockerImageName.parse("localstack/localstack")
    ).withServices(S3);

    @DynamicPropertySource
    static void registerS3Properties(DynamicPropertyRegistry registry) {
        registry.add("spring.cloud.aws.endpoint",
                () -> LOCALSTACK_CONTAINER.getEndpointOverride(S3).toString());
        registry.add("spring.cloud.aws.region.static",
                () -> LOCALSTACK_CONTAINER.getRegion().toString());
        registry.add("spring.cloud.aws.credentials.access-key",
                () -> LOCALSTACK_CONTAINER.getAccessKey().toString());
        registry.add("spring.cloud.aws.credentials.secret-key",
                () -> LOCALSTACK_CONTAINER.getSecretKey().toString());
    }

    @BeforeEach
    void setUp() {
        s3Template.createBucket(bucketName);
    }

    @AfterEach
    void tearDown() {
        s3Template.deleteBucket(bucketName);
    }

    @Test
    @DisplayName("Deve fazer o upload de um arquivo")
    void t0() throws IOException {
        //cenario
        MockMultipartFile fileRequest = new MockMultipartFile("data", file.getInputStream());
        FileUpload fileUpload = new FileUpload(fileRequest);
        //acao
        String keyAcessResource = fileStorageService.upload(fileUpload);
        //validacao
        assertTrue(s3Template.objectExists(bucketName, keyAcessResource));
        s3Template.deleteObject(bucketName, keyAcessResource);
    }

}

A primeiro momento, precisamos adaptar nossa classe de testes, para suportar a inicialização do ApplicationContext do Spring. Também é necessário que as configurações referentes ao ambiente de teste sejam aplicadas, então anotaremos a classe com @SpringBootTest e @ActiveProfiles("test"). Em seguida, vamos indicar para o JUnit que essa classe de teste faz o uso de containers gerenciados pelo TestContainers, então adicionamos a anotação @Testcontainers sobre a assinatura da classe.

O próximo passo, é indicar as dependências que utilizaremos durante a escrita do teste, para este caso, iremos precisar obter do ApplicationContext instâncias do S3Template, FileStorageService, então utilizaremos a injeção de dependências via campo, anotando os atributos previamente com @Autowired. E para finalizar esta etapa, colheremos a propriedade: s3.bucket.name para obter o nome do bucket.
E também iremos colher o arquivo que será enviado ao bucket, então anotaremos os campos, file e bucketName respectivamente com a anotação @Value.

Na etapa atual, nosso objetivo é criar a infraestrutura necessária para que o JUnit seja capaz de instanciar um container da LocalStack, expondo o serviço do Amazon S3, e em seguida integrando o mesmo no ApplicationContext. A primeiro momento iremos definir o container, através da abstração LocalStackContainer, como desejamos que o JUnit gerencie o ciclo de vida do container, anotaremos este atributo com @Container. Por fim, não menos importante, vamos conectar o S3 a Aplicação através do método registerS3Properties() que cuida, de atualizar os valores das properties de conexão com os dados do container.

Após preparar a aplicação para simular o cenário mais próximo de produção possível, podemos partir para escrita dos testes. Lembramos que uma característica essencial dos testes é que devem garantir o isolamento um dos outros. Então como boa prática, foi definido os métodos setUp() e tearDown(), que irão auxiliar na construção e destruição do ambiente para cada caso de teste. O método setUp() está previamente anotado com @BeforeEach para ser executado antes de cada teste e crie o bucket com nome definido. Já o método tearDown() está anotado com @AfterEach para ser executado ao fim de cada teste, destruindo o bucket criado anteriormente.

Por fim, iniciaremos a construção do nosso teste de integração, então ao dividiremos o teste, nas queridas etapas de cenário, ação e validação. No cenário, criaremos um objeto do tipo MockMultipartFile informando o nome do campo, e o file obtido no classpath anteriormente. Por fim, instanciamos um FileUpload recebendo o MultipartFile criado. Na etapa de ação, invocamos o serviço de storage e realizamos o upload do arquivo, recebendo como retorno a sua chave de acesso. já na etapa de validação, podemos validar se o arquivo realmente existe no bucket, garantindo assim o comportamento esperado nosso serviço, através da validação do efeito colateral. Você pode ter mais detalhes do código neste repositório.

Conclusão

Durante este artigo podemos observar que existem diversas estratégias para escrita de testes em um sistema que realizar o upload de arquivos em um bucket do S3. E que ao fazer escolha de uma estratégia de testes, devemos avaliar antes, as limitações que o ambiente nós trazemos, o nível de competência da equipe com as ferramentas e até mesmo o tempo disponível para uma determinada entrega.

Também foi discutido como os testes unitários favorecem uma cobertura de características relacionadas a estrutura do código, e são ótimos validadores da escrita de lógicas que se baseiam em estruturas de decisão, controle, repetição. Porém, são péssimos candidatos a cobertura de características que estejam relacionadas as operações de I/O, já que por natureza todo teste de unidade é rodado em memória e normalmente possuem alto uso de mocks, que evitam o comportamento real do sistema.

Sendo assim, uma estratégia interessante para contexto onde a maioria das operações são de I/O é o uso de testes de integração, já que os mesmos, se aproximam do cenário de produção, permitindo a antecipação de erros e bugs, que poderiam ser descobertos nas etapas de CI e CD e pelo usuário final do sistema.

Agora me diz você, qual estratégia faz mais sentido em seu contexto? Deixe nos comentários.

Não se esqueça de me seguir nas redes sociais para receber mais dicas sobre Engenharia de Software e Desenvolvimento Backend.

Linkedin
Twitter
Instagram

Desvendando o Segredo: Como Implementar File Upload com Spring Boot e Amazon S3

Jordi Henrique Silva — Thu, 20 Jun 2024 23:29:16 +0000

Não é de hoje que empresas e também pessoas tem necessidade de armazenar e gerenciar arquivos de forma segura e eficiente. Um bom exemplo disso é que até hoje existe uma alta procura por produtos como SDD, Pendrives, HDD externos. Sem falar que empresas como Amazon, Google, Apple, Microsoft vendem armazenamento em cloud em diferentes escalas e preços.

Storage de arquivo pode atender clientes em diversas categorias, desde os usuários comuns por meio de produtos como Google Drive, One Drive e ICloud. Até mesmo empresas de todos os tamanhos, com a necessidade de utilizar sistemas customizados para gerenciar seus arquivos.

Os clientes da Cloud Amazon Web Service, podem escrever suas aplicações para se integrar ao Amazon Simple Storage Service (S3), o serviço de armazenamento distribuído seguro e escalável, que pode ser acessado de diferentes aplicativos e plataformas por meio de API's.

Hoje é possivel escrever aplicações nas mais diversas linguagens e plataformas, utilizando o SDK da Amazon para gerenciar seus arquivos. E para nós javeiros não é diferente, podemos nos basear no SDK ou utilizar algum framework como Micronaut, Quarkus e Spring, para nos auxiliar neste processo.

E a pergunta que não quer calar? Como Implemento um FileUploader com Spring Boot e Amazon S3?

A solução deste problema é dividida em duas etapas, a primeira etapa é onde iremos realizar a configuração da aplicação para utilizar o Amazon S3 em um projeto Spring. E por fim, será construído o serviço responsável por fazer o upload dos arquivos no bucket.

1 - Configurando a Aplicação para Utilizar o Amazon S3

Então, vamos lá! O Spring Cloud AWS é um módulo construído para abstrair o uso de serviços da AWS para aplicativos Spring Boot. Inclusive existe um starter para aplicações que utilizaram apenas o modulo para uso do Amazon S3, se trata do Spring Cloud AWS S3, que oferecem a diferentes formas de acessar e utilizar o Bucket no sistema, e também conta com a abstração S3Template que torna simples e intuitivo o ato de executar operações de consulta, inserção e deleção no S3. Então o primeiro passo é adicioná-la nas dependências do projeto.

Em seguida, iremos trabalhar na configuração do Spring Cloud AWS S3, a fim de permitir que o mesmo faça o acesso ao bucket no S3, para isso devemos informar o Endpoint de acesso ao bucket, a região que o bucket esta disponível, e as credenciais de acesso à conta da AWS.



spring.cloud.aws.endpoint=${AWS_ENDPOINT:http://s3.localhost.localstack.cloud:4566} 
spring.cloud.aws.region.static=${AWS_REGION:us-east-1}
spring.cloud.aws.credentials.access-key=${AWS_ACCESS_KEY:localstackAccessKeyId}
spring.cloud.aws.credentials.secret-key=${AWS_SECRET_KEY:localstackSecretAccessKey}

No código acima, iniciamos definindo o endpoint de acesso ao bucket, através da propriedade spring.cloud.aws.endpoint. Em seguida, definimos que a região em que o bucket se encontrar por via da propriedade spring.cloud.aws.region.static, por fim definimos as credenciais de acesso à conta através das propriedades spring.cloud.aws.credentials.access-key e spring.cloud.aws.credentials.secret-key.

Os demais detalhes do projeto pode ser consultados no repositorio abaixo:

JordiHOFC / sample-storage-file-with-spring-aws-s3

This repository is about how to implemented FileUpload Application with Spring Boot and Amazon S3

2 - Escrevendo o Serviço de Upload de Arquivo

Nesta etapa vamos definir o código responsável por receber um arquivo e fazer o upload dele no Amazon S3. Antes de iniciar a construção é preciso entender como funciona a postagem de um arquivo. No Amazon S3 você pode definir um bucket. Eu ouvi certo? Um balde? Sim, no S3 o bucket é um tipo de diretório que irá armazenar seus objetos, que podem ser arquivos, imagens, musicas, e qualquer outro tipo de objeto independente do seu tipo de mídia. Esse objeto deve ter uma chave única de acesso (Key), que irá ser utilizada para geração de links de download, atualização e deleção do objeto.

Então iremos iniciar o processo, definindo a abstração responsável por representar um Arquivo. Em seguida, definiremos o bean FileUploadService que será responsável por gerenciar as operações sobre os Arquivos. E por fim, iremos construir o método responsável por fazer Upload no bucket.



public record FileUpload(MultipartFile data){}

O código apresentado acima, define uma abstração que representa um arquivo que irá ser persistido no storage de arquivos. O FileUpload tem um único campo do tipo MultipartFile que é uma abstração do Spring Web para representar um arquivo que foi submetido através de uma requisição web.

Após a definição da abstração seguiremos para definição do serviço de upload.



@Service
public class FileStorageService {
    @Autowired
    private S3Template template;

    private String bucket = "myBucketName";

    public String upload(FileUpload fileUpload) {

        try (var file = fileUpload.data().getInputStream()) {
            String key = UUID.randomUUID().toString();
            S3Resource uploaded = template.upload(bucket, key, file);
            return key;
        } catch (IOException ex) {
            throw new RuntimeException("Não foi possivel realizar o upload do documento");
        }
    }
}

O código pode ser resumido da seguinte forma, primeiro definimos a classe FileStorageService como um bean de serviço, através da anotação @Service, em seguida, injetamos o S3Template através do campo template previamente anotado com @Autowired. Em seguida, é definido o método upload, que retorna a String referente a chave de consulta do arquivo no Bucket, e recebe o FileUpload que será persistido.

A lógica de upload do arquivo é um pouco sensível, dado que manipular arquivos em Java exigem que o arquivo seja fechado, o que é muito fácil de ser esquecido, e pequenos erros, sutis como este, levam a problemas de vazamento de memória que podem prejudicar o funcionamento da aplicação.

Dado a esta exigência, foi utilizado a instrução try-with-resource, que tenta abrir o arquivo dentro da cláusula try, caso tenha sucesso, o mesmo é fornecido para uso dentro do escopo da instrução e fechá-lo automaticamente quando a execução for finalizada. Caso contrario podemos fazer um tratamento de exceção personalizado com as instruções catch. No escopo do bloco try, é onde a mágica acontece, então definimos uma chave de acesso única para arquivo, e utilizamos o método upload do S3Template, informando o bucket de destino, a chave de acesso, e o inputStream do arquivo, caso nenhuma IOException não seja lançada, retornamos a chave de acesso.

Conclusão

Armazenar e gerenciar arquivos é uma necessidade de muitas pessoas e empresas, não é à toa que os grandes players do mercado como Amazon, Google, Apple, Microsoft e outros, vem lucrando com a venda dos seus produtos de Storage.

É comum que empresas de todos os tamanhos precisem definir processos e logicas customizadas para o armazenamento e uso de seus arquivos, e uma boa solução é o desenvolvimento de um software que cuide de garantir as regras e comportamentos para o gerenciamento dos seus arquivos, que serão armazenados em um serviço storage distribuído como Amazon S3.

O Spring Cloud AWS é um módulo focado em abstrair o uso de serviços da Cloud AWS para aplicações Spring, e contém um starter que facilita a integração com os buckets do S3. A construção de um serviço que manipule arquivos deve ser feita com cuidado, já que conforme os arquivos são abertos, os mesmos devem ser fechados, para não ocasionar vazamentos de memória. Porém, podemos mitigar isso, utilizando o try-with-resource, que abstrai o processo de fechamento do arquivo.

3 dicas para criar uma estratégia moderna de Testes para Microsserviços Spring Boot

Jordi Henrique Silva — Mon, 19 Feb 2024 20:42:52 +0000

A verdade é que uma entrega de software com qualidade, é formada por uma base de código que tenha bom design, e que permita o crescimento e evolução do software com simplicidade, qualidade e segurança durante seu ciclo de vida. Junto há uma bateria de testes que agregue segurança na evolução e manutenção do software. E que também ofereça a oportunidade de antecipar o encontro de bugs e anomalias.

E no contexto de arquiteturas distribuídas ou altamente distribuídas, como no caso de Microsserviços, onde majoritariamente os desafios estão concentrados em garantir que os diferentes sistemas comuniquem-se bem entre-si. Estas dificuldades também se estendem para os testes, e caso optemos por utilizar apenas testes de unidade, deixaremos de captar falhas referentes a processos básicos do nosso sistema, como serialização, desserialização, mapeamento dos clientes HTTP e até mesmos que nossas operações juntos a bancos de dados, brokers MQ sejam feitas como eu já disse em:

3 motivos do porquê testes unitários não são suficientes para Microservices com Spring Boot

Jordi Henrique Silva ・ Dec 14 '22

#spring #java #testing #microservices

Pensando nisto, separei 3 dicas para te ajudar, a escrever testes que aumentem a segurança e corretude dos sistemas em que trabalha.

1. Entenda o contexto e conheças as dependências da sua solução

O primeiro passo para escrever um codigo de teste, é ter bom entendimento sobre o código de produção, principalmente quando nos apoiamos em frameworks de IoC/DI como Spring, onde utilizamos outros beans em composição com nossa lógica de negócio. Então aqui aparecem ferramentas de cache, bancos de dados relacionais e não relacionais, clientes HTTP, gRPC e outros.

Entender como as dependências interagem entre-si lhe permite identificar o que é necessário para o seu cenário de teste. Desde quais dependências precisaram ser simuladas e também quais são as entradas necessárias para o teste.

2. Utilize ferramentas de testes modernas como TestContainers e WireMock para simular suas dependências

Essa dica é como a cereja do bolo, traz refinamento a sua suíte de testes, pois, com uso destas ferramentas, você pode simular de maneira fidedigna os serviços que serão integrados em produção. Ao aproximar a execução dos testes ao cenário de produção, conseguiremos validar detalhes como, conexão com a ferramenta, configuração dos beans via properties ou programaticamente. Ao utilizar ferramentas como TestContainers podemos fazer com que nosso testes executem seus cenários que exigem o Redis como Cache Distribuído, através de containers gerenciados pelo JUnit. Ou até mesmo serviços da AWS como S3, SQS, SNS e DynamoDB.

Já quando você opta por utilizar Wiremock, você ganhará confiança em suas integrações REST, pois, Wiremock permite que você simule a resposta de Servidores HTTP, através de seus contratos. Desta forma, aquele cliente que você mapeou a chamada a uma API, será executado, e ainda na execução dos testes você terá validações se o contrato é respeitado, ou se o seu código de produção exige que modificações sejam feitas.

3. Escreva seus testes nas etapas de Cenário, Ação e Validação ou AAA Pattern.

A ideia do aqui é basicamente separar seu teste em 3 estágios, cenário, ação e validação, ou como a literatura diz em Unit Testing Principles, Practices, and Patterns, Arrange, Act e Assert.

O primeiro estágio é onde nos preocupamos em provisionar o Cenário necessário para execução da nossa solução. Este estágio é onde criamos os objetos de domínio que serão utilizados como massa para o teste, caso nossa solução utilize dependências externas, devemos provisioná-las ou Mockar as mesmas, de modo a definir seus comportamentos.

Não existe segredo para o estágio de Ação, nele é onde invocamos a execução do nosso código de produção que desejamos testar, e armazenamos a resposta para ser utilizada na próxima etapa. E por fim, iremos cuidar da etapa de Validação do teste, escrevendo um conjunto de sentenças que tragam garantia que o comportamento executado pelo código de produção, entrega o esperado, utilizaremos os asserts para validar se os resultados correspondem ao planejado.

Vamos ver na prática?

Para entender um pouco melhor vamos imaginar a seguinte situação, dado um fluxo de um sistema que realiza venda de produtos, é necessário que você implemente um serviço que calcule o frete para uma determinada venda. Neste calculo será necessário que você se integre a API da transportadora para calcular uma simulação de frete. Para executar a simulação, será necessário que obtenha o peso total do pedido, e o código postal, do destino, para seja calculado um valor e estimativa de data de entrega para o frete.



POST www.suatransportadora.com/v1/frete
{
    "origem": "32569-455",
    "destino": "39856-151",
    "valor": 45.5,
    "peso": 784,
    "comprimento": 25,
    "altura": 10,
    "largura": 4
}

A chamada HTTP acima, corresponde ao contrato que deve ser utilizado para se integrar a REST API de fretes da transportadora. E abaixo você encontrará uma implementação do serviço de fretes em Spring Boot.



@Service
public class CalculaFreteService{
    @Autowired
    private ProdutoRepository repository;
    @Autowired
    private TransportadoraClient freteClient;
    @Value("${default.cep.origem}")
    private String cepOrigem;

    @Transactional(readOnly = true)
    public Frete calcular(SolicitacaoCompra solicitacaoCompra) {
        List<Produto> produtos = repository.findAllById(solicitacaoCompra.produtos());

        var altura = produtos.stream().max(alturaComparator()).get().getAltura();
        var largura = produtos.stream().max(larguraComparator()).get().getLargura();
        var comprimento = produtos.stream().max(comprimentoComparator()).get().getComprimento();
        var valor = produtos.stream().map(Produto::getPreco).reduce(BigDecimal.ZERO, BigDecimal::add);
        var peso = produtos.stream().map(Produto::getPeso).reduce(BigDecimal.ZERO, BigDecimal::add);

        var freteRequest = new FreteSimulationRequest(
                altura,
                largura,
                comprimento,
                peso,
                cepOrigem,
                solicitacaoCompra.cepDestino(),
                valor
        );
        try {
            var simulacao = freteClient.simulate(freteRequest);
            return new Frete(simulacao);
        } catch (FeignException.FeignClientException.BadRequest ex) {
            throw new InvalidIntegrationException("Entradas nao suportadas");
        }
    }
}

O codigo apresentado acima, pode ser resumido em, o sistema recebe o cep de destino e os identificadores dos produtos que serão entregues. Em seguinda os produtos são buscados no banco de dados, e as caracteristicas de largura, altura e comprimento do recipiente que armazenará os produtos, junto ao peso, e o valor do produto são obtidos, para serem utilizados como entrada da integração da API de fretes. Após obter estes dados, uma chamda HTTP é feita a API da Transportadora para calcular o custo do frete. Caso a requisição seja executada com sucesso, os dados do frete são retornados, caso contrário uma resposta de erro será retornada.

Aplicando o conhecimento

Agora que conhecemos nosso serviço, e também aprendemos sobre como extrair melhor valor de ferramentas modernas de testes, podemos somar com conhecimento de Spring Test e JUnit para construir teste que aproximem a execução do serviço em produção.

Então antes da escrita do primeiro teste, é necessário identificar e provisionar as dependências exigidas para execução no serviço, conforme discutimos isso em Entenda o contexto e conheças as depêndencias da sua solução. Conhecer os pontos de integração do sistema, permite que você habilite em seu sistema, a capacidade de fornecer as mesmas. Então em primeiro lugar habilitaremos novas dependências ao sistema, como o starter do Spring Cloud Contract WireMock em nosso projeto, atravrés de seu starter. Também é necessário adicionar as depêndecias os starters do Spring TestContainers, JUnit Test Containers. Como nosso sistema se integrar a um PostgreSQL, também será necessário adicionar o TestContainers Postrgres.



@SpringBootTest
@ActiveProfiles("test")
@AutoConfigureWireMock(port = 0)//habilita que uma porta aletoria seja utilizada no WireMockServer
@Testcontainers
class CalculaFreteServiceTest {
    @Container
    @ServiceConnection
    static PostgreSQLContainer<?> container = new PostgreSQLContainer<>(
            DockerImageName.parse("postgres:latest")
    );

    @Autowired
    private CalculaFreteService service;

    @Autowired
    private ProdutoRepository produtoRepository;

    @Autowired
    private ObjectMapper mapper;

    @BeforeEach
    void setUp() {
        produtoRepository.deleteAll();
    }


    @Test
    void deveCalcularOFrete() throws JsonProcessingException {
        //cenario
        Produto produto = new Produto(
                "Joystick Xbox One", "Joystick wireless", BigDecimal.TEN,
                new Caracteristica(
                    new BigDecimal("17.7"),
                    new BigDecimal("17.8"),
                    new BigDecimal("7.2"),
                    new BigDecimal("300")
                )
        );

        produtoRepository.save(produto);

        stubFor(
            post(urlPathMatching("/v1/frete"))
                .willReturn(
                    aResponse()
                        .withStatus(HttpStatus.CREATED.value())
                        .withHeader("content-type", MediaType.APPLICATION_JSON_VALUE)
                        .withBody(toJson(getSimulacaoDoFrete()))
                )
        );


        //acao
        Frete frete = service.calcular(new SolicitacaoCompra(List.of(produto.getId()), "32604189"));

        //validacao
        assertEquals(
                new BigDecimal("42.35"), frete.getValor()
        );
        assertNotNull(frete.getEstimativaDeEntrega());
        assertEquals(
                "32605125", frete.getOrigem()
        );
        assertEquals(
                "32604189", frete.getDestino()
        );

    }
}

O primeiro passo deste teste é habilitar o uso do ApplicationContext na execução do seu teste, através da anotação @SpringBootTest, dado a isso, o processo de startup do sistema será iniciado, instanciando todos os beans necessários para a execução do sistema. Esta anotação faz com que durante a execução do teste uma instância do Servidor seja criada, então caso alguma configuração de beans feita programaticamente ou através de properties esteja incorreta, você será capaz de perceber já que para o ApplicationContext seja iniciado, todas BeansFactorys devem ser criadas com sucesso, caso contrario o startup será abortado.

Em seguida habilitamos que as configurações referentes ao profile de test seja utilizada, e também habilitamos a capacidade do Test de Usar WireMock Servers através das respectivas anotações: @ActiveProfiles("test") e @AutoConfigureWireMock(port = 0). E para encerrar as configurações habilitamos a classe de teste a capacidade de utilizar containers docker através de TestContainers, com a anotação @TestContainers.

Após finalizar as configurações, iremos provisionar as dependências necessárias ao nosso teste, iniciaremos provisionando um container do PostgreSQL. Utilizamos a anotação @Container para habilitar que o TestContainers utilize seu orquestrador para instância o containers do PostgreSQL. Também adicionaremos a anotação @ServiceConnection para crie o bean de conexão com JDBC e integre o container ao contexto durante a execução do teste. E por fim, não menos importante, fornecemos instâncias do CalculaFreteService, ObjectMapper e o ProdutoRepository.

Ainda da escrita do teste, precisamos garantir que os testes rodem de maneira independente, isto significa, que o contexto de execução de um teste, nunca deverá interferir sobre a execução de outro método de teste, então isto torna necessário que antes que cada teste execute o estado do banco seja o mesmo, justificando a utilização do método deleteAll() do ProdutoRepository. E então estamos prontos para implementar os nossos testes.

O caso de teste implementado visa cobrir o caminho feliz ou caminho sem erros do código, então sua responsabilidade é garantir que uma simulação de frete seja calculada. Neste momento é onde nos conectamos com as dicas I e II. Iniciamos utilizando a etapa de cenário para fornecer as ambiente necessário para execução do teste, então adicionados ao banco de dados, o registro de um produto. Em seguida provisionados um MockServer com WireMock que irá atender o contrato de resposta da REST API de Frete da Transportadora. Na etapa de ação, iremos executar uma chamada ao método calcular do CalculaFreteService e armazenar a resposta, para o produto e código postal de destino informado. E para finalizar iremos validar, se o valor, cep de origem e destino são iguais ao esperado, e se existe uma estimativa de entrega. Você pode ter mais detalhes do código neste repositório.

Conclusão

Trabalhar em arquiteturas altamente distribuídas é um grande desafio por diferentes motivos, como garantir que a rede estará disponível, se existe banda, ou baixa latência, e também que os sistemas presentes na arquitetura se comuniquem de forma correta.

Dado a isso, a escrita de testes para estes serviços não pode ser baseadas apenas em requisitos funcionais do sistema, mas também devem garantir que os requisitos não funcionais, como operações em rede, operações em disco, serialização e etc, sejam, executados conforme esperado. E isto exige uma boa habilidade de escrita de testes. Visando isso aprendemos que escrever testes que se aproxime a execução do software em produção, proporciona a capacidade de executar validações que só seriam feitas no, startup da aplicação ou na execução do código em produção, antecipando o encontro de bugs e anomalias.

Na primeira e segunda dica aprendemos que conhecer as dependências do código que será testado, facilita o encontro de ferramentas que auxiliem a prover as dependências necessárias para execução do sistema, durante a execução do teste. Já na terceira dica aprendemos que dividir o teste em etapas pode, lhe ajudar a planejar melhor seu teste.

Quando combinamos as dicas, criamos uma estratégia poderosa e moderna de testes, proporcionando que o software seja mantido e evoluído com segurança e qualidade software.

3 Estratégias para sincronizar cache na camada de aplicação

Jordi Henrique Silva — Tue, 09 May 2023 02:26:07 +0000

No último artigo começamos a discutir sobre Cache, falamos sobre quais são os perigos e obstáculos de soluções de cache local em ambientes clusterizados. Também conversamos sobre o módulo Spring Cache, que oferecer abstrações para uso de caching na camada de aplicação em projetos Spring Boot.

Turbinando seus Microsserviços com Spring Cache e Redis

Jordi Henrique Silva ・ Feb 28 '23

#spring #cache #java #redis

Hoje iremos voltar a discutir sobre cache, porém, vamos nos concentrar em estratégias para manter o cache e a camada de dados sincronizadas.

Cache e sua importância

A verdade é que sistemas enterprise são automações que auxiliam no processo de escalada de um negócio. Isto significa que quanto mais o negócio crescer, quantos mais clientes o negócio atender, maior será o requisito de performance do sistema. O que quero dizer com isso é que otimizações precisaram ser feitas, e existem inúmeras técnicas que podem ser aplicadas, inclusive inserir uma camada de Caching.

A partir do momento que implementamos uma camada de cache, podemos usufruir de diversos benefícios, como diminuição do custo de consulta para O(1).E caso o banco de dados fique indisponível, o sistema continuará disponível para solicitações de leituras.

Uma camada de cache bem implementada deve se garantir que, leituras obsoletas não sejam permitidas. E que os dados estejam sincronizados com a fonte da verdade, no caso o banco de dados.

Os provedores de cache tem diversas formas para invalidação, entre elas as mais comuns são por tempo de duração em cache. E por limite de armazenamento, sendo possível definir uma capacidade máxima de objetos ou uma capacidade máxima em bytes.

Contudo, o que viemos discutir hoje são técnicas que você poderá aplicar para garantir que os dados presentes em cache não são obsoletos em relação à camada de dados.

Estratégias para sincronização de Cache

A primeira estratégia que vamos conhecer é conhecida como Cache a-side, nesta estratégia a camada de aplicação é responsável por gerenciar as camadas de dados e cache.

Cache a side

Nesta estratégia a camada de aplicação gerencia manualmente o cache e o banco de dados. Isto significa que quando um registro é buscado no banco, o mesmo é inserido no cache, o tornando disponível na próxima solicitação de leitura. O mesmo se aplica para quando um dado é atualizado.

Para entender melhor como, observe o diagrama abaixo, que demostra o comportamento da aplicação em uma consulta de dados.

O diagrama demostra que primeiro o dado é procurado em cache, como o mesmo obtêm na resposta que o dado não existe, é feito a consulta no banco de dados, em seguida o dado retornado do banco é inserido no cache.

Está é uma implementação simples, porém, misturar a lógica de negócio com lógica de acesso a cache, quebra o Princípio da Responsabilidade Única (SRP) do SOLID. Então a boa prática é que seja utilizado interceptors de programação orientada a aspectos AOP, para esconder a lógica de acesso à camada de cache, como, por exemplo, a API do Spring Cache.

Read Through

Nesta estratégia a camada de aplicação, irá se comunicar apenas com a API de Cache, e toda a lógica de gerenciamento de banco de dados será de total responsabilidade da camada de cache. As vantagens desta estratégia é que agora existe apenas um ponto de acesso a dados, então se torna mais simples a escrita e manutenção do código.

O diagrama apresentado acima, descreve o comportamento do caso de cache miss. Nesta situação o sistema, iniciará consultando se os dados existem em cache, caso não existam os dados são buscados no banco de dados, e inseridos em cache.

Write Behind

Esta estratégia é recomendada para situações onde NÃO é necessário ter uma forte consistência, pois as atualizações são feitas em lotes. Isto significa que as operações serão enfileiras, e executadas de uma só vez.

No diagrama a cima, é resumido o comportamento da estratégia de atualização de Caching para escrita. Nesta estratégia as operações de atualização são enfileiradas, até que o flush() for executado, liberando todas as operações ao fim da transação.

O contexto de persistência da JPA, utiliza write-behind para garantir que todas as transições de estado das entidades sejam liberadas no fim da Transação em execução, ou antes, de uma consulta.

Conclusão

Implementar uma camada de caching em um projeto permite o sistema ganhe desempenho e disponibilidade, já que o custo de processamentos complexos são reduzidos, proporcionando uma maior capacidade de atender solicitações simultâneas.

Porém, antes de gozar das vantagens é necessário entender quais são as melhores práticas para manter a camada da cache sincronizada com o banco de dados. Existem diversas estratégias que podem ser utilizadas, desde fazer com que a aplicação gerêncie o cache e o banco de dados como é o caso de cache a side. Caso trabalhar com duas fontes de dados seja trabalhoso, outra solução é definir uma API de Caching que gerencie a camada de dados, implementando Read-Through. E caso não seja necessária uma consistência forte, a camada de caching poderá enfileira as solicitações e dispará-las de uma única vez, como é Write-Behind.

Lembrando que decisões como essas são complexas, e devem ser tomadas de acordo com contexto do time, projeto e tecnologias utilizadas.

Turbinando seus Microsserviços com Spring Cache e Redis

Jordi Henrique Silva — Tue, 28 Feb 2023 12:11:14 +0000

No decorrer da última década vivenciamos a grande ascensão da arquitetura de microsserviços, antes os times de tecnologia optavam por desenvolver grandes sistemas responsáveis por todas as funcionalidades do negócio. E hoje a principal solução é dividir o domínio do negócio em vários escopos menores e criar pequenos sistemas independentes que os atendam. As vantagens da arquitetura de microsserviços variam desde proporcionar que diferentes times desenvolvam software em ritmos isolados, em até escalar o desempenho de determinadas funcionalidades.

Na busca pela melhora de desempenho uma das ferramentas utilizadas é o cache que permite aumentar a velocidade de consumo a dados frequentemente acessados. Uma das principais estratégias para o uso de cache é armazenar os dados na memória local do servidor a fim de evitar consultas regulares no banco de dados, APIs externas ou até mesmo processamento de cálculos custosos.

Ao tratar de microsserviços é comum que dado um requisito de disponibilidade ou desempenho seja necessário mais de uma instância dando vida a um cluster. Junto ao ambiente clusterizado vem problemas na implementação de cache local, já que cada uma das instâncias é um processo independente, e a memória não é compartilhada, ocasionando que o cache fique inconsistente entre uma instância e outra. Neste tipo de situação a estratégia de cache local não é suficiente, pois agora quando um dado é armazenado em cache por uma instância, a outra instância deverá ter acesso em sua próxima consulta. Então se faz necessário a utilização de um provedor de cache distribuído como Hazelcast e Redis.

Redis é um banco de dados não relacional de estrutura de chave (key) e valor (value). Sua principal característica é a alta velocidade de acesso devido a sua implementação em memória. E uma das suas principais utilizações é como cache distribuído, já que é possível ter diversas conexões paralelas. Ao optar por utilizar Redis como provedor de cache em uma aplicação é necessário que seja utilizada suas APIs na base de código, gerando uma grande dependência, já que se em algum momento se torne necessário a troca de provedor, haveria um alto custo em manutenção. Problemas como esse são resolvidos adotando abstrações, independente se são construídas por você ou não. Em uma aplicação Spring Boot é possível se apoiar no módulo do Spring Cache.

Spring Cache é um módulo de extensão do Spring Boot que abstrai a maneira como os dados são inseridos, atualizados e removidos do cache através da sua API no modelo de anotações. Spring Cache oferece suporte ao caching de objetos, então facilita que em diferentes pontos da aplicação compartilhem o mesmo caching.

Spring Cache com Redis

Para colher os benefícios do uso do Spring Cache com Redis é necessário que uma série de procedimentos de configuração da ferramenta, me refiro desde a inserção de dependências no pom.xml ou qualquer outro gerenciador de dependências que você utilize. Até a definição de beans e properties. Mas não se preocupe! O intuito deste artigo é demostrar como você pode configurar e utilizar o Redis como cache distribuído através das abstrações Spring Cache.

Inicialmente é necessário adicionar a Dependência de um módulo do Spring Data para o Redis, em seguida configuraremos a aplicação para trabalhar com cache e definiremos o Redis como provedor. Após as configurações de conexão e definição do Redis como provedor é necessário que definir as configurações responsáveis por limpar o cache, e qual serializer será utilizado durante a comunicação.

Configurando a Aplicação

Iniciaremos adicionando a dependência do Spring Data Redis no projeto, esta dependência ira abstrair o uso do Redis na aplicação, algumas vantagens são client e conector predefinido, serializers personalizados para o tráfego de dados na rede, etc. Abaixo tem um exemplo utilizando Maven.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

O próximo passo é definir as properties de conexão com Redis, e também definir o redis como provedor de cache no arquivo application.yaml.

spring:
    redis:
        host: ${HOST:localhost}
        port: ${PORT:6379}
        password: ${PASSWORD:password}
    cache:
        type: redis
        cache-names: user_payment_methods

Após a definição do Redis como provedor de cache é necessário que configuramos algumas propriedades como o tempo de vida de objetos no cache, e qual será a forma como os objetos serão serializadas. Por padrão no Spring Data Redis é utilizado o JdkSerializationRedisSerializer que utiliza a serialização nativa da JVM, e esta biblioteca nativa é conhecida por permitir a execução de código remoto, que injetam bytecode não verificado que pode causar a execução de código indesejado. Dado a isso, a recomendação é que outros serializers sejam utilizados, como, por exemplo, o serializer para Json da biblioteca Jackson.

@EnableCaching
@Configuration
public class RedisConfig {

    @Bean
    public RedisCacheConfiguration defaultCacheConfiguration() {
        return RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(120))// 2 horas
                .disableCachingNullValues()
                .serializeValuesWith(fromSerializer(new GenericJackson2JsonRedisSerializer()));
    }
}

Iniciamos o código acima, utilizando ao nível de classe a anotação @EnableCaching responsável por habilitar o uso do módulo de cache em aplicações Spring Boot. Em seguida é utilizado a anotação @Configuration para definir que a classe fornecerá bens para contexto do Spring. E o bean que ela fornecerá é o responsável por definir as configurações padrões de cache. Durante o método defaultCacheConfiguration() é definido que os objetos irão permanecer no cache em até 2 horas, e também é definido que valores nulos não serão cacheados, e por fim que os objetos sejam serializados em Json através do GenericJackson2JsonRedisSerializer.

Cacheando Resultados

Ao finalizar as configurações estamos prontos para provisionar o uso do cache na aplicação. Então para melhor entendimento, imagine um Market Place, onde um usuário pode ter diferentes formas de pagamento por estabelecimento. E o sistema deve oferecer uma forma de consultar quais são as formas de pagamento deste usuário. Então na primeira vez em que um usuário consultar as formas, o resultado deverá ser armazenado em cache para usos futuros. Veja um exemplo de implementação no código abaixo:

@Service
public class PaymentMethodsUserService {
    @Autowired
    private UserRepository userRepository;

    @Cacheable(value = "user_payment_methods", key = "#userId")
    public List<PaymentMethod> getPaymentMethodsToUserById(UUID userId) {
        User user = userRepository.findById(userId)
                .orElseThrow(() -> new IllegalArgumentException("User not exists"));

        if (user.getPaymentMethods().isEmpty()) {
            return defaultMethods();
        }

        return user.getPaymentMethods();
    }

    private List<PaymentMethod> defaultMethods() {
        return List.of(
                new PaymentMethod("Cash", "Money")
        );
    }
}

Para habilitar o cache no método getPaymentMethodsToUserById(UUID userId) é necessário que anotação @Cacheble seja utilizada ao nível de método e que os argumentos value e key sejam definidos. O argumento value é responsável por identificar qual cache sera consultado. Já o argumento key é responsável por definir como a chave do cache será criada. Por padrão o primeiro argumento é utilizado, porém, caso necessário é possível criar chaves mais elaboradas através de Spring Expression Language (SpEL). Para saber mais sobre como as keys são geradas consulte a documentação. Dado que um método é anotado com @Cacheable o seguinte comportamento é incorporado, primeiro é feito uma consulta se existe a chave no cache, o valor é retornado e o código do corpo do método não é executado. Caso contrario, o código do corpo do método é executado e seu resultado no fim é armazenado em cache para consultas futuras.

Invalidando o Cache

Nosso projeto já consegue armazenar novas informações no cache, e realizar consultas, porém, também precisamos identificar a situação onde o cache deve ser invalidado, para que as informações sejam atualizadas. Imagine agora que o sistema está evoluindo e começou a aceitar novas formas de pagamento, e agora o usuário poderá adicionar as mesmas em sua coleção. Então, sempre que o usuário adicionar uma nova forma de pagamento, o seu registro de formas no cache deverá ser apagado. Veja um exemplo de implementação no código abaixo.

@Service
public class PaymentMethodsUserService {
    @Autowired
    private UserRepository userRepository;

    @CacheEvict(value = "user_payment_methods", key = "#userId")
    public void addPaymentMethods(UUID userId, PaymentMethod paymentMethod) {
        User user = userRepository.findById(userId)
                .orElseThrow(() -> new IllegalArgumentException("User not exists"));

        user.add(paymentMethod);
        userRepository.save(user);
    }
}

Se observamos no método addPaymentMethods() foi utilizado a anotação @CacheEvict que possui os mesmo argumentos que a anotação @Cachable. Quando um método é anotado @CacheEvict o mesmo se torna um gatilho para invalidação do cache, e então caso sua execução seja realizada sem interrupção de alguma exceção o cache é sera invalidado. Caso contrario o cache não sofre alterações.

Então agora é possível utilizar este cache em diversos pontos do sistema, basta apenas que as anotações e o contrato dos métodos sejam equivalentes a estes. E a aplicação poderá rodar em diversas instâncias e compartilhar o mesmo cache, mantendo a consistência dos dados.

Conclusão

A utilização de cache permite que o aumento de desempenho em um sistema, já que dados que tem alta frequência de acesso podem ser recuperados mais rapidamente, já que não é necessário um processamento custoso, ou aguardar a finalização de operações de I/O. A utilização de cache em memória local é uma estratégia interessante quando apenas uma instância do serviço será executada, pois, a partir do momento em que o ambiente se torna clusterizado a memória de cache não é compartilhada deixando os dados inconsistentes. O que justifica a utilização de um provedor de cache distribuído. Redis é um provedor de cache distribuído que facilita o compartilhamento de dados na rede, e oferece suporte para uso em diferentes linguagens.

A utilização de cache em uma aplicação Spring Boot pode ser feita através da Spring Cache que permite que o uso de cache seja abstraído por anotações. Spring Cache oferece suporte ao Redis como provedor, e através de configurações é possível rapidamente utilizá-lo como cache distribuído. A anotação @Cacheable permite que um método faça a consulta por objetos no cache e @CacheEvict permite que invalidar o cache. Tão importante como inserir, remover e atualizar os dados no cache é definir o tempo de duração para não ser surpreendido com problemas indesejáveis.

Referências

Escrevendo Testes de Integração para Producers Kafka Com Spring Boot e EmbeddedBroker

Jordi Henrique Silva — Tue, 07 Feb 2023 18:29:03 +0000

Alguns meses atrás foi delegado a mim uma tarefa na qual eu não possuía muita experiencia e familiaridade com tema, se tratava da escrita de um produtor (Producer) do Apache Kafka em uma aplicação Java.

Minha primeira ideia foi utilizar as próprias bibliotecas do Kafka para implementar este Producer. Porém, após trocar algumas ideias com meus pares chegamos na conclusão que a melhor maneira era utilizar os frameworks do ecossistema Spring que visam facilitar a escrita de serviços de mensageria como o Spring For Apache Kafka

Ao utilizar o Spring for Apache Kafka ganhamos diversos benefícios como a configuração de beans através arquivo de configuração independente se é através de YAML ou Properties. E as abstrações que facilitam a inserção e o consumo de mensagens em tópicos.

Outra vantagem oferecida junto ao starter Spring For Kafka são as abstrações do Spring Kafka Test que permitem que instâncias do Zookeeper e Kafka Embedded sejam levantadas para que você teste de forma integrada seus produtores e consumidores.

Spring Kafka Test prove ferramentas que auxiliam a escrita de abstrações para facilitar como times escrevam testes integrados junto ao brooker embedded.

Para melhor entendimento de como escrever bons testes utilizando a ferramenta, imagine que em um ecomerce é necessário que os dados das vendas sejam integrados a outros sistemas através de um tópico utilizando Apache Kafka.

@Component
@Validated
public class VendaProducer {
    @Value("${spring.kafka.producer.topic}")
    private String topic;
    @Autowired
    private KafkaTemplate<String, Venda> templateMessage;

    public void produzir(@Valid Venda venda){
        templateMessage.send(topic, venda);
    }
}

Os demais detalhes do código acima estão disponíveis no seguinte repositório.

Acima está o código do Producer implementado, que tem a responsabilidade de receber os dados relativos da venda, aplicar validações, e caso nenhuma restrição seja violada a mensagem é inserida no tópico.

Agora nos concentraremos em configurar o ambiente de testes com Spring Kafka Test para utilizar KafkaEmbeddedBroker para escrita dos testes de integração.

Configurando o `KafkaEmbeddedBroker` para fazer Testes Integrados

Então inciaremos criando uma classe de teste para o VendaProducer, definiremos algumas propriedades para habilitar o uso do EmbeddedBroker. Inicialmente iremos definir:

Tópico que sera utilizado
Numero de partições
Endereço que o broker esta disponível.

As configurações acima devem ser feitas através da anotação @EmbeddedKafka ao nível de classe de teste. O tópico a ser utilizado pode ser informado via variável de ambiente com Spring Expresion Language (SpEL) , ou texto hardcoded. Como teremos um único broker levantado junto ao Context do Spring a sugestão é que possuam uma única partição. E quanto ao endereço o Spring Boot oferece uma propriedade que faz o bind do endereço de forma automática para você, basta definir como: spring.kafka.bootstrap-servers.

Veja o exemplo abaixo:

@SpringBootTest
@EmbeddedKafka(
        topics = "vendas",
        partitions = 1,
        bootstrapServersProperty = "spring.kafka.bootstrap-servers"
)
public class VendaProducerTest {}

Agora precisaremos de uma instância do broker para escrever um consumidor para o tópico que iremos publicar uma mensagem. Uma das formas de disponibilizar acesso à abstração do broker embedded é fazer uso da Injeção de Dependência.

@SpringBootTest
@EmbeddedKafka(
        topics = "vendas",
        partitions = 1,
        bootstrapServersProperty = "spring.kafka.bootstrap-servers"
)
public class VendaProducerTest {
    @Autowired
    private EmbeddedKafkaBroker broker;
}

O próximo passo é construir junto a abstração KafkaTestUtils um Consumidor para o tópico que publicaremos as mensagens. Vamos dividir esta etapa nas seguintes fases:

Definição das propriedades do Consumer
Criação da DefaultConsumerFactory
Criação do Consumer

Definição das propriedades do Consumer

Nesta etapa iremos definir configurações básicas do consumidor, como se trabalhará em modo auto_comit, quais são os Deserializer para chave (key) e value (valor) das nossas mensagens, e também quais os pacotes onde o Deserializer escolhido ira se basear para encontrar as classes que representam mensagens no projeto.

Outra configuração que deve ser feita, é definir a política de leitura de offset, como queremos que todas as mensagens enviadas em um casos de teste sejam consumidas, o ideal é que a propriedade ConsumerConfig.AUTO_OFFSET_RESET_CONFIG seja definida como earliest conforme sugerido pela própria documentação da Spring Kafka Test.

Após definir as propriedades, iremos utilizar a abstração DefaultKafkaConsumerFactory, para obter a instância do consumidor que será utilizado nos testes.

Veja o código correspondendo na classe VendaProducerTest demostrada abaixo:

@SpringBootTest
@EmbeddedKafka(
        topics = "vendas",
        partitions = 1,
        bootstrapServersProperty = "spring.kafka.bootstrap-servers"
)
public class VendaProducerTest {
    @Autowired
    private EmbeddedKafkaBroker broker;

    private <V> Consumer<String, V> createConsumer(Class<V> classType) {

        Map<String, Object> consumerProps = KafkaTestUtils.consumerProps(TOPIC, "true", this.broker);
        consumerProps.put(JsonDeserializer.TRUSTED_PACKAGES, "*");
        consumerProps.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");

        DefaultKafkaConsumerFactory<String, V> consumerFactory = new DefaultKafkaConsumerFactory(
                consumerProps, new StringDeserializer(), new JsonDeserializer<>()
        );

        return consumerFactory.createConsumer();
    }
}

Agora estamos prontos para escrever testes integrados para Producers Kafka.

Então, voltamos a classe VendaProducerTest, e criaremos o nosso teste, que cuidará de publicar uma mensagem no tópico de vendas, e em seguida utilizaremos o KafkaEmbeddedBroker e nosso método createConsumer() para validar se a mensagem foi inserida como deveria.

Na construção do teste, iremos dividir em 3 etapas: cenário, ação e validação. No cenário, cuidaremos de disponibilizar o ambiente necessário para o caso de teste executar, nesta etapa, instanciaremos um objeto que represente a mensagem de venda, e habilitaremos para que um Consumer criado atenda as mensagens do tópico especificado. No bloco de ação, iremos disparar o método produz do VendaProducer. E por fim, utilizaremos nosso Consumer para verificar se a mensagem foi inserida e se corresponde a mensagem esperada.

É importante ressaltar que hoje o EmbeddedKafkaBroker não possui ferramentas para limpeza do topico, então é necessário que o TestContext seja reconstruído após cada método, a fim de garantir que os testes sejam independentes um aos outros em sua execução. Então adicionaremos ao nível de classe de teste a anotação @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD).

@SpringBootTest
@EmbeddedKafka(
        topics = "venda",
        partitions = 1,
        bootstrapServersProperty = "spring.kafka.bootstrap-servers"
)
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
public class VendaProducerTest {
    @Autowired
    private EmbeddedKafkaBroker broker;
    @Autowired
    private VendaProducer producer;

    @Test
    @DisplayName("deve consumir uma mensagem na fila")
    void t1() {
        //cenario
        Consumer<String, Venda> consumer = createConsumer(Venda.class);
        this.broker.consumeFromEmbeddedTopics(consumer, "venda");
        Venda venda = new Venda("PlayStation 5", BigDecimal.valueOf(5000), LocalDate.now());

        //acao
        producer.produzir(venda);

        //validacao
        ConsumerRecords<String, Venda> records = KafkaTestUtils.getRecords(consumer, Duration.ofSeconds(5));
        assertThat(records)
                .hasSize(1)
                .allMatch(msg -> msg.value().equals(venda));

    }

    private <V> Consumer<String, V> createConsumer(Class<V> classType) {

        Map<String, Object> consumerProps = KafkaTestUtils.consumerProps(TOPIC, "true", this.broker);
        consumerProps.put(JsonDeserializer.TRUSTED_PACKAGES, "*");
        consumerProps.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");

        DefaultKafkaConsumerFactory<String, V> consumerFactory = new DefaultKafkaConsumerFactory(
                consumerProps, new StringDeserializer(), new JsonDeserializer<>()
        );

        return consumerFactory.createConsumer();
    }
}

Testes de integração possibilitam que características relacionadas a integração do código criado com o Spring Context sejam validadas. Caso existam bugs e anomalias devido à má configuração e definição de beans através das properties ou de forma programática, os mesmos terão sua identificação antecipada na etapa de testes.

Ao testar de forma integrada os Producers estamos favorecendo que a aplicação se comporte o mais próximo possível do contexto de execução real, possibilitando que mais características referentes a integração da lógica e Apache Kafka sejam validadas, antecipando a identificação de bugs.

E por fim, não menos importante, os testes integrados permitem a validação dos efeitos colaterais do servidor, oferecendo garantia que a mensagem foi inserida no tópico como deveria, ao contrário de Mocks, onde fazemos todas as validações em memória.

Conclusão

Durante este artigo exploramos diversos benefícios das APIs do Spring Kafka Test. Estas APIs nos possibilitam com mínimo de configuração expor uma instância do ZookeeperEmbedded e KafkaEmbeddedBroker.

O KafkaEmbeddedBroker permite que os testes sejam executados mais próximos do cenário de uso real da aplicação. Desta forma, podemos validar características e configurações a fim de antecipar o encontro de bugs e anomalias.

3 motivos do porquê testes unitários não são suficientes para Microservices com Spring Boot

Jordi Henrique Silva — Wed, 14 Dec 2022 13:17:58 +0000

Escrever testes automatizados já é rotina para maioria dos times de tecnologia, porém, o que não te contaram é que testar microsserviços Spring Boot confiando em apenas de testes de unidade pode diminuir a qualidade do seu sistema. E hoje vou mostrar para você 3 motivos que demostram que apenas testes unitários não são suficientes para microsserviços com Spring Boot.

O primeiro motivo é que testes de unidade costumam ser escritos utilizando Mocks, e se você esta instanciando seus Beans manualmente esta deixando de validar uma série de comportamentos e configurações relacionados ao contexto do Spring.

O segundo motivo é que ao mockar as dependências dos seus Beans, você esta renunciando a validar o comportamento entre a integração de um componente e outro. E isto pode fazer com que, falhas de conexão entre seu banco de dados relacional, mapeamentos de entidade da JPA/Hibernate e controle transacional nunca sejam executados. O impacto disto é que se houver algum erro em alguma destas tarefas o seu cliente/usuario é quem vai encontrar o bug em produção.

O terceiro motivo é que você esta deixando de validar os efeitos colaterais do seu componente de código, isto significa, que você não tem nenhuma garantia que inseriu um registro no banco, uma mensagem na fila, ou um arquivo no storage.

Para entender melhor, observe o código abaixo, neste temos uma API REST que recebe informações necessárias para o cadastro de um produto na base de dados.

@RestController
public class CadastraProdutoController {
    private final ProdutoRepository repository;
    private final Logger LOGGER = LoggerFactory.getLogger(CadastraProdutoController.class);

    public CadastraProdutoController(ProdutoRepository repository) {
        this.repository = repository;
    }

    @PostMapping("/produtos")
    @Transactional
    public ResponseEntity<?> cadastrar(@RequestBody @Valid ProdutoRequest request) {

        if (repository.existsBySku(request.getSku())) {
            LOGGER.error("Já existe um produto cadastrado para este sku {}", request);
            throw new ResponseStatusException(HttpStatus.UNPROCESSABLE_ENTITY, "Produto ja cadastrado");
        }

        Produto novoProduto = request.toModel();
        repository.save(novoProduto);
        LOGGER.info("Produto Cadastrado {}", novoProduto);

        return ResponseEntity.status(CREATED).build();
    }
}

Um caso de teste de unidade para este Controller, focaria em validar se o contrato esta sendo respeitado, o que significa que instanciaríamos um objeto do tipo ProdutoRequest, e executaríamos a função cadastrar, e por fim iremos validar se a resposta HTTP contém um Status 201 CREATED. Para realizar este teste é necessário que utilizaremos o Mockito para criar um duble do ProdutoRepository, dando comportamento para os métodos: existsBySku e save. Abaixo tem o código correspondente a este caso de teste.

@ExtendWith(value = MockitoExtension.class)
class CadastraProdutoControllerUnitTest {
    @Mock
    private ProdutoRepository repository;
    private CadastraProdutoController produtoController;

    @BeforeEach
    void setUp() {
        this.produtoController = new CadastraProdutoController(repository);
    }

    @Test
    @DisplayName("deve cadastrar um Produto")
    void t1() {
        //Cenario
        ProdutoRequest produtoRequest = new ProdutoRequest(
                "PlayStation 5",
                "Console e 2 controles",
                BigDecimal.TEN,
                "123567"
        );

        when(repository.existsBySku(produtoRequest.getSku())).thenReturn(false);
        when(repository.save(any(Produto.class))).thenReturn(produtoRequest.toModel());

        //acao
        ResponseEntity<?> response = produtoController.cadastrar(produtoRequest);

        // validacao
        assertEquals(HttpStatus.CREATED, response.getStatusCode());

    }

}

Por mais que pareça que o caso de teste é completo, ele não valida características essências da nossa API. Como se ela atende, ao verbo POST, e a URI de "/produtos". Não valida se as informações recebidas no body da requisição HTTP são desserializadas em um objeto Java. Também não é validado se as informações referentes ao produto são registradas no Banco de Dados.

A verdade é que diversos comportamentos indispensáveis para o funcionamento do software são ignorados no caso de teste. E caso não funcionem como esperado, não serão detectados durante a execução.

Um teste bem escrito para este Controller consideraria a integração com Application Context do Spring Boot, o que garantiria que Beans de todas as camadas seriam instanciados, e se houver erros de configuração e mapeamento o teste já falharia imediatamente. Outra característica essencial é que a lógica de negócio execute de maneira similar a execução do servidor, isto significa que a API deve ser exposta na Web, e que durante o teste uma requisição HTTP deve ser feita, o que garantiria que um banco de dados seria utilizado na execução, ou seja, como efeito colateral da requisição, um registro deve ser criado na base de dados. Abaixo tem o código correspondente a este caso de teste.

@SpringBootTest
@ActiveProfiles("test")
@AutoConfigureMockMvc(printOnlyOnFailure = false)
class CadastraProdutoControllerIntegrationTest {
    @Autowired
    private ObjectMapper mapper;
    @Autowired
    private ProdutoRepository repository;
    @Autowired
    private MockMvc mockMvc;

    @BeforeEach
    void setUp() {
        repository.deleteAll();
    }

    @Test
    @DisplayName("deve cadastrar um Produto")
    void t1() throws Exception {
        //Cenario
        ProdutoRequest produtoRequest = new ProdutoRequest(
                "PlayStation 5",
                "Console e 2 controles",
                BigDecimal.TEN,
                "123456"
        );

        String payload = toJson(produtoRequest);

        MockHttpServletRequestBuilder request = post("/produtos")
                .header(HttpHeaders.ACCEPT_LANGUAGE, "en")
                .contentType(APPLICATION_JSON)
                .content(payload);

        //Acao
        ResultActions response = mockMvc.perform(request);
        //Validacao
        response.andExpectAll(
                status().isCreated()
        );

        assertEquals(1, repository.findAll().size(),
                "deveria conter apenas um registro de produto"
        );
    }
}

Conclusão

Como visto anteriormente testes de integração são mais assertivos que testes unitários, pois, testes integrados favorecem que os diversos pontos de integração sejam exercitados. Exercitar a integração com contexto do Spring, favorece que validamos configuração das propriedades e Beans. Também favorece a validação do comportamento de integração as camadas referente a Rede e Banco de Dados.

No contexto de sistemas distribuídos e microsserviços onde temos pequenas bases de código e a maioria das operações são referentes a entrada e saída (I/O) favorecer testes de unidades não será suficientes para garantir o comportamento do seu software.

E se você ainda tem dúvida do que leu até aqui, remova todas as anotações de um Controller e rode seus testes de unidade, e se nenhum teste quebrar me conta aqui nos comentários.

Criando Sistemas de Reservas Com Versionless Optimistic Locking, Spring Boot e JPA/Hibernate

Jordi Henrique Silva — Wed, 17 Aug 2022 22:00:00 +0000

Como visto no artigo anterior o Optmistic Locking é uma opção para lidar com Race Conditions para cenários com baixo e/ou moderado índice de conflitos. O principal motivo para o uso de bloqueio otimista nestes cenários é porque não haverá um número exagerado de transações conflitantes e o seu banco de dados (BD) não será sobrecarregado com uma alta quantidade de rollbacks.

Caso seu sistema necessite atualizar atributos distintos de uma entidade simultaneamente o Optmistic Locking poderá se tornar um empecilho dado que o mecanismo de bloqueio otimista encara as atualizações como tudo ou nada, ou seja, caso a versão da entidade em memória não corresponda a presente ao BD a transação será abortada independente se os campos atualizados não sejam sobrepostos.

Para entender melhor, dado a entidade Mesa descrita no código abaixo.

@Entity
public class Mesa {
    @Id
    @GeneratedValue
    private Long id;
    @Column(nullable = false)
    private Integer quantidadeDeLugares;
    @Column(nullable = false)
    private boolean disponivelParaReserva;
    @Version
    private Long version;
    //construtores e metodos omitidos
}

Imagine que duas transações simultâneas desejem atualizar os atributos quantidadeDeLugares e disponivelParaReserva. Ambas consultem o registro e recebam a mesma versão da entidade Mesa. A primeira transação (Tx1) atualiza a quantidade de lugares, fazendo com que a versão da mesa seja incrementada. Enquanto a segunda transação (Tx2) tenta atualizar o status da mesa para indisponível para reserva, porém, dado que Tx1 incrementou a versão da entidade, agora a versão está obsoleta, portanto, Tx2 sera abortada.

Em casos de uso onde é necessário que atualizações com atributos não sobrepostos não conflitem, ou quando alterar o schema de dados para inserir um atributo de versão seja caro independente do motivo o Hibernate oferece suporte ao controle de concorrência com mecanismo de Versionless Optmistic Locking ou bloqueio otimista sem versão em português.

Version-less optimistic locking

Os bloqueios otimistas estão relacionados a um atributo incremental para controle de versão da entidade, e é através deste que a integridade e consistência são mantidas em atualizações concorrentes.

Existem sistemas onde o custo de utilizar uma estratégia de Optimistic Locking é alto, pois não é simples inserir uma nova coluna na tabela dado que o impacto desta mudança poderá causar anomalias em outras funcionalidades do sistema, ou para realizar mudanças no schema exija aprovações em um sistema altamente burocrático, ou você trabalha em um sistema legado onde alterar o schema não é uma opção.

Para estes casos é possível criar um versionamento da entidade a partir do próprio estado do recurso, seja através de uma coluna atualizada ou da junção de todas colunas.

Versionless Optmistic Locking com Hibernate

Hibernate oferece suporte ao controle de concorrência com bloqueio otimista sem versão, para habilitar o mesmo devemos utilizar anotação @OptimisticLocking ao nível de entidade, esta anotação recebe como argumento a estratégia de bloqueio otimista descrita por um OptimisticLockType.

O Hibernate oferece suporte as seguintes estratégias de bloqueio otimista.

OptimisticLockType.NONE: indica que o mecanismo de bloqueio otimista está desabilitado;
OptimisticLockType.VERSION: indica que o mecanismo de bloqueio otimista utilizará o atributo anotado com @Version como versão da entidade;
OptimisticLockType.DIRTY: indica que o mecanismo de bloqueio otimista utilizará apenas os atributos atualizados pela transação como versão da entidade;
OptimisticLockType.ALL: indica que o mecanismo de bloqueio otimista utilizar todos os atributos da entidade como versão;

Como o mecanismo de controle de concorrência precisa inserir condições adicionais em sua Query de atualização, é necessário que a entidade seja anotado com @DynamicUpdate ao nível de entidade.

@Entity
@OptimisticLocking(type = OptimisticLockType.ALL)
@DynamicUpdate
public class Mesa {
    @Id
    @GeneratedValue
    private Long id;
    //Demais campos, construtores e metodos omitidos  
}

Controle de Concorrência com `OptimisticLockType.ALL`

Dado que a estratégia de bloqueio otimista OptimisticLockType.ALL esteja habilitada no momento de uma atualização o Hibernate irá verificar se o estado de cada atributo da entidade corresponde em memória ao estado presente no BD.

Para melhor entendimento observe o código abaixo.

@Transactional
public void atualizarQuantidadeDeLugares(Long mesaId, int qtdLugares){
   Mesa mesa = entityManager.find(Mesa.class, mesaId);
   mesa.setQuatidadeDeLugares(qtdLugares);
}

Hibernate gera o seguinte SQL:

   SELECT *
     FROM mesa m
    WHERE m.id = :mesaId

   UPDATE mesa
      SET quantidadeLugares = :qtdLugares
    WHERE id = :medaId 
      AND quantidadeLugares = 2
      AND disponivelParaReserva = true

No SQL acima é possível visualizar que todos os campos se uniram e convergiram em um único atributo de versão global. Esta estratégia é utilizada quando é impossível inserir um atributo para versionamento da entidade. Em contrapartida, as atualizações com atributos não sobrepostos conflitam.

Controle de Concorrência com `OptimisticLockType.DIRTY`

A estratégia de bloqueio otimista OptimisticLockType.DIRTY favorece que apenas os campos "sujos" na atualização sejam utilizados como versão da entidade, ou seja, agora atualizações com atributos não sobrepostos não conflitam mais.

Observe o comportamento do seguinte método de atualização.

@Transactional
public void atualizarQuantidadeDeLugares(Long mesaId, int qtdLugares){
   Mesa mesa = entityManager.find(Mesa.class, mesaId);
   mesa.setQuatidadeDeLugares(qtdLugares);
}

Hibernate gera o seguinte SQL:

   SELECT *
     FROM mesa m
    WHERE m.id = :mesaId

   UPDATE mesa
      SET quantidadeLugares = :qtdLugares
    WHERE id = :medaId 
      AND quantidadeLugares = 2

O SQL apresentado acima demostra que apenas o atributo quantidadeLugares foi utilizado na condição do WHERE, ou seja, quando a estratégia de bloqueio otimista DIRTY é utilizada apenas os campos atualizados são utilizados como versão. O sistema permite que atualizações a atributos distintos não conflitem evitando OptimisticLockException.

O diagrama acima pode ser resumido em:

A primeira transação (Tx1) realiza a consulta de leitura da entidade Mesa com id igual a 1.
A segunda transação (Tx2) simultaneamente também realiza a consulta de leitura da entidade Mesa com id igual a 1
Tx1 altera a quantidade de lugares na mesa.
Tx2 altera o status de disponibilidade da mesa

Construindo uma API REST para reserva de mesas com Versionless Optimistic Locking

Ao nível de controller não existem mudanças a implementação do artigo anterior dado que nossas mudanças afetam apenas as entidades.

@PostMapping("/mesas/{id}/reservas")
@Transactional
public ResponseEntity<?> reservar(
        @PathVariable(value = "id") Long mesaId,
        @RequestBody ReservaMesaRequest request,
        UriComponentsBuilder uriBuilder
) {
    Mesa mesa = mesaRepository.findById(mesaId)
            .orElseThrow(() -> new ResponseStatusException(NOT_FOUND, "Mesa não cadastrada"));

    Usuario usuario = usuarioRepository.findById(request.getUsuarioId())
            .orElseThrow(() -> new ResponseStatusException(UNPROCESSABLE_ENTITY, "Usuario não cadastrado"));

    LocalDateTime dataDaReserva = request.getDataReserva();

    if (reservaRepository.existsMesaByIdAndReservadoParaIs(mesaId, dataDaReserva)) {
        throw new ResponseStatusException(UNPROCESSABLE_ENTITY, "Horario indisponivel para reserva");
    }

    Reserva reserva = mesa.reservar(usuario, dataDaReserva);
    reservaRepository.save(reserva);


    URI location = uriBuilder.path("/mesas/{id}/reservas/{reservaId}")
            .buildAndExpand(mesa.getId(), reserva.getId())
            .toUri();

    return ResponseEntity.created(location).build();
}

Independente da abordagem de bloqueio otimista sem versão é indispensável a construção de um Exception Handler para ObjectOptimisticLockingFailureException, quando atualizações conflitarem é essencial que a resposta contenham um Http Status Conflict.

@RestControllerAdvice
public class DeafultExceptionHandler {    
 @ExceptionHandler(ObjectOptimisticLockingFailureException.class)
    public ResponseEntity<?> optmisticLock(ObjectOptimisticLockingFailureException ex) {

        String msg = "Aconteceu um conflito em sua atualização, tente novamente.";

        return status(409)
                .body(
                        Map.of("mensagem",msg)
                );
    }
}

Conclusão

Construir mecanismo para controle de concorrência é uma tarefa complexa dado que cada sistema possui suas restrições. O mecanismo de Versionless Optimistic Locking do Hibernate oferece flexibilidade para implementação da estratégia de detecção de conflitos para diversos casos de uso.

Caso o conflito de atualizações estejam causando integridade aos dados em um sistema legado ou quando alterar o schema seja custoso o OptimisticLockType.ALL se torna uma ótima solução dado que seu comportamento é semelhante ao Optimistic Locking tradicional.

Porém, se existe a necessidade de que atualizações a atributos não sobrepostos não conflitem a estratégia de OptimisticLockType.DIRTY se torna uma solução já que apenas os atributos "sujos" são utilizados como versão da entidade.

Referências

Criando Sistemas de Reservas consistentes com Optimistic Locking, Spring Boot e JPA/Hibernate

Jordi Henrique Silva — Thu, 11 Aug 2022 17:42:00 +0000

No artigo anterior foi utilizado a estratégia de Pessimistic Locking para construção de uma API REST para reserva de mesas de bar. Como visto no artigo existem situações onde empregar bloqueios físicos pode ser custoso visando que se diversas linhas estejam bloqueadas haverá uma diminuição de produtividade nas transações de banco de dados.

Caso você se encontre em uma destas situações, existem outras estratégias para lidar com Race Conditions, como é o caso do Optimistic Locking ou Bloqueio Otimista em português.

Optimistic Locking é uma estratégia de detecção de conflitos, ao contrário do Pessimistic Locking que seu foco é evitar conflitos, o bloqueio otimista deixa os conflitos acontecerem e ao identificá-los reverte as transações detentoras dos mesmos.

Conhecendo o Optimistic Locking

A ideia principal do bloqueio otimista é reduzir o período de tempo em que as transações detêm bloqueios físicos afim prover melhorias no desempenho da aplicação. Antes ao utilizar o bloqueio pessimista uma transação obtia um bloqueio garantindo exclusividade para alterar o recurso. Já no bloqueio otimista diversas transações podem tentar alterar, porém, somente uma ira conseguir e as demais serão abortadas.

Para identificar os conflitos a estrategia utiliza o estado do recurso como um critério de versionamento, permitindo que apenas as transações que contenham o recurso com versão equivalente a presente no banco de dados sejam confirmadas (COMMIT).

Optimistic Locking com JPA/Hibernate

JPA/Hibernate oferece suporte para estratégia de Optimistic Locking, para habilita-lo devemos inserir um campo na entidade para representar a versão. Este campo deverá ser anotado com @Version para ser gerenciado pela JPA/Hibernate. O atributo de versão deve ser mapeado para java.sql.Timestamp ou qualquer tipo que represente números inteiros, por exemplo, Long, long, int, Integer, short e Short.

@Entity
public class Mesa {
    @Id
    @GeneratedValue
    private Long id;
    @Version
    private Long version;
    //Demais campos, construtores e metodos omitidos  
}

OBS: É recomendado que o versionamento de entidades seja através de atributos inteiros dado que a versão devera sempre crescer monotonicamente. O perigo de utilizar um atributos de data e hora é que por causa de uma sincronização do Network Time Protocol as datas podem retroceder.

Observe o comportamento ao persistir uma entidade.

@Transactional 
public void cadastrar(){
     Mesa mesa = new Mesa(4);
     entityManager.persist(mesa);
}

O SQL gerado pela JPA/Hibernate.

INSERT INTO mesa
 (id, quantidadeDeLugares, disponivelParaReserva, version)
VALUES (1, 4, 1, 0);

Dado que o mecanismo de bloqueio otimista está habilitado para uma entidade para cada operação de atualização é disparado uma checagem para verificar se a versão da entidade em memória corresponde a versão da entidade no banco de dados, caso corresponda atualização é confirmada e a versão da entidade é incrementada. Caso contrario a transação sera revertida.

Observe abaixo um exemplo de atualização bem sucedida.

@Transactional 
public void atualizarQuantidadeLugares(Long mesaId, int novaQuantidadeLugares){
     Mesa mesa = entityManager.find(Mesa.class, mesaId);
     mesa.atualizarQuantidadeDeLugares(novaQuantidadeLugares);
}

O Hibernate gera a seguinte saída:

SELECT * 
  FROM mesa m
 WHERE m.id = :id

UPDATE mesa
   SET quantidadeDeLugares=:qtdLugeres, version = 1
 WHERE id=:id AND version = 0;

Caso o retorno da operação UPDATE seja a contagem de 1 linha atualizada a operação SQL UPDATE sera commitada. Caso seja 0 sera lançada uma Exceção do tipo OptimisticLockException e automaticamente a transação sera revertida.

Para entender melhor, imagine que duas transações desejem atualizar informações da mesma entidade de maneira simultânea, ambas as transações iram obter a mesma versão de entidade. A primeira transação (Tx1) a terminar, irá persistir suas alterações, e incrementar a versão da entidade. A segunda transação (Tx2) não tem ciência que a versão da entidade foi incrementada, e dispara sua atualização, porém, a versão de presente em memória precede a versão presente no banco, portanto a segunda transação é abortada.

Construindo uma API REST para reserva de mesas com Optimistic Locking

Para se beneficiar do mecanismo de Optimistic Locking em nossa API de reserva, devemos implementar algumas mudanças em comparação a implementação anterior. Antes onde era adquirido um bloqueio pessimista através da consulta findByIdWithPessimisticLock( ) agora não é mais necessário dado que uma checagem de versão sera realizada pela JPA/Hibernate. Então podemos substituir a consulta pelo método default findById( ).

Um possível implementação para lógica descrita acima é:

@PostMapping("/mesas/{id}/reservas")
@Transactional
public ResponseEntity<?> reservar(
        @PathVariable(value = "id") Long mesaId,
        @RequestBody ReservaMesaRequest request,
        UriComponentsBuilder uriBuilder
) {
    Mesa mesa = mesaRepository.findById(mesaId)
            .orElseThrow(() -> new ResponseStatusException(NOT_FOUND, "Mesa não cadastrada"));

    Usuario usuario = usuarioRepository.findById(request.getUsuarioId())
            .orElseThrow(() -> new ResponseStatusException(UNPROCESSABLE_ENTITY, "Usuario não cadastrado"));

    LocalDateTime dataDaReserva = request.getDataReserva();

    if (reservaRepository.existsMesaByIdAndReservadoParaIs(mesaId, dataDaReserva)) {
        throw new ResponseStatusException(UNPROCESSABLE_ENTITY, "Horario indisponivel para reserva");
    }

    Reserva reserva = mesa.reservar(usuario, dataDaReserva);
    reservaRepository.save(reserva);


    URI location = uriBuilder.path("/mesas/{id}/reservas/{reservaId}")
            .buildAndExpand(mesa.getId(), reserva.getId())
            .toUri();

    return ResponseEntity.created(location).build();
}

Sabemos que se uma operação de atualização UPDATE falhar no mecanismo de checagem de versão uma ObjectOptimisticLockingFailureExceptionserá lançada, e se o sistema não estive preparado um erro inesperado sera retornado ao cliente, então é importante que a exceção seja tratada e uma mensagem amigável e coerente ao caso seja dada ao cliente.

Segundo a RFC 7231 quando uma solicitação resulta em erro dado ao estado atual do recurso no servidor de destino é o indicado que a resposta a solicitação contenha o HTTP Status 409 Conflict.

Exemplo de Exception Handler com Spring:

@RestControllerAdvice
public class DeafultExceptionHandler {    

    @ExceptionHandler(ObjectOptimisticLockingFailureException.class)
    public ResponseEntity<?> optmisticLock(ObjectOptimisticLockingFailureException ex) {

        String msg = "Aconteceu um conflito em sua atualização, tente novamente.";

        return status(409)
                .body(
                        Map.of("mensagem",msg)
                );
    }
}

Conclusão

O mecanismo de bloqueio otimista da JPA/Hibernate trabalha com a estratégia de detecção de conflitos. Isto que significa que o tempo em que o registro fica bloqueado é reduzido. Antes um bloqueio era adquirido no momento da leitura e era liberado ao fim da transação. Agora diversas transações simultâneas podem tentar atualizar o registro, mas apenas uma conseguirá.

Estrategia de bloqueio otimista pode trazer uma melhoria em performance para seu sistema como um todo na maioria dos casos, porém, não se engane, caso o índice de conflitos seja alto o Optimistic Locking pode ser mais custoso que um bloqueio pessimista, dado que será necessário um alto esforço do banco de dados para reverter transações. Outro fator que corrobora uma possível perda de performance é que bloqueios otimistas bem implementados requerem retries o que pode aumentar o tempo de resposta da sua aplicação.

Enfim, se seu sistema possui um índice de concorrência baixo ou moderado o uso de Optimistic Locking é uma ótima opção, pois oferece ganhos de consistência sem sacrificar a performance.

Referências

Criando Sistemas de Reservas consistentes com Pessimistic Locking, Spring Boot e JPA/Hibernate

Jordi Henrique Silva — Mon, 01 Aug 2022 15:31:00 +0000

OBS: Objetivo deste artigo não é ensinar a construir um sistema de reservas para produção, mas sim introduzir conceitos de controle de concorrência.

Uma cultura bastante popular em diversas cidades no mundo é se encontrar para bater papo e tomar alguns drinks em uma mesa de bar. Em alguns Bares a procura por mesas é tão grande que as pessoas precisam se adiantar para não ficar de fora e isto causa descontentamento aos clientes.

Uma possível solução para os donos de bares é prover um mecanismo para que todos os clientes possam reservar suas mesas antecipadamente, porém, dado a alta concorrência pelas mesas, já se pode deduzir que construir um sistema de reserva não é uma tarefa trivial, pois caso o desenvolvedor não se atente aos requisitos não funcionais, mais de um cliente poderá reservar a mesma mesa, ocasionado o que conhecemos como Anomalia da Atualização Perdida (Lost Update Anomaly).

Anomalia de Atualização Perdida é causada por Race Conditions ou Condições de Corrida em português. Race Conditions é um problema classico da Ciência da Computação que indica que se dois ou mais processos, tentam acessar um recurso simultaneamente, após varios acessos não podemos definir o estado do recurso, o que causa um problema de inconsistência.

Para identificar Race Conditions devemos nos atentar se o algoritmo da sua solução segue o seguinte padrão: ler - processar- escrever. Isto porque durante a janela de tempo entre ler e escrever, outro processo pode atualizar o estado do recurso, causando inconsistência.

Para entender melhor vamos realizar o seguinte exercício de imaginação. Imagine que dado o modelo de domínio abaixo, dois usuários tentem reservar a mesma mesa paralelamente.

Usuario 1 realiza a leitura do registro de uma mesa, e realizaria o processamento da lógica de reserva. Usuario 2 também executa a leitura para o mesmo registro de mesa, e obtêm que a mesa ainda está disponível para reserva. Usuario 1 conclui a lógica de reserva, e o Usuario 2 não é notificado que o status de disponibilidade da mesa mudou, portanto, a instância em memória da mesa que o Usuario 2 possui ainda indica que a mesa está disponível para reserva e dado a isso ele também consegue reservar a mesa.

O diagrama acima pode ser resumido da seguinte forma:

Usuario 1 faz a consulta pela mesa 1, e recebe como resposta que a mesa esta disponivel.
Usuario 2 também consulta a mesa 1, e recebe que a mesa esta disponivel.
Usuario 1 procede com fluxo de reserva, e consegue reservar a mesa.
Usuario 2 contém uma versão em memória que indica que a mesa está disponível, por tanto consegue progredir na reserva, agora tanto Usuario 1 quanto Usuario 2 tem uma reserva para mesa 1.

Existem diversas soluções para o problema de Race Conditions, uma delas é a aplicação do algoritmo de sessão critica, que pode ser resumido em, um processo obtem um bloqueio (lock) modifica o recurso, e libera o bloqueio para que outro processo consiga executar suas alterações.

No mundo Java uma solução popular para Race Conditions é a fazer com que a lógica de reserva fique encapsulada em um método com a palavra-chave synchronized. O que proveria a sincronização de acesso ao recurso ao nível de Thread da JVM. O problema desta abordagem é que por requisitos de escalabilidade ou disponibilidade podem existir mais de uma instância da aplicação, indicando a necessidade de um mecanismo de lock distribuído.

Ferramentas como Zookeeper, MongoDb e Redis provem mecanismos para obter bloqueios distribuídos, porém, se em sua infraestrutura já exista um banco de dados relacional, e caso todas as instâncias da sua aplicação acessem este banco é possível se favorecer dos mecanismos de controle de concorrência do banco.

Os Bancos de dados relacionais oferecem suporte a bloqueios exclusivos, adquiridos para evitar conflitos entre operações de escrita. Dado que um bloqueio é adquirido por uma transação, as demais transações que tentem acessar o mesmo recurso serão obrigadas a aguardar que a transação detentora do bloqueio seja confirmada (COMMIT) ou revertida (ROLLBACK).

Ao inserir um bloqueio exclusivo em uma consulta é utilizado a estratégia de Pessimistic Locking ou Bloqueio Pessimista em português.

Obtendo `Pessimistic Locking` em seu banco de dados relacional

Os bloqueios pessimistas podem ser adquiridos de maneira implícita ou explicita. Implícita quando alguma instrução SQL UPDATE ou DELETE são disparadas, para que o estado do registro não seja modificado um bloqueio é adquirido. Explicita é quando de maneira declarativa o usuário do SGBD solicita que a instrução SQL SELECT se comporte como uma operação UPDATE, desta forma outras transações são impedidas de escrever, deletar ou adquirir um bloqueio para o registro.

Para solicitar um bloqueio exclusivo em um PostgreSQL basta escrever uma operação SQL SELECT com as cláusulas FOR UDPATE.

  SELECT *
    FROM mesa m
   WHERE m.id = 1
     FOR UPDATE

Existem alguns bancos como postgreSQL que oferecem suporte a um bloqueio compartilhado, este bloqueio permite que apenas a transação dentetora do bloqueio solicite um bloqueio exclusivo.
Para solicitar um bloqueio compartilhado em um PostgreSQL basta escrever uma operação SQL SELECT com as cláusulas FOR SHARE.
 SELECT *
   FROM mesa m
  WHERE m.id = 1
    FOR SHARE

Construindo o mecanismo de bloqueio exclusivo com Spring Data e JPA/Hibernate

O modulo Spring Data JPA oferece suporte a especificação JPA e utiliza Hibernate como implementação padrão, isto significa que nós podemos nos aproveitar dos mecanismos de controle de concorrência da JPA/Hibernate.

Os tipos de bloqueios suportados pela JPA/Hibernate estão descritos no enum LockModeType. Abaixo está descrito quais são as propriedades responsáveis por solicitar bloqueio exclusivo ou compartilhado:

LockModeType.PESSIMISTIC_READ: esta propriedade indica que um bloqueio compartilhado deve ser adquirido.
LockModeType.PESSIMISTIC_WRITE: esta propriedade indica que um bloqueio exclusivo deve ser adquirido.

EntityManager oferece a possibilidade de realizar um bloqueio através da consulta por id. O método find() oferece suporte para através do argumento opcional lockMode que recebe um tipo de lock através do LockModeType.

Mesa mesa = entityManager.find(Mesa.class, mesaId, LockModeType.PESSIMISTIC_WRITE);

Observe o sql gerado.

SELECT m FROM Mesa m WHERE m.id = :id FOR UPDATE

Outras formas de solicitar um lock através da EntityManager são pelo método lock(), e outra alternativa é ao criar uma Query criada através do método createQuery() informar a estratégia através do método setLockMode().

Caso você utilize os repositories (Repository) da Spring Data um lock pode ser solicitado por uma consulta através da anotação @Lock(lockMode = LockModeType.PESSIMISTIC_WRITE). No exemplo a baixo é implementado uma consulta por id obtendo um bloqueio exclusivo.

public interface MesaRepository extends JpaRepository<Mesa,Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT m FROM Mesa m WHERE m.id = :id")
    Optional<Mesa> findByIdWithPessimisticLock(Long id);
}

Quando optamos por construir nosso controle de concorrência utilizando um bloqueio exclusivo estamos implementando a estratégia de Pessimistic Locking ou Bloqueio Pessimista em português. Isso se deve a estratégia de bloqueio que acredita que a melhor forma de lidar com conflitos é garantindo que eles não existam.

Construindo o Serviço para Reserva

Durante a construção do serviço de reserva é o momento onde iremos implementar uma sessão critica através da estratégia de Pessimistic Locking.

A primeiro momento é necessário que esteja bem claro que cada transação é um processo independente, e que o problema de Race Condition acontece entre a leitura do registro e a persistência da operação, ou seja, durante o período que uma transação esta processando suas operações outra transação pode alterar o estado do registro.
Então o que precisa ser feito é que dado um contexto transacional é necessário que o registro da Mesa a ser reservada obtenha um bloqueio exclusivo.

Dado isso uma possível implementação para esta logica é:

@RestController
public class ReservarMesaController {
    private final MesaRepository mesaRepository;
    private final UsuarioRepository usuarioRepository;
    private final ReservaRepository reservaRepository;

    public ReservarMesaController(MesaRepository mesaRepository, UsuarioRepository usuarioRepository, ReservaRepository reservaRepository) {
        this.mesaRepository = mesaRepository;
        this.usuarioRepository = usuarioRepository;
        this.reservaRepository = reservaRepository;
    }

    @PostMapping("/mesas/{id}/reservas")
    @Transactional
    public ResponseEntity<?> reservar(
            @PathVariable(value = "id") Long mesaId,
            @RequestBody ReservaMesaRequest request,
            UriComponentsBuilder uriBuilder
    ) {
        Mesa mesa = mesaRepository.findByIdWithPessimisticLock(mesaId)
                .orElseThrow(() -> new ResponseStatusException(NOT_FOUND, "Mesa não cadastrada"));

        Usuario usuario = usuarioRepository.findById(request.getUsuarioId())
                .orElseThrow(() -> new ResponseStatusException(UNPROCESSABLE_ENTITY, "Usuario não cadastrado"));

        LocalDateTime dataDaReserva = request.getDataReserva();

        if (reservaRepository.existsMesaByIdAndReservadoParaIs(mesaId, dataDaReserva)) {
            throw new ResponseStatusException(UNPROCESSABLE_ENTITY, "Horario indisponivel para reserva");
        }

        Reserva reserva = mesa.reservar(usuario, dataDaReserva);

        reservaRepository.save(reserva);

        URI location = uriBuilder.path("/mesas/{id}/reservas/{reservaId}")
                .buildAndExpand(mesa.getId(), reserva.getId())
                .toUri();

        return ResponseEntity.created(location).build();

    }
}

Os demais detalhes do código acima estão disponíveis no seguinte repositório.

A estratégia de Pessimistic Locking também pode trazer algumas desvantagens, caso sua tabela tenha um alto volume de acesso para operações de atualização e/ou remoção, existe a chance de que varias linhas fiquem bloqueadas, e o impacto disto é que diversas transações ficaram aguardando para serem executadas, o que resultaria em gargalos no banco que se propagariam por toda a aplicação.

Conclusão

Sistemas que envolvem reservas de recursos são fortes candidatos a sofrem com condições de corrida, isto porquê o espaço de tempo entre a leitura de um recurso e a escrita da solução é suficiente para que outro processo altere o estado do recurso causando inconsistência.

Problema de Race Conditions podem ser solucionados através da sincronização de acesso ao recurso. Para sincronizar o acesso a um determinado recurso podemos implementar uma sessão critica, que defina que apenas um processo detenha permissão suficiente para alterar o estado do recurso por vez.

Os bancos de dados relacionais oferecem mecanismos para controle de concorrência, que podem ser utilizados através das APIs da JPA/Hibernate. Sobre tudo implementar um mecanismo de controle de concorrência utilizando a estratégia de Pessimistic Lock é uma tarefa que exige atenção e cuidado, pois o uso de bloqueios exclusivos de maneira imatura podem causar uma baixa produtividade de transações o que afetaria a performance da aplicação.

Referências

Criando Controllers seguros do Mass Assignment Cheat Sheet

Jordi Henrique Silva — Mon, 25 Jul 2022 17:30:00 +0000

Se você esta iniciando sua carreira como Desenvolvedor(a) Java e utiliza Spring MVC para construir suas APIs REST já deve ter se perguntado o por quê não é utilizado a própria entidade para receber dados no Controller?

Para responder essa pergunta preciso te contar uma história bizarra que aconteceu com o GitHub. Em 2012 um hacker conseguiu explorar uma falha em um formulário de entrada, que permitiu ele se associar a organização do Ruby on Rails através de uma chave ssh publica. Após se associar este usuário possuía permissão necessária para fazer alterações nos repositórios da organização.

Isto aconteceu porquê provavelmente ele conseguiu persistir a sua chave de acesso na coleção de chaves permitidas da organização. Quando um usuário consegue alterar valores de objetos de maneira indesejada através de parâmetros de uma requisição HTTP, chamamos de Vulnerabilidade de Atribuição de Massa.

Para entender melhor imagine que um usuário mal-intencionado descobre que é possível cadastrar uma conta bancaria com um valor de saldo aprovado para uso através da requisição de criação de conta. Este usuário poderia simplesmente transferir este valor antes que a falha fosse identificada e causar sérios prejuízos ao banco.

Um exemplo de API que permita esta operação é:

@Entity
public class Conta{
    @Id
    @GenratedValue
    private Long id;
    private String titular;
    private BigDecimal saldo;
}


@RestController
public class CadastrarConta{
    @AutoWired
    private ContaRepository repository;

    @PostMapping("/contas")
    public ResponseEntity<?> cadastar(@RequestBody Conta conta, UriComponentsBuilder uriBuilder){
        repository.save(conta);

        URI location = uriBuilder.path("conta/credito/{id}")
                .buildAndExpand(conta.getId())
                .toUri();

        return ResponseEntity.created(location).build();
    }
}

Por mais que o desenvolvedor especifique que para criar uma conta é necessário enviar apenas o nome do titular no corpo da requisição. Como no exemplo abaixo:

POST /contas
...
body: {
    "titular": "Jordi Henrique Marques da Silva"
}

O usuário mal-intencionado poderia simplesmente informar o saldo na sua requisição e iniciar sua conta com valor disponível em operação. Por exemplo:

POST /contas
...
body: {
    "titular": "Jordi Henrique Marques da Silva",
    "saldo":1000000.00
}

E este é o motivo do porquê não recebemos a entidade como porta de entrada de dados no Controller, pois ficamos vulneráveis a esta falha de segurança.

Uma solução simples para este problema é inserir um objeto para representar as informações de cadastro. Este objeto é uma implementação do padrão de projeto Data Transfer Object (DTO). Neste objeto inserimos apenas os atributos referente ao cadastro da Conta, não permitindo que o usuário acesse os demais campos da entidade. Abaixo o exemplo para cadastro de conta:

public class CadastroContaDTO{
    private String titular;

    public Conta toModel(){
        return new Conta(titular);
    }
}

Para deixar o nosso Controller seguro agora basta substituir o tipo do objeto conta de Conta para CadastroContaDTO no método cadastrar e adaptar a lógica de cadastro.

@RestController
public class CadastrarConta{
    @AutoWired
    private ContaRepository repository;

    @PostMapping("/contas")
    public ResponseEntity<?> cadastar(@RequestBody CadastroContaDTO request, UriComponentsBuilder uriBuilder){

        Conta conta = request.toModel();

        repository.save(conta);

        URI location = uriBuilder.path("conta/credito/{id}")
                .buildAndExpand(conta.getId())
                .toUri();

        return ResponseEntity.created(location).build();
    }
}

O Controller adaptado fica igual ao código apresentado acima, e além de não ficar vulnerável ao ataque de atribuição de massa, ter um DTO de entrada permite que os modelos evoluam de maneira independente, ou seja, minha entidade pode ganhar novos campos, sem que meu DTO seja alterado e vice-versa.

Ter um DTO de entrada ou saída pode trazer consigo também uma otimização de dados trafegados na rede, dado que o DTO contém apenas as informações necessárias para satisfazer uma funcionalidade, campos que antes eram serializados, trafegados e não utilizados, agora não fazem mais parte da mensagem.

Conclusão

Receber uma entidade no Controller pode trazer grandes danos a segurança da sua aplicação e seu negócio, porém, ao inserir um DTO para receber estas informações, proporciona diversas vantagens como maior segurança contra vulnerabilidades, desacoplamento entre os modelos da API e negócio, e ganhos em desempenho em relação aos dados trafegados na rede.

DEV Community: Jordi Henrique Silva

Como utilizar o Type aliases do Kotlin para facilitar o Design de Código

Como uso o Type aliases para melhorar meu código?

Olhá só o que aconteceu comigo...

Foi aí que vi a oportunidade de combinar as coisas...

Evoluindo sua estratégia de Testes para FileUpload com Spring Test e Amazon S3

Desvendando o Segredo: Como Implementar File Upload com Spring Boot e Amazon S3

Jordi Henrique Silva ・ Jun 20

Escrevendo Testes de Unidade

Vamos ver como funciona na prática

Ai eu te pergunto, como esse teste me ajuda a garantir que o FileUpload funciona como deveria?

3 dicas para criar uma estratégia moderna de Testes para Microsserviços Spring Boot

Jordi Henrique Silva ・ Feb 19

Evoluindo para um Teste de Integração com Spring Test, Test Containers e LocalStack

Conclusão

Desvendando o Segredo: Como Implementar File Upload com Spring Boot e Amazon S3

E a pergunta que não quer calar? Como Implemento um FileUploader com Spring Boot e Amazon S3?

1 - Configurando a Aplicação para Utilizar o Amazon S3

JordiHOFC / sample-storage-file-with-spring-aws-s3

This repository is about how to implemented FileUpload Application with Spring Boot and Amazon S3

2 - Escrevendo o Serviço de Upload de Arquivo

Conclusão

3 dicas para criar uma estratégia moderna de Testes para Microsserviços Spring Boot

3 motivos do porquê testes unitários não são suficientes para Microservices com Spring Boot

Jordi Henrique Silva ・ Dec 14 '22

1. Entenda o contexto e conheças as dependências da sua solução

2. Utilize ferramentas de testes modernas como TestContainers e WireMock para simular suas dependências

3. Escreva seus testes nas etapas de Cenário, Ação e Validação ou AAA Pattern.

Vamos ver na prática?

Aplicando o conhecimento

Conclusão

3 Estratégias para sincronizar cache na camada de aplicação

Turbinando seus Microsserviços com Spring Cache e Redis

Jordi Henrique Silva ・ Feb 28 '23

Cache e sua importância

Estratégias para sincronização de Cache

Cache a side

Read Through

Write Behind

Conclusão

Turbinando seus Microsserviços com Spring Cache e Redis

Spring Cache com Redis

Configurando a Aplicação

Cacheando Resultados

Invalidando o Cache

Conclusão

Referências

Escrevendo Testes de Integração para Producers Kafka Com Spring Boot e EmbeddedBroker

Configurando o KafkaEmbeddedBroker para fazer Testes Integrados

Definição das propriedades do Consumer

Conclusão

3 motivos do porquê testes unitários não são suficientes para Microservices com Spring Boot

Conclusão

Criando Sistemas de Reservas Com Versionless Optimistic Locking, Spring Boot e JPA/Hibernate

Version-less optimistic locking

Versionless Optmistic Locking com Hibernate

Controle de Concorrência com OptimisticLockType.ALL

Controle de Concorrência com OptimisticLockType.DIRTY

Construindo uma API REST para reserva de mesas com Versionless Optimistic Locking

Conclusão

Referências

Criando Sistemas de Reservas consistentes com Optimistic Locking, Spring Boot e JPA/Hibernate

Conhecendo o Optimistic Locking

Optimistic Locking com JPA/Hibernate

Construindo uma API REST para reserva de mesas com Optimistic Locking

Conclusão

Referências

Criando Sistemas de Reservas consistentes com Pessimistic Locking, Spring Boot e JPA/Hibernate

Obtendo Pessimistic Locking em seu banco de dados relacional

Construindo o mecanismo de bloqueio exclusivo com Spring Data e JPA/Hibernate

Construindo o Serviço para Reserva

Conclusão

Referências

Criando Controllers seguros do Mass Assignment Cheat Sheet

Conclusão

Configurando o `KafkaEmbeddedBroker` para fazer Testes Integrados

Controle de Concorrência com `OptimisticLockType.ALL`

Controle de Concorrência com `OptimisticLockType.DIRTY`

Obtendo `Pessimistic Locking` em seu banco de dados relacional