Artigos on Gilberto | GibaTech

NATS.io: Mensageria Simples e Rápida com Spring Boot

Fri, 27 Jun 2025 13:00:00 +0000

🟢 Como utilizar NATS no Spring Boot

Este guia mostra como criar um projeto de exemplo para publicar e consumir mensagens usando NATS como broker de mensagens, utilizando Spring Boot.

🛠️ Criação do Projeto

Crie um novo projeto Spring Boot com as dependências básicas:

🌐 Spring Boot Starter Web
✉️ NATS (biblioteca Java)
🧪 Datafaker (para geração de dados de exemplo)

No build.gradle:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'io.nats:jnats:2.19.0'
    implementation 'net.datafaker:datafaker:2.2.2'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

🐳 Configuração do NATS

Adicione um arquivo docker-compose.yml para subir o NATS localmente:

version: '3.8'
services:
  nats:
    image: nats:2.10
    ports:
      - "4222:4222"

Inicie o NATS com:

`1`	`docker compose up -d`

⚙️ Configuração de Host e Porta

No seu código Java, configure o host e a porta do NATS (por padrão, localhost:4222):

1
2

String natsUrl = "nats://localhost:4222";
Connection natsConnection = Nats.connect(natsUrl);

📤 Publicando Mensagens

Exemplo de publicação de mensagem:

import io.nats.client.Connection;
import io.nats.client.Nats;

public void publishMessage(String subject, String message) throws Exception {
    try (Connection nc = Nats.connect("nats://localhost:4222")) {
        nc.publish(subject, message.getBytes(StandardCharsets.UTF_8));
    }
}

📥 Consumindo Mensagens

Exemplo de assinatura de mensagens:

import io.nats.client.Connection;
import io.nats.client.Dispatcher;
import io.nats.client.Nats;

public void subscribe(String subject) throws Exception {
    Connection nc = Nats.connect("nats://localhost:4222");
    Dispatcher d = nc.createDispatcher((msg) -> {
        System.out.println("Recebido: " + new String(msg.getData(), StandardCharsets.UTF_8));
    });
    d.subscribe(subject);
}

🧩 Integração com Spring Boot

Você pode criar um @Service para publicar e consumir mensagens, injetando as dependências conforme necessário.

🚀 Testando

Execute a aplicação Spring Boot:

`1`	`./gradlew bootRun`

Dispare requisições para publicar ou consumir mensagens conforme sua API REST.

🎯 Projeto Demo no GitHub

Confira um exemplo completo e funcional de integração Spring Boot + NATS no repositório:

👉 Projeto Demo no GitHub

Para mais detalhes, consulte a documentação oficial do NATS Java.

Padrão CQRS

Wed, 01 Jan 2025 00:00:00 +0000

O que é

O padrão CQRS (Command Query Responsibility Segregation) é uma abordagem arquitetural que separa as operações de leitura e gravação em um sistema, permitindo a otimização independente de cada aspecto. Este modelo, introduzido por Greg Young, visa melhorar o desempenho, a escalabilidade e a manutenção de aplicações complexas.

Separação conceitual

No modelo tradicional (CRUD), usamos o mesmo modelo de entidade para ler e escrever:

// Modelo único — usado tanto para leitura quanto para escrita
@Entity
public class Cliente {
    @Id private Long id;
    private String nome;
    private String email;
    private String telefone;
    private LocalDate dataCadastro;
    // 10+ campos...
}

No CQRS, separamos em dois modelos distintos:

// COMMAND — usado apenas para escrever
public class CriarClienteCommand {
    private String nome;
    private String email;
    private String telefone;
}

// QUERY — modelo otimizado para leitura (pode ser uma projeção)
public class ClienteResumoDTO {
    private Long id;
    private String nome;
    // apenas os campos necessários para a view
}

Exemplo prático com Spring

// Command (escrita)
@Service
public class ClienteCommandHandler {
    @Autowired
    private ClienteRepository repository;

    public void handle(CriarClienteCommand cmd) {
        var cliente = new Cliente(cmd.nome(), cmd.email(), cmd.telefone());
        repository.save(cliente);
    }
}

// Query (leitura) — pode usar uma projeção JPA
public interface ClienteQueryRepository extends JpaRepository<Cliente, Long> {
    // Projeção fechada — busca apenas os campos necessários
    <T> List<T> findByOrderByNome(Class<T> projection);
}

Cenários onde aplicar o CQRS

O padrão CQRS é uma abordagem arquitetural que pode trazer benefícios em cenários específicos e agregar complexidade em outros. Em geral ele traz benefícios em Sistemas de Alta Performance, pois permite otimizar o fluxo de leitura e escrita da melhor forma, inclusive a nível de banco de dados.

Não há uma única forma de aplicar ou biblioteca mágica que irá abstrair toda a complexidade. Optar por CQRS irá exigir uma correta modelagem tanto do cenário de leitura quanto de escrita e a revisão contínua dessa abordagem. Este padrão não exige aplicação em todos os domínios, então pode ser aplicado nos pontos que mais irão render benefícios, como performance ou organização da arquitetura.

Conclusão

O CQRS é um padrão poderoso para cenários onde leitura e escrita têm requisitos significativamente diferentes. Não é recomendado para CRUDs simples — a complexidade adicional só se justifica quando há ganhos reais de performance, escalabilidade ou organização.

Aprofunde seus conhecimentos:

Se você chegou até aqui e ficou curioso com este padrão, recomendo estes artigos que irão agregar mais conhecimento para que você possa de fato aplicar os conceitos:

Apache Kafka: Ferramenta de mensageria de alta volumetria

Mon, 10 Jun 2024 12:00:00 -0300

🧐 O que é? Qual o uso?

O Apache Kafka é uma plataforma de mensageria distribuída, open source, projetada para alta capacidade de envio e processamento de mensagens. Possui alta tolerância a falhas e é utilizada por grandes empresas que enfrentam desafios com grandes volumes de dados.

Conceitos Fundamentais

Antes de começar, é importante entender alguns conceitos básicos do Kafka:

Tópico: Categoria ou canal para onde as mensagens são publicadas
Partição: Divisão de um tópico que permite paralelismo e escalabilidade
Producer: Aplicação que publica mensagens em um tópico
Consumer: Aplicação que consome mensagens de um tópico
Consumer Group: Grupo de consumidores que trabalham juntos para consumir mensagens de um tópico, permitindo balanceamento de carga e tolerância a falhas
Offset: Posição de uma mensagem dentro de uma partição
Broker: Servidor Kafka que armazena e serve dados

Kafka vs Filas Tradicionais

Característica	Filas Tradicionais	Apache Kafka
Persistência	Temporária	Persistente
Escalabilidade	Limitada	Alta (horizontal)
Throughput	Baixo/Médio	Alto
Ordem	Garantida por fila	Garantida por partição
Replay	Não suportado	Suportado (via offsets)

Casos de Uso Típicos

Event sourcing: Captura de eventos para reconstrução do estado
Streaming em tempo real: Processamento contínuo de dados
Log aggregation: Centralização de logs de múltiplos serviços
Mensageria entre microservices: Comunicação assíncrona e desacoplada
Pipeline de dados: ETL e processamento de dados em batch

🛠️ Exemplo: Criando uma aplicação Spring Boot com Spring Kafka

Veja um passo a passo básico para criar uma aplicação simples usando Spring Boot e Spring Kafka:

1️⃣ Adicione as dependências no `build.gradle`:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    implementation 'org.springframework.kafka:spring-kafka'
    implementation 'com.fasterxml.jackson.core:jackson-databind'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

2️⃣ Configure o Kafka no `application.yml`:

spring:
  kafka:
    bootstrap-servers: localhost:9092
    consumer:
      group-id: exemplo-grupo
      auto-offset-reset: earliest
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      enable-auto-commit: false
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
      acks: all
      retries: 3

Explicação das propriedades:

bootstrap-servers: Endereço do(s) servidor(es) Kafka a serem conectados
consumer.group-id: Identifica o grupo de consumidores (permite balanceamento de carga)
consumer.auto-offset-reset: Define o que fazer se não houver offset salvo:
- earliest: Começa do início do tópico
- latest: Começa das mensagens mais recentes
- none: Lança exceção se não houver offset salvo
consumer.key-deserializer e consumer.value-deserializer: Classes responsáveis por transformar os bytes recebidos em objetos Java
producer.key-serializer e producer.value-serializer: Classes responsáveis por transformar objetos Java em bytes para envio
consumer.enable-auto-commit: Desabilita auto-commit para processamento atômico
producer.acks: all garante que a mensagem foi replicada para todos os brokers
producer.retries: Número de tentativas em caso de falha

3️⃣ Exemplo de Producer (publicador):

// ProducerService.java
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.stereotype.Service;

@Service
public class ProducerService {
    private static final Logger logger = LoggerFactory.getLogger(ProducerService.class);
    
    @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;

    public void sendMessage(String topic, String message) {
        kafkaTemplate.send(topic, message)
            .addCallback(
                result -> logger.info("Mensagem enviada para o tópico {}: {}", topic, message),
                failure -> logger.error("Falha ao enviar mensagem para o tópico {}", topic, failure)
            );
    }
}

Este é um exemplo de Produtor, que envia mensagens para um tópico Kafka. O KafkaTemplate é usado para enviar mensagens de forma assíncrona. O callback permite lidar com sucesso e falhas de forma robusta.

4️⃣ Exemplo de Consumer (assinante):

// ConsumerService.java
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.kafka.support.Acknowledgment;
import org.springframework.kafka.support.KafkaHeaders;
import org.springframework.messaging.handler.annotation.Header;
import org.springframework.messaging.handler.annotation.Payload;
import org.springframework.stereotype.Service;

@Service
public class ConsumerService {
    private static final Logger logger = LoggerFactory.getLogger(ConsumerService.class);

    @KafkaListener(topics = "meu-topico", groupId = "exemplo-grupo")
    public void listen(
            @Payload String message,
            @Header(KafkaHeaders.RECEIVED_TOPIC) String topic,
            @Header(KafkaHeaders.RECEIVED_PARTITION) int partition,
            @Header(KafkaHeaders.OFFSET) long offset,
            Acknowledgment acknowledgment
    ) {
        try {
            logger.info("Mensagem recebida | Tópico: {} | Partição: {} | Offset: {} | Conteúdo: {}",
                topic, partition, offset, message);
            
            // Processar a mensagem aqui
            
            // Confirma o processamento da mensagem
            acknowledgment.acknowledge();
        } catch (Exception e) {
            logger.error("Erro ao processar mensagem", e);
            // Em produção, você pode optar por não fazer acknowledge
            // para que a mensagem seja reprocessada
        }
    }
}

Este é um exemplo de Consumidor, que escuta mensagens de um tópico específico. O método listen será chamado sempre que uma nova mensagem for recebida. O uso de Acknowledgment permite controle fino sobre quando a mensagem é considerada processada.

🐳 Rodando Kafka com Docker

Para rodar o Kafka localmente, você pode usar o Docker. Lembre-se de iniciar o Kafka localmente antes de rodar a aplicação.

Opção 1: Usando docker-compose

Crie o arquivo docker-compose.yml na raiz do projeto:

version: '3.8'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:7.5.0
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
    ports:
      - "2181:2181"

  kafka:
    image: confluentinc/cp-kafka:7.5.0
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_AUTO_CREATE_TOPICS_ENABLE: 'true'

Inicie os serviços com:

`1`	`docker-compose up -d`

Opção 2: Comandos Docker diretos

# Iniciar Zookeeper
docker run -d --name zookeeper -p 2181:2181 confluentinc/cp-zookeeper:7.5.0

# Iniciar Kafka
docker run -d --name kafka -p 9092:9092 \
  -e KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181 \
  -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 \
  -e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR:1 \
  --link zookeeper:zookeeper \
  confluentinc/cp-kafka:7.5.0

Validar funcionamento

# Listar tópicos
docker exec kafka kafka-topics --list --bootstrap-server localhost:9092

# Criar um tópico manualmente
docker exec kafka kafka-topics --create --topic meu-topico --bootstrap-server localhost:9092 --partitions 3 --replication-factor 1

# Listar configurações do tópico
docker exec kafka kafka-topics --describe --topic meu-topico --bootstrap-server localhost:9092

# Ver mensagens em um tópico
docker exec kafka kafka-console-consumer --topic meu-topico --from-beginning --bootstrap-server localhost:9092

Parar os serviços

# Se usando docker-compose
docker-compose down

# Se usando comandos diretos
docker stop kafka zookeeper
docker rm kafka zookeeper

✅ Testando a aplicação

Criar um endpoint para envio de mensagens

@RestController
@RequestMapping("/api/messages")
public class MessageController {

    @Autowired
    private ProducerService producerService;

    @PostMapping
    public ResponseEntity<String> sendMessage(@RequestBody String message) {
        producerService.sendMessage("meu-topico", message);
        return ResponseEntity.ok("Mensagem enviada com sucesso");
    }
}

Testar com curl

`1`	`curl -X POST http://localhost:8080/api/messages -H "Content-Type: application/json" -d "Olá Kafka!"`

Você deve ver a mensagem sendo logada pelo consumer.

🔧 Boas Práticas

Para Produtor

Use acks: all em ambientes de produção para garantir durabilidade
Configure retries para lidar com falhas transitórias
Habilite compressão para grandes volumes de dados
Use particionamento quando precisar de paralelismo
Implemente idempotência no lado do consumidor

Para Consumidor

Desabilite auto-commit (enable-auto-commit: false) para processamento atômico
Use acknowledgment explícito para confirmar processamento
Configure timeouts adequados para evitar timeouts de sessão
Monitore lags para identificar consumidores lentos
Implemente Dead Letter Queue para mensagens que não podem ser processadas

Exemplo de Dead Letter Queue

spring:
  kafka:
    consumer:
      properties:
        spring.json.trusted.packages: "*"
    listener:
      ack-mode: manual_immediate

@Service
public class ConsumerService {
    
    @KafkaListener(
        topics = "meu-topico", 
        groupId = "exemplo-grupo",
        errorHandler = "kafkaErrorHandler"
    )
    public void listen(String message, Acknowledgment acknowledgment) {
        try {
            // Processar mensagem
            acknowledgment.acknowledge();
        } catch (Exception e) {
            // Falha ao processar - não acknowledge para reprocessar
            // ou enviar para Dead Letter Queue manualmente
            throw e;
        }
    }
}

@Bean
public KafkaListenerErrorHandler kafkaErrorHandler() {
    return (message, exception) -> {
        log.error("Erro no consumer: {}", exception.getMessage());
        // Lógica de tratamento de erro
        return null;
    };
}

🔍 Troubleshooting

Problemas Comuns

Connection refused: Verifique se o Kafka está rodando e a porta está correta
Consumer não recebe mensagens: Verifique o group-id e auto-offset-reset
Offset out of range: O tópico pode ter sido recriado, considere usar earliest
SerializationException: Verifique se os serializers/deserializers correspondem

Logs úteis para debugging

logging:
  level:
    org.springframework.kafka: DEBUG
    org.apache.kafka: INFO

🔗 Mais informações

🎥 Vídeos

Para começar, vale assistir a este material do O Hipsters ponto Tube.
É um conteúdo compacto e muito interessante:

Para complementar, assista também ao vídeo do Código Fonte TV!
Ele tem 11 minutos e traz um resumo muito bem pensado sobre o Kafka:

Frontend: Comece por aqui

Thu, 03 Nov 2022 12:00:00 -0300

Se você está começando no mundo do desenvolvimento front-end e está procurando materiais, pode ficar confuso com a quantidade de nomenclaturas, tais como React, Next, Webpack, NPM, Yarn, Bootstrap e muitas outras. Realmente, há muitas tecnologias envolvidas nesse processo, mas esta página tem como objetivo esclarecer um pouco mais sobre cada uma delas.

Assim como no desenvolvimento de backend, o front-end também está se tornando cada vez mais complexo e exigente. Para criar aplicações maiores e mais poderosas, pode ser necessário utilizar várias bibliotecas e frameworks, assim como no desenvolvimento de backend.

Ferramentas de Build (Build Tool)

As ferramentas de build servem para facilitar a instalação de dependências, comandos necessários para testes, execução ou publicação, por exemplo. As soluções mais utilizadas são:

Outros exemplos apenas a título de curiosidade são o BIT, GRUNT e o GULP.

Empacotador (Module Bundler)

Além do processos de build em si, há algumas ferramentas mais especializadas para as ações de build, execução e publicação, como compactar recursos (como estilos e scripts), disponibilizar recursos estáticos, além de permitir a separação da aplicação em módulos. Algumas das ferramentas utilizas:

Webpack
Vite

Outras ferramentas semelhantes: Browserify, Rollup e o Turbopack.

Comparando com o backend, no caso do mundo Java, não existe esse tipo de ferramenta pois essas ações normalmente são feitas pelo próprio Build Tool (Gradle/Maven).

Frameworks/Bibliotecas de Construção de Interfaces

Somente aqui vemos ferramentas como o React aparecer. Como uma biblioteca de renderização de componentes para a web, ele funciona integrado ao código de forma a permitir a criação e renderização de páginas e partes da página de forma dinâmica e componentizada. Ou seja, podemos ter uma aplicação com NPM+Webpack+React ou YARN+Browserify+React se assim quisermos.

Vamos ver alguns dos frameworks e bibliotecas mais conhecidos:

Você também pode desenvolver utilizando apenas JavaScript (chamado de VanilaJS).

Outras bibliotecas e frameworks

Apenas para ajudar por onde começar, listamos alguns projetos interessantes que valem um estudo:

Componentes e plugins para criação de interfaces:

Entre outros.

Para escrita de Testes:

Ferramentas “tudo-em-um”

Há algumas ferramentas que se propôe a simplificar toda essa complexidade que é a criação e configuração dos projetos de frontend tornando a criação simples e auto-configurada.

Destacamos essas que merecem atenção:

Vite - Ferramenta moderna e rápida para criar projetos React, Vue, Svelte e outros com suporte nativo a ES modules e Hot Module Replacement.
NextJS - Framework que traz todas as funcionalidades necessárias para uma aplicação React de forma auto-configurada, tanto para renderização no navegador, como código estático, quanto para renderização no servidor, com NodeJS.
NuxtJS - Abstração que também foca em simplicidade de configuração para aplicações VueJs.

Conclusão

Espero que este material tenha te ajudado a entender um pouco mais sobre as ferramentas e siglas utilizadas no Frontend. Deixe seu comentário com sugestões ou contando sua experiência estudando Frontend :)

Outros materiais

» Buscar no Guia

» Navegar por Tópicos

Backend: Comece por aqui

Thu, 03 Nov 2022 00:00:00 +0000

O backend é a parte do sistema que trabalha em conjunto com o frontend, atuando como a “engrenagem” que executa as operações necessárias para obter, consolidar, processar e persistir informações. Toda vez que um usuário interage com o frontend, seja para obter informações ou salvar dados, o backend é acionado para executar essas tarefas.

Assim, podemos dizer que o backend é responsável pelo processamento lógico do sistema, trabalhando em conjunto com o frontend para fornecer uma experiência completa e satisfatória para o usuário. É por meio do backend que os dados são armazenados, processados e transformados em informações úteis para o usuário.

Frameworks Java

Ao falarmos especificamente sobre o desenvolvimento de backend, é importante mencionar o Java, que é uma das linguagens mais utilizadas para essa finalidade. Com o objetivo de facilitar a estruturação de projetos, configurações e integrações com outras ferramentas, é possível utilizar frameworks específicos para a linguagem.

Os frameworks de Java oferecem uma série de funcionalidades e recursos que permitem aos desenvolvedores se concentrarem nas tarefas principais do projeto, reduzindo o tempo e o esforço gastos com tarefas secundárias. Além disso, esses frameworks também ajudam a manter um padrão de desenvolvimento consistente, facilitando a manutenção e a escalabilidade do projeto.

Alguns dos frameworks mais utilizados são:

Outros frameworks e bibliotecas

Além da função primária dos frameworks, podemos ter alguns sub-frameworks e bibliotecas especializadas para realizar algumas integrações ou facilidades em nossos projetos. Por exemplo podemos citar:

Lombok - Evita códigos repetitivos como acessores, construtores e métodos.
MapStruct - Evita cópias repetitivas entre classes com atributos semelhantes.
Hibernate - Persistência em bancos relacionais.
JUnit 5 - Facilidades para execução de testes.
Mockito - Isola dependências para execução de testes unitários.
AssertJ - Torna as asserções em testes de forma fluída.

Conclusão

Espero que este material tenha te ajudado a entender um pouco mais sobre as ferramentas e siglas utilizadas no Backend. Deixe seu comentário com sugestões ou contando sua experiência estudando Java :)

Outros materiais

» Buscar no Guia

» Navegar por Tópicos

React: Conheça esse famoso Framework para Desenvolvimento Web

Fri, 29 Apr 2022 12:00:00 -0300

É uma biblioteca de renderização de componentes para a web que funciona integrado ao código de forma a permitir a criação e renderização de páginas e partes da página de forma dinâmica e componentizada.

Biblioteca ou Framework

Embora se autodenomine como uma biblioteca, podemos de certa forma considerá-lo um framework, pois ele molda a forma como que estruturamos boa parte da nossa aplicação como os componentes e páginas.

Alternativas

Algumas das alternativas ao React são o Angular, Vue.Js e Ember.Js.

Ainda, há um concorrente que promete ser semelhante e muito mais leve: o Preact. Ficou curioso? Vale experimentar.

Onde começar

Atualmente a forma mais recomendada para iniciar um projeto React é usando Vite:

npm create vite@latest meu-app -- --template react
cd meu-app
npm install
npm run dev

Outra alternativa é o Next.js (framework full-stack baseado em React):

`1`	`npx create-next-app@latest meu-app`

Você pode também seguir o React: Getting Started, que possui versão em Português. Ou ver um dos vídeos a seguir:

Playlist

https://www.youtube.com/watch?v=FXqX7oof0I4&list=PLnDvRpP8BneyVA0SZ2okm-QBojomniQVO&index=1

Vídeo

Conclusão

Espero que este material tenha te ajudado a entender um pouco mais sobre o React e o motivo de ser tão popular. Deixe seu comentário com sugestões ou contando sua experiência estudando Frontend :)

WebAssembly: A promessa de futuro do desenvolvimento Web

Fri, 08 Apr 2022 20:00:00 -0300

O que é?

WebAssembly (Wasm) é um formato binário e uma linguagem de baixo nível projetada para permitir a execução de código de alta performance na web e em outros ambientes. Ele oferece uma alternativa ao JavaScript, permitindo que os desenvolvedores escrevam código em linguagens como C++, Rust, etc., que é então compilado para WebAssembly. Ele é suportado por todos os principais navegadores e oferece vantagens como maior desempenho e acesso direto a recursos de hardware.

Características:

Eficiente e rápido:

O WebAssembly é codificado de forma eficiente em um formato binário, visando a execução nativa rápida, aproveitando as capacidades de hardware comuns.

Seguro:

O ambiente de execução do WebAssembly é protegido e isolado, garantindo segurança de memória e respeitando as políticas de segurança do navegador.

Aberto e passível de depuração:

O WebAssembly pode ser apresentado em formato textual para fins de depuração, teste, otimização e escrita manual de programas, facilitando a compreensão e a manutenção.

Parte da plataforma web aberta:

O WebAssembly foi projetado para ser integrado à web como uma extensão, permitindo chamadas entre JavaScript e WebAssembly. Além disso prevê o acesso às mesmas APIs de navegador, mantendo a compatibilidade com versões anteriores.

Especificação:

A especificação do Webassembly é composta pelos seguintes itens:

Especificação principal: define a semântica dos módulos WebAssembly independentemente de uma incorporação concreta. O núcleo do WebAssembly é especificado em um único documento. https://webassembly.github.io/spec/core/

Especificação das Interfaces:

API JavaScript: define classes e objetos JavaScript para acessar o WebAssembly de dentro do JavaScript, incluindo métodos para validação, compilação, instanciação, e classes para representar e manipular importações e exportações como objetos JavaScript. https://webassembly.github.io/spec/js-api/index.html
API Web: define extensões para a API JavaScript disponibilizadas especificamente em navegadores da web, em particular, uma interface para compilação e instanciação de streaming a partir de tipos de Resposta associados à origem. https://webassembly.github.io/spec/js-api/index.html
API WASI: define uma interface de sistema modular para executar o WebAssembly fora da web, fornecendo acesso a coisas como arquivos, conexões de rede, relógios e números aleatórios. https://github.com/WebAssembly/WASI/blob/main/Proposals.md

Convenções de ferramentas: repositório descrevendo convenções não padrão úteis para coordenar a interoperabilidade entre ferramentas que trabalham com o WebAssembly. Isso inclui convenções para esquemas de ligação, informações de depuração, ABIs de linguagem e mais. https://github.com/WebAssembly/tool-conventions

Documentos de design: documentos que descrevem o design, objetivos e visão geral de alto nível do WebAssembly. Alguns desses documentos estão desatualizados atualmente. https://github.com/WebAssembly/design

Suporte dos Navegadores:

Há um bom suporte, mas ainda existem itens pendentes em diversas implementações. Confira a lista atualizada aqui: https://webassembly.org/features/

Quais as vantagens em relação ao Javascript?

Embora ainda não esteja amplamente em uso, ele possui algumas várias vantagens que podem ser consideradas:

Desempenho: O WebAssembly é projetado para oferecer desempenho próximo ao nativo, o que significa que os aplicativos podem ser executados mais rapidamente na web, especialmente aqueles que requerem computação intensiva.
Portabilidade: O código em WebAssembly pode ser executado em uma variedade de ambientes, não apenas em navegadores web, mas também em servidores e dispositivos embarcados, aumentando a portabilidade das aplicações.
Segurança: O modelo de execução do WebAssembly é projetado para ser seguro, oferecendo um ambiente de execução isolado que protege contra ataques maliciosos.
Compatibilidade: O WebAssembly foi projetado para ser compatível com a web existente, permitindo que os aplicativos interajam facilmente com o JavaScript e a infraestrutura da web, além de suportar chamadas para e de APIs do navegador.
Ampla adoção: O WebAssembly é suportado por todos os principais navegadores, o que significa que os desenvolvedores podem contar com sua disponibilidade em uma ampla gama de plataformas.
Linguagem de programação: O WebAssembly permite que os desenvolvedores usem uma variedade de linguagens de programação, incluindo C, C++, Rust e outras, em vez de se limitarem ao JavaScript, proporcionando flexibilidade na escolha da linguagem mais adequada para cada aplicativo.

Essas vantagens fazem do WebAssembly uma opção interessante para o desenvolvimento de aplicativos web que exigem alto desempenho, portabilidade e segurança.

E desvantagens, temos?

Claro, sempre há dois lados e é importante avaliar cada uma delas quando projetar um sistema. Aqui listamos algumas das desvantagens do WebAssembly hoje:

Complexidade de desenvolvimento: O processo pode ser mais complexo devido à necessidade de lidar com ferramentas de compilação e otimização para diferentes linguagens de programação.
Debugging e Ferramentas de Desenvolvimento: Depurar e usar ferramentas de desenvolvimento pode ser mais desafiador e menos maduras do que aquelas disponíveis para JavaScript.
Tamanho dos arquivos: Arquivos WebAssembly tendem a ser maiores que equivalentes em JavaScript, resultando em tempos de carregamento mais longos.
Curva de Aprendizado: Pode haver uma curva de aprendizado para desenvolvedores que estão acostumados apenas com JavaScript.
Compatibilidade com Navegadores Antigos: Pode haver problemas de compatibilidade com versões mais antigas dos navegadores, especialmente ao utilizar recursos mais recentes do WebAssembly.

Em resumo, o WebAssembly apresenta promessas significativas, oferecendo desempenho próximo ao nativo, portabilidade e segurança para aplicativos web. No entanto, sua complexidade de desenvolvimento, desafios de compatibilidade com navegadores mais antigos e potenciais questões de tamanho de arquivo podem representar obstáculos para os desenvolvedores.

Desde 2022, o Wasm tem ganhado tração consistente: é usado em edge computing (Cloudflare Workers, Fastly), aplicações de código aberto como o SQLite e até em substituição ao Docker em alguns cenários com WASI. A adoção cresce, mas o JavaScript (e TypeScript) ainda dominam o desenvolvimento web tradicional. Wasm se consolidou como uma alternativa poderosa para cenários específicos de alta performance, não como substituto geral do ecossistema JavaScript.

Spring Data: Como realizar integrações de maneira facilitada

Tue, 22 Mar 2022 00:00:00 -0300

O Spring Data é uma abstração criada pelo Spring para interagirmos com dados, sejam de fontes relacionais ou não relacionais. Além de fornecer as operações mais comuns como listar ou salvar prontas, também provê formas práticas de personalizar consultas.

1. Recursos

Suporte a bancos relacionais (JPA) e não relacionais (MongoDB, Redis, Cassandra)
Interfaces prontas como CrudRepository, JpaRepository e PagingAndSortingRepository
Query methods derivados do nome do método
Anotações para personalização com @Query

2. Exemplo com JPA

Adicione a dependência no build.gradle:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.h2database:h2'
}

Crie a entidade e o repositório:

@Entity
public class Cliente {
    @Id @GeneratedValue
    private Long id;
    private String nome;
    private String email;
    // getters e setters omitidos (use Lombok!)
}

public interface ClienteRepository extends JpaRepository<Cliente, Long> {
    List<Cliente> findByNomeContainingIgnoreCase(String nome);
    Optional<Cliente> findByEmail(String email);
}

O Spring Data implementa automaticamente os métodos da interface. O método findByNomeContainingIgnoreCase gera a query SELECT * FROM cliente WHERE nome LIKE %:nome% sem escrever uma linha de SQL.

3. Exemplo com MongoDB

1
2
3

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-mongodb'
}

@Document
public class Produto {
    @Id
    private String id;
    private String nome;
    private BigDecimal preco;
}

public interface ProdutoRepository extends MongoRepository<Produto, String> {
    List<Produto> findByPrecoBetween(BigDecimal min, BigDecimal max);
}

Mais informações:

Spring Boot | Profiles: Como trocar configurações de acordo com o ambiente

Sun, 20 Mar 2022 00:00:00 -0300

Os Profiles ou perfis de execução de uma aplicação nos permitem diferentes configurações de acordo com o ambiente ou objetivo da execução. Por exemplo, precisamos de um banco de dados H2 localmente, com certo usuário e senha, mas em produção usamos um Postgres com outro usuário e senha. Ainda, podemos ter algum teste que usa uma terceira configuração, por exemplo, com um banco desconfigurado para simular um erro de execução.

Para estas variações de execução temos os Profiles. Esta é uma funcionalidade central do Spring e está presente tanto no SpringBoot quanto diretamente na raiz do Spring. Com ela podemos criar diferentes arquivos de configuração para nossa aplicação, e quando “executamos” podemos informar qual “profile” queremos utilizar.

Dada a explicação inicial, vamos ver como “criar” profiles e como utilizá-los:

1.Criando profiles

Cabe dizer que o nome dos profiles não são predefinidos e você pode ser criativo, mas usualmente eles são simples e alfanuméricos. Exemplos de bons nomes de profiles: “local”, “testes”, “testes-kafka”, “producao” ou mesmo “cliente345”. Dito isso, há basicamente duas formas de “definir” esses nomes de profiles:

1.1.Limitando uso de SpringBeans com Profiles

Por exemplo, supondo que temos um SpringBean (classe Java com algum stereotype) de configuração de banco Postgresql, que só queremos que seja executado em Produção. Podemos utilizar nesta classe a anotação @Profile indicando que queremos que funcione somente no profile “prod”:

@Component
@Profile("prod")
public class ConfigurePostgresConfig {
    //Método de configuração omitido...
}

Neste caso esse “SpringBean” será carregado para o contexto do Spring somente se o profile for especificamente “prod”. Ainda é possível colocar uma lista de profiles nesta anotação ou fazer lógica como “OU”, “E” ou “NEGAÇÃO” mas não abordaremos esses exemplos aqui. Olhe a documentação adicional para esses casos.

1.2.Diferenciando configurações com Profiles

No caso de configurações podemos criar arquivos para cada cenário, e eles podem ser no formato “properties” ou “yaml”. Porém, não basta criarmos o arquivo, ele deve seguir um padrão:

application-{nomeprofile}.{properties ou yml}

Exemplos de nomes válidos: application-prod.yaml, application-local.properties, application-teste-integrado.yaml. Nestes casos os profiles são “prod”, “local” e “teste-integrado” respectivamente.

OBS:

Ainda há o arquivo “application.yaml” ou “application.properties” considerado o profile padrão (default).
A extensão “yaml” também pode ser escrita apenas “yml”.
Com algumas configurações no projeto o prefixo “application” pode ser substituído por “bootstrap”. Neste caso, por exemplo podemos ter um arquivo “bootstrap-local.yml” também válido.

2.Utilizando profiles

Para fazermos nossa aplicação ler e utilizar um destes arquivos de configuração, ou mesmo considerar o profile para descartar um “SpringBean” da configuração temos de indicar qual (ou quais) profiles queremos utilizar na inicialização da aplicação. Podemos fazer isso de algumas formas:

2.1.Através do application.yml/application.properties

Esses arquivos, por serem o “profile padrão” SEMPRE são lidos, então dentro deles podemos declarar uma propriedade “spring.profiles.active” indicando qual profile também deve ser considerado. Exemplo:

arquivo application.properties (profile padrão):

`1`	`spring.profiles.active=local`

arquivo application-local.properties (profile local):

`1`	`logging.level.root=debug`

2.2.Através de variável de ambiente

Podemos definir uma variável tanto na nossa IDE quanto no próprio sistema operacional denominada “SPRING_PROFILES_ACTIVE”. Por exemplo, no linux, ao configurarmos através de export SPRING_PROFILES_ACTIVE=dev estamos exportando no bash uma variável ativando o profile “dev”.

2.3.Através de parâmetros de execução

Podemos ainda definir um parâmetro “spring.profiles.active”. Os parâmetros de JVM normalmente são passados utilizando “-D”, então no caso ficaria: -Dspring.profiles.active=dev para ativar o profile “dev”.

Ainda é possível fixar essa variável “spring.profiles.active” programaticamente no Java, como propriedade de projetos Maven ou Gradle. Em todos os casos irá funcionar, resta escolher a melhor forma de configurar essa propriedade.

Materiais em vídeo:

Fizemos uma seleção dentre os vídeos para ajudá-lo a entender mais sobre o assunto:

Mais informações:

Seguem materiais adicionais, lembrando que sempre a documentação oficial é a melhor fonte, seguido de outros sites e fóruns:

Lombok: menos código repetitivo e mais foco nas regras de negócio

Mon, 03 Jan 2022 12:00:00 -0300

O que é? Qual o uso?

A ideia deste projeto é reduzir a quantidade de código repetitivo que escrevemos no Java. Métodos de leitura e escrita de campos (getters/setters), construtores com ou sem argumentos, tudo se resume a anotações com o Lombok! Poderia ficar melhor? Sim, ele consegue criar até classes de Builders com a mesma facilidade.

Exemplos de uso

Adicione a dependência no build.gradle:

dependencies {
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
}

@Data — gera getters, setters, toString, equals e hashCode

import lombok.Data;

@Data
public class Usuario {
    private Long id;
    private String nome;
    private String email;
}

O código acima equivale a aproximadamente 50 linhas de getters, setters, toString, equals e hashCode.

@AllArgsConstructor e @NoArgsConstructor

import lombok.AllArgsConstructor;
import lombok.NoArgsConstructor;
import lombok.Data;

@Data
@AllArgsConstructor
@NoArgsConstructor
public class Produto {
    private Long id;
    private String nome;
    private BigDecimal preco;
}

@Builder — padrão Builder automaticamente

import lombok.Builder;
import lombok.Data;

@Data
@Builder
public class Pedido {
    private Long id;
    private String cliente;
    private List<Item> itens;
}

// Uso:
Pedido pedido = Pedido.builder()
    .cliente("João")
    .itens(List.of(item1, item2))
    .build();

Dá uma olhada nesse vídeo pra conferir:

Vídeos

O Felipe Públio tem um material interessante sobre o tema:

Mais informações:

https://projectlombok.org/

AssertJ: Asserções de testes de forma fluída

Wed, 25 Aug 2021 12:00:00 -0300

Asserções de forma fluída para o Java.

Para que serve

AssertJ é uma biblioteca Java que fornece um conjunto rico de asserções e mensagens de erro verdadeiramente úteis, melhora a legibilidade do código de teste e é projetada para ser fácil de usar em seu IDE favorito.

Funcionalidades

Asserções com recursos do Java 8
Mensagens de erro descritivas
Conjuntos de asserções (SoftAssertions)

Iniciando uma asserção

1
2

.assertThat(resultado)              // Tudo inicia a partir do assertThat()
    .isEqualTo(esperado)            // seguido dos método que olharemos

Asserções para itens individuais

1
2
3

.assertThat(resultado)
    .as("Nome: %s", nome)   // Mensagem descritiva em caso de falha.
    .isEqualTo(algo)        // Equals clássico

Asserções para coleções ou arrays

.assertThat(colecao)
    .filteredOn(predicate, lambda ou field)   // Filtra os itens
    .containsOnly(item...)                    // Exatamente os itens existentes
    .contains(item...)                        // Um ou mais itens que devem existir
    .doesNotContain(item...)                  // Um ou mais itens que não devem existir
    .extracting(lambda ou field)              // Extrai campo(s) dos itens do array
    .flatExtracting(lambda ou field)          // Extrai campo(s) do tipo lista de cada item do array

Testando uma exceção

.assertThatThrownBy(() -> acao())           // Ação que dispara uma exceção
    .isInstanceOf(Exception.class)          // Valida o tipo da exceção
    .hasMessageContaining("Erro X")         // Valida a mensagem
    
//ou
assertThatExceptionOfType(Exception.class)  // Valida o tipo da exceção
    .isThrownBy()                           // Ação que dispara uma exceção
    .withMessage("%s!", "Erro X")           // Valida a mensagem
    .withMessageContaining("Erro X")        // Ou parte da mensagem

Notas curiosas

Além do Core, o AssertJ possui módulos extras para Guava, Joda, Neo4J, Databases e Swing.
Você pode encadear um conjunto de assertions com o SoftAssertions coletando todos os erros ao mesmo tempo em vez de parar em cada Asserção individual.
Você pode fazer asserção com o conteúdo de um arquivo utilizando assertThat(contentOf(arquivo)).

Mais informações:

https://assertj.github.io/doc/

Spring Boot: O que é este Framework para Desenvolvimento Java

Wed, 25 Aug 2021 12:00:00 -0300

O Spring Boot é um dos frameworks Java mais estabelecidos, criado para simplificar a configuração e o desenvolvimento de aplicações Spring. Ele oferece dependências pré-configuradas (starters), servidor web embutido (Tomcat, Jetty) e reduz significativamente a configuração de infraestrutura.

Exemplo mínimo

Uma aplicação REST funcional com Spring Boot requer apenas uma classe:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class MinhaAplicacao {
    public static void main(String[] args) {
        SpringApplication.run(MinhaAplicacao.class, args);
    }

    @GetMapping("/")
    public String ola() {
        return "Olá, mundo!";
    }
}

Basta adicionar a dependência spring-boot-starter-web no build.gradle:

1
2
3

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

E a aplicação já sobe com servidor Tomcat embutido na porta 8080.

Recursos:

Vídeo:

Para conhecer melhor suas funcionalidades, esse vídeo da Alga Works explica bem para os fundamentos:

Conclusão

O Spring Boot é atualmente a forma mais produtiva de desenvolver aplicações Java para a web, eliminando grande parte da configuração manual e permitindo foco nas regras de negócio. Se você está começando com Java, comece pelo Spring Boot.

Mais informações:

Padrão REST: Entenda esse estilo arquitetural e aplique no seu projeto

Fri, 20 Aug 2021 00:00:00 +0000

Sobre o REST

Antes de tudo precisamos entender que o REST (Representational state transfer) não é uma ferramenta, biblioteca nem mesmo um protocolo de comunicação.

Na verdade ele é um estilo arquitetural utilizado para comunicação entre sistemas. Com outras palavras, podemos dizer que é um conjunto de princípios e definições que definem uma forma padronizada para realizar essa comunicação.

Conceitos importantes

Ele é fortemente ancorado pelo protocolo HTTP, fazendo uso padronizado de URLs, verbos, status, cabeçalhos e tudo mais que o HTTP nos fornece.
Embora seja mais comum a utilização do formato JSON, ele não é uma restrição do REST, podendo ser utilizado XML, HTML, imagem, texto, etc.
Se trata de uma comunicação Cliente-Servidor. Isso quer dizer que de um lado o Servidor se comporta como provedor do serviço, continuamente disponibilizando o serviço a ser acessado. Já no outro lado, podemos ter 0, 1 ou vários Clientes conectando por demanda sempre que precisarem acessar algum dos recursos disponibilizados pelo Servidor.

O HTTP

Métodos (ou Verbos) HTTP:

Cada método possui uma finalidade específica que deve ser respeitada para deixar claro aos clientes qual o efeito esperado. Os métodos mais utilizados são:

GET: usado para busca de informações. Não deve alterar dados no servidor.
POST: usado para criação de recursos no servidor.
DELETE: usado para remoção de recursos existentes no servidor.
PUT: usado para substituição de recursos previamente criados no servidor.
PATCH: usado para atualização parcial de recursos previamente criados no servidor.

Status de retorno:

Da mesma forma que os métodos. Os status code existentes no HTTP são utilizados. Os status mais utilizados são:

Status de sucesso:

Ou seja, a operação foi realizada:

200: acompanhada de retorno de informações.
204: sem informações de retorno.
201: com a criação de informações.
202: de forma assíncrona, ou seja, foi recebida para processamento.

Status de erro de cliente:

Ou seja, a operação não foi realizada, e a responsabilidade provavelmente é do cliente:

400: e o motivo provavelmente está no corpo da requisição.
404: pois a informação solicitada não existe.
422: pois houve falha em uma validação de negócio.
401: por falta de autenticação.
403: por falta de permissão.

Status de erro de servidor:

Ou seja, a operação não foi realizada, e a responsabilidade provavelmente é do servidor:

500: e o motivo provavelmente está no retorno da requisição.
503: pois o serviço está indisponível.
502: pois um serviço necessário está retornando algo inesperado.
504: pois um serviço necessário está demorando para responder.

Exemplo prático

Uma requisição REST para gerenciar usuários:

### Listar usuários
GET /api/usuarios
Accept: application/json

### Criar um usuário
POST /api/usuarios
Content-Type: application/json

{
    "nome": "João Silva",
    "email": "joao@email.com"
}

### Resposta esperada (201 Created)
HTTP/1.1 201 Created
Location: /api/usuarios/1
Content-Type: application/json

{
    "id": 1,
    "nome": "João Silva",
    "email": "joao@email.com"
}

### Buscar usuário específico
GET /api/usuarios/1
Accept: application/json

### Resposta esperada (200 OK)
HTTP/1.1 200 OK
Content-Type: application/json

{
    "id": 1,
    "nome": "João Silva",
    "email": "joao@email.com"
}

### Remover usuário
DELETE /api/usuarios/1

### Resposta esperada (204 No Content)
HTTP/1.1 204 No Content

Conclusão

REST é o estilo arquitetural dominante para APIs web. Seguir seus princípios — uso correto dos verbos HTTP, statelessness, recursos bem definidos — garante APIs previsíveis, testáveis e de fácil manutenção.

Mais informações:

Gosta de vídeo?

REST // Dicionário do Programador - Código Fonte TV:

O QUE É UMA API RESTful NA PRÁTICA? MATURIDADE DE RICHARDSON - Michelli Brito:

Criando sistemas legados com o framework da moda

Sun, 22 Nov 2020 00:00:00 +0000

Não é um assunto necessariamente recente, porém restam controvérsias e, sem dúvidas, ainda cabe uma opinião.

Legados não são ruins. Ruins são as gambiarras, a ausência de testes e de boas práticas de desenvolvimento. Colocar a mesma equipe que desastrosamente sustenta um legado para criar uma nova API fresquinha, com o último framework da moda é potencializar as chances de criação de código ruim, frequentemente chamado de legado.

Também incorro no erro de chamar de construção de novos legados quando vejo códigos escritos de qualquer forma. Mas é força do hábito. Muitas vezes pensei que a solução para melhorar um software era reescrevê-lo, não por convicção própria, pois muitas vezes o CTO da empresa ou o arquiteto induziram a equipe a pensar desta forma. Fato é que essa abordagem nunca resolveu o problema inicial. Meses após o início das migrações sempre parece haver um “novo legado”.

E o que acontece ao tentar escrever um novo software com os mesmos vícios de programação? Temos dois softwares ruins para manter, com a mesma equipe que já não aguenta manter o legado. Óbvio que é tentador explorar novos frameworks e linguagens. E o ganho de velocidade realmente surpreende nas primeiras Sprints pois, obviamente, ainda não está uma bagunça completa: ela vem com o tempo. A situação ainda é agravada com os microsserviços e com a criação de novas APIs de forma desenfreada e sem qualidade.

O problema é colocado sobre o sistema, mas na verdade deveria ser sobre a sua forma de manutenção. Não há uma atenção especial à qualidade e melhoria contínua, haja vista que o foco é criar os entregáveis e fazer as peças funcionarem a todo custo. Há uma pressão clara de entrega e isso faz parte do negócio, mas os desenvolvedores devem contrapor isso com seus pontos técnicos ao longo das Sprints.

A equipe de desenvolvimento deve continuamente levantar débitos, ajustar desvios e executar pequenas refatorações. Estas não deveriam exigir um Sprint dedicado apenas a débitos técnicos de tempos em tempos, mas sim pequenas tarefas dentro de cada Estória, melhorando continuamente o código e a arquitetura. Olhar com a visão de escoteiro, melhorando pouco a pouco cada classe alterada irá dar uma sustentabilidade muito maior ao sistema, deixando mais fácil adicionar novas features.

E se o framework ficar defasado? Inseguro? Precisar ser escalado? Bem, se o software foi bem cuidado pode ser planejada uma estratégia de migração ou fracionamento. As classes de negócio poderão ser reaproveitadas, se mantida a linguagem, mas as demais provavelmente terão de ser reescritas. Será doloroso, contudo a migração será mais curta e garante foco total em apenas uma aplicação, sem legados.

Publicado também na comunidade DEV! Vá lá e comente :)

https://dev.to/gilbertolptn/criando-sistemas-legados-com-o-framework-da-moda-5gcj

Você está organizando e nomeando seu código corretamente?

Tue, 21 Apr 2020 00:00:00 +0000

Fala-se sobre Código Limpo há algum tempo, sobre funcionalidades que melhoram a legibilidade do código e bibliotecas que agilizam e deixam o código menor e, às vezes, melhor. Mas há questões bem mais fundamentais que não podem ser esquecidas ou despriorizadas em relação àqueles assuntos mais populares, entre eles, a nomenclatura de tudo o que está sendo escrito.

Quando precisamos realizar alterações em um sistema já desenvolvido, mas desconhecido, temos a necessidade de avaliar, como um todo, quais são suas funcionalidades. Certas vezes nem mesmo é desconhecido, mas trabalhado há alguns meses e com detalhes específicos de arquitetura para relembrar. Esse sistema provavelmente está em produção e quebrar algo em funcionamento não é uma possibilidade.

Num primeiro momento pouco importam as bibliotecas utilizadas, a versão da linguagem ou mesmo detalhes do ambiente de execução. A primeira coisa que devemos observar no sistema para saber qual é o seu domínio de negócio são suas classes e pacotes. Depois, olhamos para seus atributos e métodos, a fim de entender os recursos que cada parte do domínio tem. Em terceiro, analisamos os testes, que irão dizer como os recursos devem se comportar. Somente após isso, pode-se passar aos detalhes da tecnologia, versões, ambientes e bibliotecas.

Guarde esta ordem:

Classes e seus pacotes
Atributos e Métodos
Testes

Numa aplicação em que não puder ser obtida uma visão geral seguindo os passos mencionados, certamente não é orientada a objetos, mesmo que use uma linguagem dita como OO. Não conhece Orientação a Objetos mas está lendo este artigo? Que bom, é um ótimo começo!

Por que os pacotes estão no primeiro item?

Os pacotes estão juntos às classes para sustentá-las. Pouco importa ter um pacote se não existir uma classe dentro deste. Porém, caso seja ignorada a sua importância, deixando as classes mal distribuídas, tornará muito difícil encontrar a sua localização. Sem falar que se o sistema crescer, irá virar uma bagunça.

Há quem considere a divisão dos pacotes a parte mais simples, afirmando que são sempre os mesmos: entidade, serviço, dao, util, rest… Outros discordarão com veemência dizendo que preferem repositorio à dao e controlador à rest. Algum deles está correto? De certa forma, sim. Esta quebra por camadas é muito utilizada, e comum para quem está começando a trabalhar com MVC. É uma abordagem sem grandes dúvidas: em pouco tempo está definida para toda a vida do projeto e o restante do tempo fica com a codificação.

Agora, trago a verdade sobre os pacotes. Essa divisão simples por camadas é como colocar uma caixa escrito “gavetas” na sua garagem e juntar todas as gavetas da casa ali dentro: gavetas da cozinha, do guarda-roupas, do armário de produtos de limpeza. Faz sentido? Claro, deixamos todas as gavetas, que possuem a mesma finalidade juntas, não é verdade? Mas na prática isso tem pouco sentido, principalmente em sistemas maiores, onde temos dezenas de classes na mesma camada. Por que faríamos diferente com o nosso software? Faz muito mais sentido deixar coisas onde realmente são utilizadas do que juntá-las no mesmo local.

Mas como seria essa organização? Seguindo o mesmo exemplo, pense nos cômodos da casa como pacotes e nos compartimentos dos cômodos como subpacotes. Dentro deles estarão as ferramentas ou utensílios, ou seja, as classes. Então:

Cozinha
- Armário
  - Gaveta
    - Talheres
  - Balcão
- Fogão
Sala
Quarto
- Guarda-roupas
  - Gaveta
    - Meias

Não achou que poderia organizar sua casa em pacotes, subpacotes e classes? Pois é. A orientação a objetos é a melhor forma pra isso, trazer abstrações do mundo real para dentro de um sistema, de forma que se alguém pedir para adicionar uma funcionalidade de “bancada” no armário da cozinha, saberemos exatamente onde criar o pacote e suas classes. Não é uma forma fácil e vai gerar muitas dúvidas, mas fica mais próximo da realidade, o que é bom para a Orientação a Objetos.

Certo… E as classes?

Pois bem, já definimos os pacotes e agora podemos pensar de fato nas classes. Utilizando a abordagem de divisão por lógica que vimos a pouco, sabemos que devemos deixar as classes relacionadas próximas. Dentre estas, as mais importantes do nosso sistema são àquelas do domínio do negócio, as quais contém características, estado e ações. Classes como Aluno, Turma, Cliente, Animal, Pagamento são exemplos disso.

Essas classes do domínio do negócio, conhecidas como modelo, também podem se tornar entidades, se forem relacionadas a um banco de dados. Eventualmente estas entidades precisam ser listadas, criadas, apagadas ou atualizadas, sendo que neste caso delegamos a uma classe de persistência, normalmente chamada de repositório ou dao. Além da própria entidade e seu repositório, ainda é comum o uso de uma classe onde as regras de negócio entre diferentes entidades são relacionadas, chamadas de serviço.

Assim, temos três classes intrinsecamente relacionadas: a Entidade, seu Repositório e seu Serviço. Com muita dificuldade conseguiremos separá-las, razão pela qual devem permanecer no mesmo pacote.

Ainda, as classes de Serviço podem vir a ficar sobrecarregadas devido à quantidade de regras e operações que algumas entidades tem. Logo, para melhorar a manutenção deste código, devem ser decompostas em classes específicas, reduzindo a complexidade e organizando as responsabilidades. Por exemplo, em um sistema de Petshop, poderíamos ter um pacote animal, com as classes Animal, AnimalRepositorio, AnimalService, AnimalAlimentacaoServicoe AnimalSaudeServico. Isso, considerando que a “alimentação” e “saúde” dos animais possuem muitas regras que justifiquem a divisão. O uso da nomenclatura em inglês também é comum, contudo não é relevante para este artigo, desde que você adote um padrão: service e repository.

Só estas classes compõe uma aplicação?

De fato não conseguimos fazer todo o necessário somente com estas classes, pois nossos modelos quase sempre precisam conversar com o mundo externo. Para isso, serão necessários Controllers, Clientes de APIs, Filas, etc. Essas classes fazem parte de uma aplicação, mas não são parte do “negócio”, então considere separar esses recursos tecnológicos em algum pacote específico como api, infra, cliente, etc…

Além disso, precisamos de utilitários que nos ajudam a manter a abstração dentro de nossos modelos, e também são aceitos. Eles normalmente são conhecidos como Builders, Factories, Converters, Mappers, etc. Mas pense que o objetivo destes é simplificar a lógica das classes de negócio, apenas isso.

Ok, organizamos nosso negócio em pacotes e classes, mas onde de fato ficam nossas regras e informações?

Nesse momento entram os atributos de nossas classes para armazenar as informações, características e estado. E os métodos para realizar as ações, mudanças de estado e validações. Da mesma forma que os pacotes e classes devem ser precisamente pensados para dar sentido à nossa organização.

Os atributos devem parecer com características ou estado. Devem fazer sentido para o negócio e não conter prefixos ou sufixos tecnológicos que não ajudam na abstração. Ou seja, prefira “tamanho” à “nroTamanho”, por exemplo.

Quanto aos métodos, também devem parecer ações do negócio e mudança de estado e, ainda, evitar prefixos e sufixos que não auxiliam na compreensão do negócio. Caso sejam necessárias conversões, cópia de objetos ou quaisquer outras ações que não fazem parte do comportamento natural do negócio, considere criar as classes que citamos anteriormente, como Converters, Mappers, Builders, Factories…

Testes?!

Bem, como último dentre os itens citados, mas não menos relevante, temos os testes. Sua posição deve-se unicamente pela ordem natural de entender a visão geral da arquitetura, o contexto de cada uma das funcionalidades e aí sim adentrar nos detalhes da implementação.

Chegada esta etapa podemos interpretar de fato o que o sistema poderia e deveria fazer, e os testes são bons para nos contar isso: além dos cenários principais os testes nos mostram os secundários e os de exceção, com a reação prevista do software quando nem tudo sai conforme gostaríamos. Esse tipo de informação é difícil de extrair de alguns códigos de produção ou implícitos em outros, mas os testes tendem a deixá-los explícitos, o que facilita o trabalho de manutenção.

Encerra-se por aqui a discussão? Com certeza não! Existem diversas abordagens de organização e arquitetura. Aqui trago uma visão subjetiva do que considero importante após alguns anos de programação, objetivando que seja dada maior ênfase à abstração do negócio, que é o motivador para a criação dos sistemas, em vez da tecnologia, bibliotecas e termos que afastam o propósito real do código.

Também não foi o objetivo falar especificamente sobre uma ou outra arquitetura, mas há muito material disponível. Se você ficou motivado, considere pesquisar sobre DDD e Arquitetura Hexagonal.

Cloud: Comandos úteis para Google Cloud Storage

Sun, 12 Apr 2020 00:00:00 +0000

Sincronizar arquivos

`1`	`gsutil -m rsync -R public gs://meu-bucket`

Sincroniza o diretório public com um bucket do GCS de forma recursiva e paralela (-m).

Configurar página web

`1`	`gsutil web set -m index.html -e 404.html gs://meu-bucket`

Define index.html como página principal e 404.html para erros de página não encontrada.

Permissão de leitura pública

`1`	`gsutil defacl ch -u allUsers:READER gs://meu-bucket`

Define a ACL padrão do bucket para permitir leitura pública.

`1`	`gsutil -m acl ch -r -u AllUsers:R gs://meu-bucket`

Aplica a permissão de leitura pública recursivamente a todos os objetos do bucket.

Linux: Comandos úteis de rede

Sun, 12 Apr 2020 00:00:00 +0000

Este é um guia de comando úteis para utilização em ambiente Linux. São basicamente minhas notas de aula utilizadas durante os treinamentos que ministrava, mas podem ser úteis em vários contextos.

Rede

Arquivos e pastas importantes:

/etc/syconfig/network-scripts/
/etc/hosts
/etc/host.conf
/etc/resolv.conf

Comandos

dhClient: Autoconfiguração de rede. Se você estiver em uma máquina sem internet e precisar de uma configuração automática e rápida, tente este comando.
/etc/rc.d/init.d/network stop ou start: Para ou inicia um serviço de sistema. Este é específico para sistemas Linux que usam o InitD. Isto vem mudando a bastante tempo principalmente para o SystemD, e pode ser que tenha de rodar systemctl start networking.service.
route -n: Lista a tabela de roteamento de rede configurada. Da mesma forma, pode funcionar com netstat -r OU cat /proc/net/route.
dig site.com.br: Consulta o servidor DNS configurado no arquivo resolv.conf exibindo suas configurações.

Java: Ambiente de desenvolvimento

Fri, 10 Apr 2020 00:00:00 +0000

As ferramentas descritas aqui são base para o desenvolvimento Java e podem ser obtidas gratuitamente (legalmente) através dos links disponibilizados

Intellij

Link: https://www.jetbrains.com/idea/download/

Acesse a URL e faça download da versão Community para seu sistema operacional. Ele funciona da mesma forma no Linux, Mac ou Windows.

Java

Link: https://www.java.com/pt_BR/download/

Acesse a URL e faça download para seu sistema.

Há uma alternativa que pode ser utilizada sem problemas não vinculada à Oracle: O OpenJDK.

Link: https://adoptopenjdk.net/

Cliente Rest

Esta ferramenta é util caso você esteja construindo API’s Rest. Há alternativas como extensões para Chrome e Firefox mas o Postman possui mais recursos, sendo muito utilizado em ambientes corporativos.

Link: https://www.postman.com/downloads/

Outras ferramentas

Ainda, com relação ao Java, se você gosta de experimentar diferentes versões, uma alternativa para gerenciar elas facilmente é o SDKMAN. Mais detalhes neste outro artigo: Dev Tools Java

Automação de Build

Sun, 29 Mar 2020 00:00:00 +0000

Introdução

Neste tópico vamos falar sobre as ferramentas que normalmente são utilizadas em aplicações Java para tarefas rotineiras de build, como compilação, testes e cobertura, empacotamento, publicação…

As mais conhecidas ferramentas para esta finalidade são o Gradle e o Maven.

Glossário

Artefato: no contexto deste artigo, para o Java, um Artefato corresponde a uma biblioteca que é compilada a partir de outro projeto Java, resultando um arquivo de extensão JAR.
Classpath: no contexto deste artigo, para o Java, o classpath é o conjunto de recursos necessários para a execução da aplicação. Compoe esse classpath a próprias classes Java, resources, dependências (bibliotecas), etc.

Por que utilizar uma ferramenta?

Para quem está iniciando no Java, esta é uma pergunta clássica. Não basta aprender o Java, ainda tenho que aprender Maven ou Gradle? A resposta é: SIM. Não é algo que você precise se tornar especialista, mas é importante que conheça seu uso básico para não seguir caminhos complexos nos pontos que estas ferramentas resolvem com facilidade:

Gestão de dependências: O motivo principal para usar uma dessas ferramentas. Nada de baixar arquivos JAR e colocar em uma pasta LIB, ok? Basta declarar o Artefato no Maven/Gradle e deixar que ele baixe e adicione o mesmo ao Classpath.
Garantia de versionamento Todos os artefatos gerados ou dependências que nosso projeto terá serão necessariamente versionados. E uma determinada versão não deve ser regerada, gerando uma garantia que nosso código sempre utilizará a versão testada das dependências.

Gradle

O Gradle é a ferramenta de build mais moderna do ecossistema Java, usando uma DSL baseada em Groovy ou Kotlin. Arquivo de configuração: build.gradle (ou build.gradle.kts).

plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web:3.2.0'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'
}

Comandos principais:

./gradlew build — compila, roda testes e empacota
./gradlew test — executa os testes
./gradlew bootRun — executa a aplicação Spring Boot

Maven

O Maven é a ferramenta mais tradicional, usando XML para configuração. Arquivo de configuração: pom.xml.

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.exemplo</groupId>
    <artifactId>meu-app</artifactId>
    <version>1.0.0</version>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.2.0</version>
        </dependency>
    </dependencies>
</project>

Comandos principais:

mvn clean install — compila, roda testes e empacota
mvn test — executa os testes
mvn spring-boot:run — executa a aplicação Spring Boot

Conclusão

Tanto Gradle quanto Maven resolvem bem o problema de gestão de dependências e automação de build. O Gradle é mais moderno e flexível; o Maven é mais previsível e amplamente documentado. A escolha depende do seu projeto e equipe.

Ferramentas de Desenvolvimento

Tue, 25 Dec 2018 15:24:38 -0200

SDKMAN — Gerenciador de versões para ferramentas Java

Site oficial: sdkman.io

O SDKMAN permite instalar e alternar facilmente entre diferentes versões de várias ferramentas. Entre elas: Gradle, Grails, Groovy, Java, Kotlin, Maven, Scala, Spring Boot.

Instalação

1
2

curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"

Uso básico

# Listar versões disponíveis do Java
sdk list java

# Instalar uma versão específica
sdk install java 21.0.2-tem

# Alternar entre versões
sdk use java 17.0.9-tem

# Definir versão padrão
sdk default java 21.0.2-tem

Ele baixa os pacotes e configura as variáveis de ambiente automaticamente, deixando os binários no PATH para execução direta, como se fosse uma instalação no sistema principal.

Outras ferramentas úteis

Ferramenta	Uso
Gradle	Automação de build e gerenciamento de dependências
Maven	Automação de build e gerenciamento de dependências
Docker	Contêineres para ambientes isolados (banco, filas, etc.)
HTTPie	Cliente HTTP via terminal para testar APIs REST
jq	Processamento de JSON no terminal

Artigos on Gilberto | GibaTech

NATS.io: Mensageria Simples e Rápida com Spring Boot

🟢 Como utilizar NATS no Spring Boot

🛠️ Criação do Projeto

🐳 Configuração do NATS

⚙️ Configuração de Host e Porta

📤 Publicando Mensagens

📥 Consumindo Mensagens

🧩 Integração com Spring Boot

🚀 Testando

🎯 Projeto Demo no GitHub

Padrão CQRS

O que é

Separação conceitual

Exemplo prático com Spring

Cenários onde aplicar o CQRS

Conclusão

Aprofunde seus conhecimentos:

Apache Kafka: Ferramenta de mensageria de alta volumetria

🧐 O que é? Qual o uso?

Conceitos Fundamentais

Kafka vs Filas Tradicionais

Casos de Uso Típicos

🛠️ Exemplo: Criando uma aplicação Spring Boot com Spring Kafka

1️⃣ Adicione as dependências no build.gradle:

2️⃣ Configure o Kafka no application.yml:

3️⃣ Exemplo de Producer (publicador):

4️⃣ Exemplo de Consumer (assinante):

🐳 Rodando Kafka com Docker

Opção 1: Usando docker-compose

Opção 2: Comandos Docker diretos

Validar funcionamento

Parar os serviços

✅ Testando a aplicação

Criar um endpoint para envio de mensagens

Testar com curl

🔧 Boas Práticas

Para Produtor

Para Consumidor

Exemplo de Dead Letter Queue

🔍 Troubleshooting

Problemas Comuns

Logs úteis para debugging

🔗 Mais informações

🎥 Vídeos

Frontend: Comece por aqui

Ferramentas de Build (Build Tool)

Empacotador (Module Bundler)

Frameworks/Bibliotecas de Construção de Interfaces

Outras bibliotecas e frameworks

Ferramentas “tudo-em-um”

Conclusão

Outros materiais

» Buscar no Guia

» Navegar por Tópicos

Backend: Comece por aqui

Frameworks Java

Outros frameworks e bibliotecas

Conclusão

Outros materiais

» Buscar no Guia

» Navegar por Tópicos

React: Conheça esse famoso Framework para Desenvolvimento Web

Biblioteca ou Framework

Alternativas

Onde começar

Playlist

Vídeo

Conclusão

WebAssembly: A promessa de futuro do desenvolvimento Web

O que é?

Características:

Eficiente e rápido:

Seguro:

Aberto e passível de depuração:

Parte da plataforma web aberta:

Especificação:

Suporte dos Navegadores:

Quais as vantagens em relação ao Javascript?

E desvantagens, temos?

1️⃣ Adicione as dependências no `build.gradle`:

2️⃣ Configure o Kafka no `application.yml`: