DEV Community: William Moreira da Silva

Assinatura Digital em Elixir com Criptografia Assimétrica

William Moreira da Silva — Fri, 19 Sep 2025 23:44:02 +0000

Você já se perguntou como funciona um fluxo de assinatura digital?

Quando falamos de documentos digitais, surge a dúvida: como garantir que esse arquivo é autêntico e não foi alterado? É justamente para resolver isso que existe a assinatura digital.

A ideia é simples: você gera um hash do documento (uma espécie de “impressão digital”) e usa sua chave privada para assinar esse hash. Quem receber o documento pode, com a chave pública correspondente, verificar se a assinatura é legítima. Assim, temos duas garantias:

O documento não foi adulterado.
A assinatura só poderia ter vindo do dono da chave privada.

No caso de PDFs — pense em contratos ou qualquer documento de valor jurídico — isso é ainda mais relevante. No Brasil, por exemplo, a assinatura digital é regulamentada pela ICP-Brasil, dando validade legal a documentos assinados eletronicamente.

E aí entra o nosso protagonista: Elixir. Por rodar na máquina virtual do Erlang (a BEAM), a linguagem já oferece ferramentas nativas de criptografia, prontas para uso. Ou seja, você não precisa de bibliotecas externas para começar a brincar com chaves e assinaturas digitais.

Mão na massa: assinando em Elixir

1. Gerando um par de chaves

Primeiro passo: criar o par de chaves RSA (privada e pública). Com elas, vamos assinar e validar os documentos.

# Criando um par de chaves RSA com 2048 bits
{:ok, rsa_key} = :public_key.generate_key({:rsa, 2048, 65537})
{:RSAPrivateKey, _, modulus, public_exp, _private_exp, _, _, _, _} = rsa_key
# private_key é a chave que você deve manter em segredo absoluto. Ela nunca deve ser compartilhada.
public_key = {:RSAPublicKey, modulus, public_exp}
# public_key é a chave que pode ser distribuída para qualquer pessoa que precise validar suas assinaturas.
private_key = rsa_key

Pronto, agora temos as duas chaves na mão.

⚠️ Boa prática: em um sistema real, essa chave privada não deve ficar no código nem em arquivos simples. algum tipo de cofres digitais como HashiCorp Vault.

2. Gerando o hash de um PDF

Antes de assinar, precisamos transformar o conteúdo do arquivo em um hash. Esse hash vai ser a base da assinatura.

pdf_content = File.read!("contrato.pdf")
# O hash é como a impressão digital do documento (podemos dizer que é um resumo criptográfico).
hash = :crypto.hash(:sha256, pdf_content)

Alterou uma vírgula no PDF? O hash já muda completamente. Isso garante a integridade.

⚠️ Boa prática: sempre use algoritmos de hash considerados seguros. Evite MD5 ou SHA-1, que já foram quebrados e não são confiáveis para assinatura digital.

3. Assinando com a chave privada

Com o hash pronto, agora é só assinar:

# Estamos aplicando a chave privada sobre o hash.
signature = :public_key.sign(hash, :sha256, private_key)

O resultado, signature, é uma sequência de bytes que comprova que você (e só você) poderia ter gerado essa assinatura, já que só você tem a chave privada. Esse signature é o que vai junto do documento. Ele prova que quem assina tinha a chave privada correta.

⚠️ Boa prática: normalmente, essa assinatura é guardada separada do arquivo (como um .sig) ou embutida em metadados do PDF. Assim, o documento em si continua intacto.

4. Validando com a chave pública

Quem recebe o documento precisa verificar se está tudo certo:

# Aqui, usamos a chave pública para verificar a assinatura.
valid? = :public_key.verify(hash, :sha256, signature, public_key)

# Se valid? for true, temos duas garantias: o documento não foi alterado e foi assinado por quem realmente possui a chave privada correspondente.
if valid? do
  IO.puts("Tudo certo: assinatura válida e documento íntegro.")
else
  IO.puts("Ops! Assinatura inválida ou documento adulterado.")
end

⚠️ Boa prática: sempre valide o hash antes de confiar no documento. Não basta “parecer” assinado; é preciso confirmar criptograficamente.

Simples assim!!

5. Indo além

Esse fluxo básico já garante muita coisa. Mas no mundo real, é importante expandir nos seguintes pontos:

Múltiplas assinaturas em um mesmo PDF, cada uma com seu carimbo.
Metadados no próprio PDF, guardando assinatura, certificados e tudo mais.
timestamp, pra provar não só que o documento é válido, mas quando foi assinado.

Esses que pontos são super úteis em cenários jurídicos ou financeiros, onde cada detalhe pode toda faz diferença.

Conclusão

A assinatura digital é essencial para garantir autenticidade, integridade e validade jurídica de documentos. E vimos como o Elixir + Erlang tornam esse processo simples e confiável: em poucas linhas conseguimos gerar chaves, assinar e validar documentos, com a robustez de uma plataforma madura.

Entendemos o conceito de assinatura digital, vimos como gerar chaves RSA, como criar e assinar o hash de um PDF e como validar essa assinatura. A pergunta da introdução era: como funciona um fluxo de assinatura digital? Agora temos a resposta clara — ele envolve gerar um hash, assinar com a chave privada e validar com a chave pública.

Ou seja, além de mostrar a versatilidade do Elixir no mundo da criptografia, conseguimos destrinchar um processo que, no fim das contas, é bem mais direto do que parece.

No fim, o fluxo de assinatura digital nada mais é do que hash + chave privada + chave pública — simples na teoria, poderoso na prática.

Por que o Elixir é melhor que Node.js para Processamento Assíncrono?

William Moreira da Silva — Fri, 30 Aug 2024 16:42:32 +0000

Resposta simples: Node.js é single-threaded e divide esse único thread para simular concorrência, enquanto Elixir aproveita a concorrência e o paralelismo, nativo, da BEAM, a máquina virtual do Erlang, para executar processos simultaneamente.

Abaixo, vamos entender mais a fundo essa diferença, explorando dois conceitos-chave: o event loop do Node.js e a BEAM VM e OTP do Elixir. Esses elementos são cruciais para compreender como cada tecnologia lida com a execução de tarefas assíncronas e como isso afeta o desempenho e a escalabilidade em diferentes aplicações.

1. O Que é o Event Loop?

O Node.js opera em uma única thread principal e utiliza um mecanismo chamado event loop para gerenciar operações assíncronas. O conceito básico é que ele verifica se há tarefas pendentes para serem processadas, como operações de I/O, promises e callbacls, e as executa quando estão prontas.

1.1 Como funciona na prática:

Quando uma operação assíncrona é iniciada (por exemplo, uma consulta a uma API por exemplo), ela é delegada para a libuv. Enquanto isso, o event loop continua a aceitar outras conexões.
Quando a operação assíncrona termina, a libuv retorna o resultado para a event queue, então event loop coloca o callback associado à operação, na call stack.

1.2 Limitações do Event Loop:

Se uma tarefa demorada ou de CPU intensa estiver na call stack, ela pode bloquear o processamento de outras operações, reduzindo a eficiência.
A concorrência é limitada, pois tudo é executado em um único thread principal.

2. BEAM VM e OTP

Elixir é construído sobre a BEAM VM, a mesma máquina virtual que alimenta Erlang, conhecida por sua capacidade de lidar com alta concorrência e resiliência. Ao contrário de Node.js, Elixir não depende de um único thread. Em vez disso, utiliza processos extremamente leves e isolados gerenciados pela BEAM.

2.1 Como funciona na prática:

Cada processo em Elixir é independente, o que significa que eles não compartilham memória e não bloqueiam uns aos outros.
Esses processos são gerenciados pela BEAM, que pode criar e gerenciar milhões de processos simultaneamente, distribuindo a carga entre todos os núcleos de CPU disponíveis.
Além disso, Elixir vem com o OTP (Open Telecom Platform), que fornece um conjunto de bibliotecas e ferramentas para construir sistemas robustos e distribuídos.

2.2 Vantagens da BEAM e OTP:

Escalabilidade: A BEAM pode distribuir processos entre todos os núcleos de CPU, maximizando o uso de recursos.
Resiliência: Se um processo falha, ele não afeta outros processos. Isso permite construir sistemas tolerantes a falhas.
Concorrência Real: Diferente do loop de eventos, que é limitado por um único thread, Elixir pode executar processos verdadeiramente em paralelo, aproveitando múltiplos núcleos de CPU.

3. Comparando Node.js e Elixir na Prática

Vamos imaginar um servidor que precisa lidar com milhares de conexões simultâneas, cada uma realizando operações asyncronas e alguns processamentos pesado e mais demorados.

3.1 Com Node.js:

O servidor é eficiente até certo ponto, mas à medida que as operações pesadas se acumulam, o loop de eventos começa a ficar sobrecarregado. Embora um bom uso dos recursos disponivel no JS e Node podem ajudar bastante na performance: como o uso correto do async/wait e/ou then/catch e recursos built-in como a lib node:cluster
Isso pode levar a atrasos nas resposta de novas conexões, resultando em um empacto significativo no desempenho.

3.2 Com Elixir:

Cada conexão pode ser gerenciada por um processo separado. Operações de I/O, computação e até falhas podem ser geridas de forma isolada.
A BEAM distribui a carga de forma eficiente, garantindo que o sistema continue a funcionar sem maiores problemas, mesmo sob alta demanda.
Se necessario é possivel fazer uma comunicacao entre processos via mensagem.
Mecanismo Preemptive Scheduling da BEAM.

Conclusão

Node.js é uma excelente ferramenta para muitas aplicações, especialmente aquelas que lidam com operações assíncronas simples e que não exigem processamento pesado de CPU. No entanto, seu modelo de concorrência baseado em um único thread pode ser um gargalo em cenários mais complexos.

Elixir, com BEAM VM e suporte nativo a processos leves e concorrência massiva, oferece uma alternativa robusta e eficiente para sistemas que precisam lidar com grande número de operações simultâneas e distribuir carga entre múltiplos threads do CPU. Se você precisa de resiliência, escalabilidade e alta concorrência, Elixir é a escolha.

Embora o título deste artigo seja ousado ao sugerir que Elixir e a BEAM superam Node.js em processamento assíncrono, é importante reconhecer que existem diferenças significativas entre essas tecnologias. A decisão sobre qual delas utilizar deve considerar uma variedade de fatores, não apenas a concorrência e o paralelismo abordados aqui. Aspectos como o ecossistema, a familiaridade da equipe com a linguagem, requisitos específicos do projeto, e a natureza das tarefas a serem executadas desempenham um papel crucial na escolha da melhor ferramenta para o trabalho. Afinal, cada cenário tem suas particularidades, e a escolha da tecnologia deve ser feita com uma visão holística, levando em conta todas as necessidades e desafios do projeto.

Bibliografia

Threads:

Threads são as menores unidades de execução em um programa. Em muitos sistemas operacionais, um processo pode conter múltiplas threads, cada uma executando uma parte diferente do programa. Threads podem compartilhar memória e recursos, mas isso pode levar a problemas de concorrência, como condições de corrida.

Concorrência:

Concorrência é a capacidade de um sistema lidar com múltiplas tarefas ao mesmo tempo. Em um sistema concorrente, várias tarefas podem progredir independentemente, mesmo que não estejam sendo executadas simultaneamente. A BEAM, por exemplo, gerencia processos concorrentes que operam de forma independente.

Event Loop:

O event loop é um padrão de design usado em sistemas como Node.js para gerenciar operações assíncronas. Ele funciona em um único thread, executando tarefas de forma cíclica, respondendo a eventos como I/O e execuções assíncronas, garantindo que o programa continue respondendo enquanto espera por operações longas.

Paralelismo:

Paralelismo é a execução simultânea de múltiplas tarefas em diferentes núcleos de CPU. Diferente da concorrência, que se refere à gestão de tarefas simultâneas, o paralelismo envolve a execução real dessas tarefas ao mesmo tempo. A BEAM distribui processos em múltiplos núcleos para maximizar o paralelismo.

Processos Leves (Lightweight Processes):

Na BEAM, processos leves são unidades de execução que são muito mais eficientes em termos de memória e CPU do que threads tradicionais. Eles são isolados uns dos outros e gerenciados pela BEAM, o que permite criar e gerenciar milhões de processos simultâneos.

Preemptive Scheduling:

Preemptive scheduling é um sistema de gerenciamento de tempo de execução onde o sistema operacional ou a máquina virtual atribui fatias de tempo a cada processo, garantindo que nenhum processo monopolize a CPU. Na BEAM, isso assegura que todos os processos tenham a chance de ser executados de maneira justa.

BEAM VM:

A BEAM (Bogdan/Björn's Erlang Abstract Machine) é a máquina virtual que executa código Erlang e Elixir. É conhecida por sua habilidade em gerenciar processos leves de forma eficiente, suportando concorrência massiva e paralelismo, além de fornecer tolerância a falhas.

OTP (Open Telecom Platform):

OTP é um conjunto de bibliotecas e padrões de design que acompanham Erlang e Elixir. Ele fornece ferramentas para construir sistemas concorrentes, distribuídos e tolerantes a falhas, facilitando o desenvolvimento de aplicações robustas e escaláveis.

libuv

é uma biblioteca multi-plataforma que fornece suporte para operações de I/O assíncronas em Node.js. Ela é responsável por implementar o event loop e abstrair funcionalidades de sistema operacional, como operações de rede, sistema de arquivos, e threads. libuv permite que Node.js execute tarefas assíncronas de maneira eficiente em um único thread, utilizando um pool de threads internas para operações bloqueantes, garantindo a continuidade do event loop principal.

operações de I/O

Operações de I/O (Input/Output) referem-se a qualquer interação entre um programa e o mundo externo, como ler ou escrever em arquivos, comunicar-se com dispositivos de hardware, ou trocar dados pela rede. Essas operações podem ser demoradas e, em muitos sistemas, são realizadas de maneira assíncrona para evitar que o programa fique bloqueado enquanto aguarda a conclusão da operação.

Referências

ERLANG. A brief BEAM primer. Erlang Blog, 2020. Disponível em: https://www.erlang.org/blog/a-brief-beam-primer/. Acesso em: 29 ago. 2024.

ERLANG. Getting started with Erlang [PDF]. Erlang.org. Disponível em: https://erlang.org/download/erlang-book-part1.pdf. Acesso em: 29 ago. 2024.

NODE.DOCTORS. An animated guide to Node.js event loop. Dev.to, 2021. Disponível em: https://dev.to/nodedoctors/an-animated-guide-to-nodejs-event-loop-3g62. Acesso em: 29 ago. 2024.

NODE.DOCTORS. Animated Node.js event loop phases. Dev.to, 2022. Disponível em: https://dev.to/nodedoctors/animated-nodejs-event-loop-phases-1mcp. Acesso em: 29 ago. 2024.

NODE.JS. Cluster. Node.js, 2023. Disponível em: https://nodejs.org/api/cluster.html. Acesso em: 29 ago. 2024.

[MICROSERVICES] Message Queues e REST – Uma Abordagem com Go, NodeJS e Clean Architecture

William Moreira da Silva — Mon, 19 Aug 2024 20:43:25 +0000

Tabela de Conteúdos

1. Um Breve Contexto
2. Tecnologias e Arquitetura Geral
2.1. Arquitetura de Microservices
2.2. Comunicação entre Microservices
2.2.1. Message Queues (Comunicação Assíncrona)
2.2.2. APIs REST (Comunicação Síncrona)
2.3. Clean Architecture
3. O Ecosistema do Projeto
4. Desafios e Considerações Finais
4.1. Desafios na Implementação
4.2. Próximos Passos
4.3. Conclusão
5. Referências
6. Disclaimer

1. Um breve contexto

Nos últimos anos, a arquitetura de microserviços tem se tornado uma escolha popular para construir sistemas escaláveis, flexíveis e de fácil manutenção. Ao dividir uma aplicação em serviços menores e independentes, é possível manter, testar e subir cada serviço de forma autônoma, facilitando a escalabilidade e a inclusão de novas tecnologias.

Neste artigo, exploraremos a criação de uma arquitetura de microserviços utilizando Go e NodeJS, duas linguagens amplamente usadas e, neste contexto, com características complementares. Além disso, aplicaremos os princípios da Clean Architecture, uma abordagem de design que visa manter o código limpo, modular e fácil de manter, e testar, garantindo que a lógica de negócio esteja isolada das preocupações de infraestrutura e/ou dependências.

O objetivo deste projeto é praticar Go, uma linguagem que tenho estudado recentemente, e revisitar conceitos fundamentais de microserviços. Paralelamente, utilizaremos TypeScript no desenvolvimento dos serviços, aplicando os princípios da Clean Architecture para reforçar boas práticas de design de software.

A partir dessas premissas, teremos a oportunidade de explorar tanto os pontos positivos quanto os desafios dessa abordagem. Afinal, nem todo negócio exige uma estrutura tão complexa, e um projeto prático é a melhor forma de entender suas reais necessidades e implicações.

2. Tecnologias e Arquitetura Geral

2.1 Arquitetura de Microservices

A arquitetura de microservices divide uma aplicação em serviços menores e independentes, cada um responsável por uma parte específica da funcionalidade. Esses serviços se comunicam por meio de APIs bem definidas, o que facilita a manutenção, escalabilidade e adoção de novas tecnologias.

Benefícios:

Modularidade: Facilita a manutenção e o desenvolvimento independente de cada serviço.
Escalabilidade: Permite a escalabilidade individual de cada serviço conforme a demanda.
Resiliência: Isola falhas e reduz o impacto de problemas em um serviço sobre outros.
Comparação com Monolitos:

Monolitos: Aplicações integradas em uma unica code base. Embora simples inicialmente, podem se tornar difíceis de manter e escalar com o tempo.

Microservices: Oferecem maior flexibilidade e escalabilidade, mas podem criar um complexidade adicional na gestão e comunicação entre serviços.

2.2 Comunicação entre Microservices

Em uma arquitetura de microservices, a comunicação entre serviços pode ser feita de duas formas principais: comunicação assíncrona, usando message queues por exemplos e comunicação síncrona, através de APIs REST. Vale destacar que existem outra forma de comunição além de queue e rest.

2.2.1 Message Queues (Comunicação Assíncrona)

As filas de mensagens são usadas para permitir a comunicação assíncrona entre microservices. Elas permitem que serviços enviem e recebam mensagens sem precisar de uma resposta imediata, o que ajuda a melhorar a resiliência e a escalabilidade do sistema.

Papel das Filas de Mensagens:

Comunicação Assíncrona: Facilita a troca de informações entre serviços sem necessidade de resposta instantânea.
Resiliência: Gerencia picos de carga e falhas temporárias, garantindo que mensagens sejam processadas eventualmente.

Implementação:

Ferramentas: RabbitMQ e Kafka são opções populares para gerenciar filas de mensagens.
Integração: Implementar filas de mensagens para comunicação entre serviços escritos em Go e NodeJS, garantindo uma troca de dados eficiente e escalável.

2.2.2 APIs REST (Comunicação Síncrona)

APIs RESTful são usadas para comunicação síncrona entre serviços. Elas são baseadas em princípios HTTP e permitem que serviços interajam de maneira padronizada e eficiente.

2.3 Clean Architecture

Clean Architecture é uma abordagem de design que visa criar sistemas com um código base bem organizado e fácil de manter e/ou testar. Ela enfatiza a separação de preocupações e a independência de camadas.

Princípios da Clean Architecture:

Separação de Camadas: Dividir o código em camadas distintas (domínio, aplicação, infraestrutura) para isolar a lógica de negócio das preocupações técnicas.
Independência de Frameworks e Bibliotecas: Garantir que a lógica de negócio não seja dependente de frameworks ou tecnologias específicas.
Aplicação em Microservices:

Organização do Código: Estruturar cada microservice seguindo os princípios da Clean Architecture para garantir um código modular, testável e fácil de manter.
Manutenção e Evolução: Facilitar a adição de novas funcionalidades e a modificação de existentes sem comprometer a integridade do sistema.

3. O ecosistema do projeto

No ecossistema de microservices, um endpoint HTTP desempenha um papel crucial na orquestração do fluxo de trabalho dos documentos, neste context, é onde tudo começa. Este endpoint é responsável por receber e processar a solicitação para criar um novo documento. Ao receber uma requisição, ele enfileira o documento para o worker em Go, que se encarregará da geração e processamento do documento. Além disso, o endpoint emite uma notificação para o serviço de documentos por meio de uma Message Queue, informando que um novo recurso, ou seja, um documento, entrou na fila para processamento. Esta abordagem assegura uma integração eficiente entre os componentes do sistema, permitindo que o endpoint gerencie a criação e o rastreamento dos documentos de forma coordenada e assíncrona, enquanto o worker em Go cuida da criação efetiva dos documentos e o serviço de documentos é atualizado sobre novos itens na fila.

Além do endpoint HTTP, o sistema conta com dois workers com papéis distintos. O primeiro, implementado em Go, é responsável pela geração dos documentos. Ele consome tarefas de uma fila de mensagens, processa os dados e, ao concluir o processamento, notifica um endpoint específico sobre a conclusão. A eficiência do Go garante um processamento rápido e robusto. O segundo worker, desenvolvido em NodeJS, lida com a criação do estado inicial dos documentos, definindo-os como "não processado" ao serem inseridos no sistema. A agilidade do NodeJS permite uma gestão rápida e eficiente dos estados dos documentos desde o início do fluxo de trabalho.

Em resumo, o sistema descrito demonstra um fluxo bem coordenado para o gerenciamento de documentos. O endpoint HTTP, em conjunto com os workers em Go e NodeJS, proporciona uma solução integrada e eficiente, garantindo desde a criação até a conclusão do processamento dos documentos. A interação entre os workers e o REST, é refletida na imagem da arquitetura abaixo, que ilustra como a arquitetura promove escalabilidade e modularidade, assegurando um fluxo de trabalho robusto e coordenado. Esta abordagem não só melhora a eficiência operacional, mas também pode ser adaptada para diferentes cenários de uso, oferecendo flexibilidade e crescimento futuro.

O desenho final:

O repositorio do projeto: https://github.com/williamMDsilva/microservice-poc

4. Desafios e Considerações Finais

4.1 Desafios na Implementação

Implementar uma arquitetura de microservices com a Clean Architecture pode apresentar diversos desafios. Um dos principais desafios é o entendimento profundo do negócio para criar um código que seja verdadeiramente escalável e mantenha a integridade da lógica de negócio. A Clean Architecture exige que o código seja estruturado de forma a separar claramente as preocupações, o que demanda um conhecimento detalhado do domínio para que as abstrações e separações sejam efetivas.

Além disso, o conhecimento dos princípios SOLID é crucial. Estes princípios ajudam a criar um código mais coeso e menos acoplado, e um entendimento sólido deles pode economizar tempo significativo na pesquisa e resolução de problemas. A aplicação dos princípios SOLID não apenas melhora a qualidade do código, mas também facilita a manutenção e a escalabilidade do sistema.

No caso específico do Go, uma base sólida na linguagem pode melhorar a legibilidade e a manutenção do código. Go oferece ferramentas e práticas que ajudam a manter o código limpo e eficiente, e um conhecimento mais profundo pode fazer a diferença na implementação de serviços complexos.

Por fim, o uso de um bom boilerplate pode ser extremamente benéfico. Boilerplates bem projetados para a Clean Architecture não apenas aceleram o início do desenvolvimento, mas também garantem que novos recursos sejam adicionados dentro do padrão proposto inicialmente. Eles oferecem uma estrutura que ajuda a manter a consistência e a qualidade do código ao longo do projeto.

4.2 Próximos Passos

Para avançar e melhorar a arquitetura descrita, alguns próximos passos são recomendados:

Incluir Recursos de Monitoramento e Observabilidade: Implementar ferramentas de monitoramento e observabilidade é essencial para garantir a saúde e o desempenho do sistema. A inclusão de métricas, logs e tracing ajuda a identificar problemas e a analisar o comportamento do sistema em produção.
Adicionar Tratativas para Indisponibilidade: É crucial incluir mecanismos para lidar com falhas e indisponibilidades, como retries, circuit breakers e fallback strategies, para aumentar a resiliência do sistema e garantir a continuidade dos serviços.
Realizar Testes Unitários e de Integração: Testes são fundamentais para garantir a qualidade do código e a integração correta dos componentes. Testes unitários verificam o funcionamento de partes isoladas do código, enquanto testes de integração asseguram que os diferentes componentes do sistema funcionam corretamente em conjunto.
Refatorar Serviços e Módulos: Revisar e refatorar serviços e módulos existentes para garantir que o código permaneça limpo, legível e alinhado com os princípios da Clean Architecture é uma tarefa contínua que melhora a manutenabilidade e a escalabilidade do sistema.
Prova de Conceito com Kafka: Considerar uma prova de conceito para substituir o RabbitMQ por Kafka pode oferecer uma visão sobre como diferentes ferramentas impactam o projeto. A análise do impacto no design do serviço e na arquitetura geral pode fornecer insights valiosos para futuras decisões tecnológicas.

4.3 Conclusão

Este projeto demonstrou a eficácia de uma arquitetura bem planejada e a importância de uma implementação cuidadosa dos princípios da Clean Architecture. O uso de Go e NodeJS, combinado com práticas como SOLID e o emprego de message queues e APIs REST, contribuiu para um sistema robusto e escalável. No entanto, o desenvolvimento e a manutenção de uma arquitetura de microservices apresentam desafios que exigem um conhecimento profundo do negócio e da tecnologia. Enfrentar esses desafios com um planejamento adequado e a adoção de boas práticas ajuda a garantir a construção de sistemas eficientes e sustentáveis. O caminho adiante envolve a incorporação de melhorias contínuas, como monitoramento avançado e novas provas de conceito, para manter a arquitetura alinhada com as necessidades e evolução do negócio.

5. Referências

Martin, R. C. (2008). Código Limpo: Habilidades Práticas do Agile Software. Alta Books.

Martin, R. C. (2017). Arquitetura Limpa: Estruturas e Princípios para o Design de Software. Alta Books.

RabbitMQ. (n.d.). Tutorial Two - JavaScript. Retrieved from https://www.rabbitmq.com/tutorials/tutorial-two-javascript

RabbitMQ. (n.d.). Tutorial Two - Go. Retrieved from https://www.rabbitmq.com/tutorials/tutorial-two-go

Disclaimer

Devido à natureza acadêmica e de prova de conceito deste projeto, alguns recursos não foram implementados e permanecem como débitos técnicos para futuros estudos. Áreas como testes automatizados, tratamento de erros, stream de recursos, autenticação nos serviços e observabilidade são temas que ainda precisam ser explorados. Toda crítica construtiva é bem-vinda e encorajada, pois contribui para a melhoria contínua e o aprofundamento no conhecimento dessas áreas importantes.

Elevando a Qualidade: Guia Prático de Testes em Cypress para Componentes e E2E em Aplicações React

William Moreira da Silva — Fri, 12 Jan 2024 01:42:20 +0000

Os testes desempenham um papel fundamental no desenvolvimento de aplicações, garantindo a estabilidade, confiabilidade e qualidade do código. Neste artigo, vamos explorar a importância dos testes de componentes e os end-to-end (E2E) usando Cypress em aplicações React.

Um pouco sobre Cypress

O Cypress é uma poderosa ferramenta de automação de testes end-to-end (E2E) projetada para facilitar o processo de teste em aplicações web. Com um foco especial na simplicidade de uso e eficácia, o Cypress ganhou popularidade entre desenvolvedores e equipes de QA devido às suas características distintivas. Seu design intuitivo e capacidades abrangentes tornam-no uma peça fundamental no processo de garantia de qualidade para aplicações web modernas.

Principais Características:

Integração Simples: A instalação do Cypress é direta, e a integração com projetos existentes é fácil
Testes em Tempo Real: Ao contrário de muitas ferramentas de automação, o Cypress executa testes em tempo real enquanto interage com a aplicação, fornecendo feedback instantâneo e facilitando a depuração.
Comandos Simples e Intuitivos: A sintaxe dos comandos Cypress é clara e intuitiva. Operações comuns, como clicar em elementos, preencher formulários e verificar resultados, são expressas de maneira concisa.
Execução em Navegadores Reais: O Cypress executa testes diretamente em navegadores reais, o que significa que os desenvolvedores podem confiar na precisão dos resultados e na consistência com a experiência do usuário real.
Conceito de "Subjects" e Encadeamento de Comandos (chains of commands): O Cypress gerencia um conceito de "subject" que permite o encadeamento natural de comandos, simplificando a construção de testes complexos.
Ampla Gama de Assertivas (Assertions): A capacidade de verificar o estado do DOM e dos elementos usando assertivas robustas simplifica a validação de resultados esperados.
Visual Regression Testing Integrado: O Cypress pode integrar facilmente testes de regressão visual, comparando capturas de tela para identificar alterações visuais não intencionais.
API Mocking e Testes de API: A capacidade de simular chamadas de API e realizar testes de integração com facilidade contribui para uma cobertura de teste mais abrangente.
Timeouts Configuráveis: O Cypress gerencia timeouts automaticamente, mas oferece controle configurável para adaptar a execução dos testes conforme necessário.
Comunidade Ativa e Suporte Contínuo: O Cypress possui uma comunidade ativa, com suporte constante e atualizações frequentes, garantindo que a ferramenta permaneça relevante e eficiente.

Definindo algumas bases

Segue aqui alguns pontos importantes para utilizar o cypress com maestria.

Esse e vários outros pontos podemos encontrar na própria documentação do cypress:

1. Como o Cypress consulta o DOM:

O Cypress possui comandos específicos para interagir com elementos no DOM. Veja um exemplo de como você pode usar o comando cy.get para consultar e interagir com um elemento:

// Consulta e interação com um botão usando seu seletor
cy.get('button').click();

// Consulta e interação com um input usando um atributo específico
cy.get('[data-cy=username-input]').type('nome de usuário');

2. Como o Cypress gerencia subjects e chains of commands:

O Cypress mantém uma referência ao elemento alvo como um "subject". Cada comando retorna um novo "subject", permitindo a encadeamento de comandos. Veja um exemplo:

// Cada comando retorna um novo "subject"
cy.get('ul')
  .find('li')   // O subject agora é a lista de itens dentro da ul
  .first()      // O subject agora é o primeiro item da lista
  .click();     // Clicando no primeiro item

3. Como as assertivas (assertions) funcionam:

As assertivas no Cypress são usadas para verificar se o estado do DOM ou de outros elementos é como esperado. Exemplo:

cy.get('.status-message').should('be.visible'); // Verifica se o elemento está visível

cy.get('input[name="username"]').should('have.value', 'nome de usuário'); // Verifica o valor do input

4. Como os timeouts são aplicados aos comandos:

O Cypress gerencia timeouts automaticamente, mas você pode personalizá-los conforme necessário. Exemplo:

// Configuração de um timeout específico para um comando
cy.get('elemento').click({ timeout: 10000 }); // Timeout de 10 segundos para o clique

Esses exemplos demonstram como os conceitos fundamentais do Cypress são aplicados no contexto de consultas ao DOM, manipulação de "subjects", execução de assertivas e controle de timeouts. O Cypress é uma ferramenta poderosa que oferece controle detalhado sobre interações com o DOM e facilita a criação de testes E2E robustos.

Conceitos que irão parecer por aqui

Subjects:

No contexto do Cypress, "subjects" referem-se aos elementos HTML ou objetos que são o foco de uma cadeia de comandos. Cada comando no Cypress gera um novo "subject", e os comandos subsequentes são executados em cima desse "subject". Isso cria uma forma natural de encadear comandos, simplificando a escrita de testes e a interação com o DOM. Por exemplo:

cy.get('button')   // "get" retorna um novo "subject" representando o botão
  .click()        // "click" é executado no "subject" do botão
  .should('be.visible');  // "should" é executado no "subject" após o clique

Chains of Commands:

As "chains of commands" (cadeias de comandos) referem-se à sequência de comandos encadeados que são executados em Cypress. Cada comando gera um novo "subject" que é passado para o próximo comando na cadeia. Isso cria uma forma clara e concisa de expressar interações e verificações em testes E2E. Exemplo:

cy.get('.menu')
  .should('be.visible')
  .contains('Item de Menu')
  .click()
  .should('have.class', 'ativo');

Assertions:

As assertivas em Cypress são usadas para verificar se o estado de um "subject" ou de um elemento DOM corresponde às expectativas definidas no teste. Elas ajudam a garantir que a aplicação está se comportando conforme o esperado. Um exemplo comum usando a assertiva should:

cy.get('.elemento').should('be.visible');

Neste exemplo, a assertiva verifica se o elemento com a classe ".elemento" está visível.

Visual Regression Testing Integrado:

O Visual Regression Testing é uma técnica que compara imagens ou capturas de tela da aplicação em diferentes momentos para detectar alterações visuais inesperadas. O Cypress oferece integração nativa com esse tipo de teste, permitindo comparar automaticamente capturas de tela durante a execução do teste. Isso ajuda a identificar alterações visuais que podem ocorrer inadvertidamente ao longo do desenvolvimento.

cy.visit('/pagina');
cy.matchImageSnapshot();  // Compara a página atual com uma referência anterior

esse exemplo é bem simplório, veja a documentação do cypress para aprofundar no assunto. https://docs.cypress.io/guides/tooling/visual-testing

API Mocking:

API Mocking refere-se à capacidade de simular chamadas de API durante os testes. Isso permite isolar o frontend do backend, garantindo que os testes se concentrem apenas no comportamento do frontend. O comando cy.intercept é comumente utilizado para definir respostas simuladas para solicitações de API. Exemplo:

cy.intercept('GET', '/api/dados', { fixture: 'dados.json' }).as('getDados');
cy.visit('/dashboard');
cy.wait('@getDados').its('response.statusCode').should('eq', 200);

Neste exemplo, a chamada de API é interceptada e substituída por uma resposta simulada, garantindo que os testes não dependam da disponibilidade do backend real durante a execução.

Testes de Componentes em React:

Os testes de componentes em React visam verificar se os componentes individuais funcionam conforme o esperado. Isso pode incluir testes de renderização, manipulação de estados, interações do usuário e muito mais. A biblioteca de testes mais comum para React é o Jest, frequentemente combinado com React Testing Library para testes centrados no usuário.

Exemplo de teste de renderização com Jest:

import { render, screen } from '@testing-library/react';
import Component from './Component';

test('renderiza o componente corretamente', () => {
  render(<Component />);
  const elemento = screen.getByText(/texto do component/i);
  expect(elemento).toBeInTheDocument();
});

Exemplo com Cypress

import React from "react";
import ErrorMessage from "./ErrorMessage";

function ErrorMessage({ message }) {
  return <div className="error-message">{message}</div>;
}

describe("<ErrorMessage />", () => {
  it("renders", () => {
        // instancia do componente
    cy.mount(<ErrorMessage message="Mensagem de erro" />);
        // validação se a div com a class error-message contém a mensagem "Mensagem de erro"
    cy.get(".error-message").should(`have.text`, "Mensagem de erro");

        // ... Outros possíveis testes
  });
});

Para rodar o teste basta executar o seguinte comando:

$ yarn cypress run --component

ou ainda via interface

$ yarn cypress open

Testes E2E com Cypress:

Os testes E2E simulam interações do usuário em uma aplicação completa. O Cypress é uma ferramenta poderosa para isso, permitindo simular cliques, preenchimento de formulários, navegação entre páginas e mais, enquanto monitora visualmente o comportamento da aplicação.

Exemplo de teste E2E com Cypress:

describe('Teste E2E em React com Cypress', () => {
  it('Deve fazer login corretamente', () => {
    cy.visit('/login');
    cy.get('input[name="username"]').type('usuario');
    cy.get('input[name="password"]').type('senha');
    cy.get('button[type="submit"]').click();
    cy.url().should('include', '/dashboard');
// ...
// podemos continuar esse teste fazendo diversas outras assertations em /dashboard para garantir o o bom funionanmento do workflow
  });
});

Outros exemplos de testes

Vamos explorar exemplos específicos para testes mais avançados em Cypress, abordando pontos como API Mocking, Visual Regression Testing e Testes em Diferentes Dispositivos e Resoluções.

Exemplo 1: API Mocking

Suponha que você tenha um componente React que faz uma solicitação a uma API para recuperar dados. Aqui está um exemplo de como você pode usar o Cypress para simular essa chamada de API:

// cypress/integration/apiMocking.spec.js
describe('Teste E2E com API Mocking', () => {
  it('Deve simular a resposta da API', () => {
    cy.intercept('GET', '/api/data', { fixture: 'data.json' }).as('getData');
    cy.visit('/dashboard');
    cy.wait('@getData').its('response.statusCode').should('eq', 200);
    cy.get('.data-item').should('have.length', 5);
  });
});

Neste exemplo, o cy.intercept é usado para interceptar a chamada de API e fornecer uma resposta simulada a partir de um arquivo de fixture.

Exemplo 2: Visual Regression Testing

O Cypress suporta visual regression testing usando a biblioteca cypress-plugin-snapshots. Aqui está um exemplo básico:

// cypress/integration/visualRegression.spec.js
describe('Teste de Regressão Visual', () => {
  it('Deve garantir a consistência visual', () => {
    cy.visit('/dashboard');
    cy.matchImageSnapshot();
  });
});

No exemplo acima, cy.matchImageSnapshot() tira um print da página e a compara com uma referência anterior, alertando sobre qualquer diferença visual.

Exemplo 3: Testes em Diferentes Dispositivos e Resoluções

Cypress permite a simulação de diferentes dispositivos e resoluções. Veja um exemplo:

// cypress/integration/responsiveTesting.spec.js
describe('Teste de Responsividade', () => {
  it('Deve garantir layout responsivo', () => {
    cy.viewport('iphone-6');
    cy.get('.mobile-menu').should('be.visible');

    cy.viewport('macbook-15');
    cy.get('.desktop-menu').should('be.visible');
  });
});

No exemplo acima, cy.viewport é usado para simular diferentes tamanhos de tela e garantir que os elementos responsivos estejam visíveis conforme o esperado.

Estes são exemplos básicos, e a complexidade pode aumentar com a necessidade do seu projeto. Lembre-se de ajustar conforme necessário para atender aos requisitos específicos da sua aplicação.

Benefícios de Testes Abordados

Os principais benefícios dos testes incluem Garantia de Qualidade, Detecção Precoce de Problemas e Facilidade de Manutenção. A Garantia de Qualidade é assegurada através dos testes de componentes que verificam a funcionalidade individual de partes da aplicação. A Detecção Precoce de Problemas é obtida através dos testes E2E que identificam falhas em fluxos reais de usuário, permitindo a identificação e correção de problemas antes do lançamento. Por último, a Facilidade de Manutenção é conseguida por meio de testes automatizados que diminuem a necessidade de testes manuais repetitivos, permitindo uma maior precisão e eficiência.

A Garantia de Qualidade é um dos principais benefícios de realizar testes. Especificamente, os testes de componentes ajudam a assegurar que as partes individuais da aplicação funcionem corretamente. Isso é vital porque cada componente de uma aplicação é como um tijolo na construção de uma casa - se um tijolo é fraco ou defeituoso, pode comprometer a estrutura inteira. Portanto, garantir que cada componente funcione corretamente contribui para a construção de um produto final mais robusto e de alta qualidade, o que, por sua vez, traduz-se em uma melhor experiência para o usuário.

Outro benefício importante é a Detecção Precoce de Problemas. Aqui, os testes E2E desempenham um papel crucial. E2E, ou End-to-End, refere-se a testes que verificam o fluxo de uma aplicação, desde o início até o final. Estes testes identificam falhas em fluxos de usuário reais, permitindo que os desenvolvedores detectem e corrijam problemas antes do lançamento. Isso é extremamente valioso porque, sem esses testes, problemas podem passar despercebidos até o lançamento do produto, quando são mais difíceis e custosos de corrigir. A detecção precoce de problemas, portanto, evita problemas futuros e melhora a experiência do usuário.

Por último, mas não menos importante, os testes automatizados proporcionam Facilidade de Manutenção. Eles reduzem a necessidade de testes manuais repetitivos, o que não só economiza tempo, mas também garante uma maior precisão dos testes. Isso ocorre porque os testes manuais são propensos a erros humanos, enquanto os testes automatizados realizam as mesmas operações da mesma maneira todas as vezes. Além disso, os testes automatizados podem ser executados a qualquer momento, o que significa que os desenvolvedores podem verificar a qualidade do código constantemente, tornando a manutenção do código mais eficiente.

Conclusão

Investir em testes de componentes e E2E para aplicações React é crucial para o sucesso do desenvolvimento. O uso de ferramentas como Jest para testes de componentes e Cypress para testes E2E pode melhorar significativamente a qualidade e confiabilidade das aplicações, proporcionando uma experiência consistente para os usuários finais.

Este artigo oferece apenas uma visão geral, mas a prática constante e a adaptação às necessidades específicas do projeto são essenciais para garantir a eficácia dos testes em sua aplicação React.

Referências

Visual Testing | Cypress Documentation

Introduction to Cypress | Cypress Documentation

React Component Testing | Cypress Documentation

Repositório de pesquisa | GitHub