DEV Community: Paulo Porto

AI-CLDD (AI-Change-Log Driven Development)

Paulo Porto — Wed, 28 Jan 2026 23:30:53 +0000

O uso de Inteligência Artificial no desenvolvimento de software deixou de ser experimental. Hoje, a IA escreve código, sugere arquiteturas, cria testes e participa ativamente da evolução de sistemas reais.

Mas, conforme a IA passa de “assistente” para agente ativo, um novo problema surge: perda de contexto e de intenção ao longo do tempo.

Este artigo apresenta o ai-cldd (AI Change-Log Driven Development), um padrão de design criado para resolver exatamente esse problema.

Repositório oficial:
https://github.com/cesarpaulomp/ai-cldd

O problema: quando a IA esquece o porquê

Prompts são efêmeros.

Código não explica decisões.

E a próxima IA (ou desenvolvedor) quase nunca sabe por que algo foi feito.

Alguns sintomas comuns em projetos com IA:

Funcionalidades implementadas sem contrato explícito
Decisões arquiteturais incoerentes ao longo do tempo
Dificuldade de evoluir código gerado por outra IA
Falta de rastreabilidade entre intenção e implementação
Alto risco de regressão conceitual

O problema não é a IA gerar código errado.

O problema é não existir um histórico confiável de intenção e decisão.

A ideia central do ai-cldd

O ai-cldd parte de um princípio simples:

Nenhuma mudança sem intenção documentada.

Nenhuma intenção sem registro do que foi aplicado.

Na prática:

A intenção é escrita em um documento
A IA aplica essa intenção no código
A IA registra exatamente o que foi feito

Esse ciclo cria continuidade cognitiva, mesmo quando múltiplas IAs ou desenvolvedores trabalham no mesmo projeto ao longo do tempo.

SYSTEM_BASE e FEATURE: separando contrato de mudança

SYSTEM_BASE (SB-*)

Documentos SYSTEM_BASE definem o contrato técnico global do sistema.

Eles descrevem:

O que o sistema é e faz
Tecnologias obrigatórias
Padrões arquiteturais
Restrições que não podem ser violadas
Estrutura do projeto
Padrões de comunicação

Esses documentos usam o prefixo SB- e sempre têm prioridade máxima.

Exemplo:
SB-000 – System Base

FEATURE Use Cases (UC-*)

Documentos FEATURE descrevem mudanças ou adições de comportamento.

Eles definem:

O que deve ser implementado
O que está dentro e fora de escopo
Estruturas de dados envolvidas
Endpoints ou interfaces
Tarefas objetivas de implementação

Esses documentos usam o prefixo UC- e devem sempre ser aplicados junto a um SYSTEM_BASE.

Exemplo:
UC-002 – Endpoints para estado do jogo

Change-logs: a memória da IA

Toda aplicação de um SYSTEM_BASE ou FEATURE gera exatamente um change-log.

Esse change-log registra:

Qual documento foi aplicado
O checksum do conteúdo
Quando a mudança ocorreu
Qual agente de IA aplicou
Quais alterações foram feitas

Esses registros são imutáveis e se tornam a memória auditável do sistema.

Estrutura esperada no projeto

/ai-cldd
/docs
SB-000 - System Base.md
UC-001 - Feature.md
UC-002 - Feature.md

/change-logs
SB-000.yaml
UC-001.yaml
UC-002.yaml

ai-cldd-v1.yaml

O papel do ai-cldd-v1.yaml

O arquivo ai-cldd-v1.yaml funciona como um manual de execução para a IA.

Ele define:

Tipos de documentos
Prioridade entre regras
Ordem correta de execução
Estrutura obrigatória de change-logs
Ações proibidas e obrigatórias

Esse arquivo deve ser copiado para o projeto e explicitamente referenciado no prompt da IA.

O que o ai-cldd não é

Não é um framework
Não é uma metodologia ágil
Não é uma ferramenta de prompt
Não depende de linguagem ou stack

O ai-cldd é um padrão de design para desenvolvimento assistido por IA.

Por que esse padrão importa

À medida que a IA se torna parte do time, precisamos tratar decisões técnicas como ativos duráveis.

O ai-cldd permite:

Evolução segura de sistemas complexos
Rastreabilidade completa de decisões
Menor acoplamento entre prompts e código
Onboarding mais rápido de novas IAs ou desenvolvedores
Continuidade arquitetural ao longo do tempo

Conclusão

O ai-cldd não tenta controlar a IA.

Ele cria contratos claros para que a IA opere com segurança.

Se você já usa IA no desenvolvimento, a pergunta não é se precisa de algo assim — é quando a falta disso vai começar a custar caro.

SSR vs SPA | Qual devo usar?

Paulo Porto — Mon, 19 Jan 2026 20:16:59 +0000

O objetivo deste artigo é guiá-los na escolha da melhor tecnologia para sua aplicação.

Quando iniciei minha carreira, comecei com JSF (JavaServer Faces), um MPA (Multi-Page Application) no qual o servidor entregava o HTML completamente renderizado para o navegador apenas exibir. Cada interação do usuário resultava em uma nova requisição e, consequentemente, em um novo carregamento de página.

Pouco tempo depois, o Ajax explodiu em popularidade — junto com o jQuery — e passou a permitir a atualização de apenas partes da página. Isso trouxe mais dinamismo às aplicações e reduziu significativamente a quantidade de reloads completos, melhorando a experiência do usuário sem abandonar o modelo server-side.

Em seguida, houve uma ruptura. Os dispositivos pessoais se tornaram mais potentes, os navegadores evoluíram e isso abriu espaço para utilizar o cliente como principal responsável pela renderização da interface. Nesse contexto, o modelo SPA (Single-Page Application) ganhou popularidade e passou a dominar o desenvolvimento frontend.

O SPA consolidou o backend como um provedor de APIs, separando de forma mais clara frontend e backend. Essa mudança ajudou a reduzir custos de infraestrutura e aumentou a flexibilidade arquitetural, mas também trouxe novos problemas: o primeiro carregamento das aplicações ficou mais lento e o SEO das páginas públicas piorou significativamente.

É nesse cenário que o SSR surge como uma tentativa de corrigir os problemas das SPAs sem simplesmente retornar ao modelo do passado. A página volta a ser renderizada no servidor, garantindo um carregamento inicial mais rápido e melhor indexação, mas após a entrega inicial ela passa a se comportar como uma SPA no navegador.

O que mudou ao longo do tempo não foi apenas a tecnologia, mas a forma como equilibramos responsabilidades entre servidor, cliente, performance e experiência do usuário.

Qual devo usar?
Antes de decidir entre SPA ou SSR, é fundamental responder a algumas perguntas básicas sobre o projeto:

Para quem é esta aplicação?
É um sistema interno, um painel administrativo, uma ferramenta autenticada ou uma aplicação pública voltada para usuários finais?
Qual é o meu orçamento?
Tenho recursos para manter uma infraestrutura mais complexa, com renderização no servidor, cache e possíveis custos adicionais de escalabilidade?
Preciso que a primeira renderização seja rápida?
O tempo até o primeiro conteúdo visível é crítico para a experiência do usuário?
SEO é importante para a página?
O conteúdo precisa ser indexado por mecanismos de busca ou compartilhado em redes sociais com preview adequado?
Qual é o tamanho da aplicação?
Mesmo que a primeira renderização precise ser rápida, nem sempre o tamanho e a complexidade da aplicação justificam o uso de SSR.

Para quem é o SPA
Use SPA quando a aplicação se comporta mais como um software do que como um site. Nesses cenários, o tempo da primeira renderização e o SEO não são fatores críticos.

Exemplos:
Ferramentas internas ou aplicações que exigem autenticação para acesso. Nesse tipo de sistema, as funcionalidades e informações não estão disponíveis ao público em geral, mas restritas a usuários específicos, como equipes internas, parceiros ou clientes autenticados.

Para quem é o SSR
Use SSR quando a aplicação se comporta mais como um site do que como um software. Nesses cenários, o tempo da primeira renderização e o SEO são fatores críticos para o sucesso do projeto.

Exemplos:
Sites institucionais, blogs, portais de conteúdo, e-commerces e landing pages. Em aplicações desse tipo, o conteúdo precisa estar disponível rapidamente, ser facilmente indexado por mecanismos de busca e gerar previews corretos ao ser compartilhado em redes sociais.

Conclusão
Durante minha carreira vi pequenas aplicações serem criadas com SSR antes validar se o SPA poderia atender. Vi aplicações pequenas com muito acesso necessitando de 16 servidores para atender a quantidade de requisições. Porém somente parte do conteúdo era púplico e a grande maioria era autenticado. Neste caso você poderia ter duas aplicações e reduzir a quantidade de servidores.

No fim, a melhor tecnologia é aquela que atende aos requisitos do negócio, equilibrando corretamente custo e benefícios.

Evolução da linguagem Java (parte 5)

Paulo Porto — Fri, 24 Oct 2025 16:59:14 +0000

Neste artigo damos continuidade à nossa análise histórica sobre os recursos que cada versão do Java trouxe para tornar o código mais limpo e simples para o desenvolvedor.

Se você caiu de paraquedas aqui e ainda não leu a primeira parte, clique aqui.

Java 19 e 20

As versões Java 19 e 20 não trouxeram mudanças definitivas na forma de escrever código, mas apresentaram importantes recursos em preview que abririam o caminho para grandes transformações nas versões seguintes.

Java 21

O Java 21, lançado em setembro de 2023, esta versão trouxe finalmente recursos estáveis que mudaram a forma de escrever código no dia a dia.

Entre eles estão:

Record Patterns
Pattern Matching for switch

(As Virtual Threads também foram finalizadas — sem dúvida, a melhor parte desta versão. Elas merecem um artigo dedicado apenas a elas!)

🧩 Record Patterns

Os Record Patterns apresentados na versão do Java 19 e 20 e agora finalizado na 21, elas permitem desconstruir objetos record diretamente em variáveis.

record Point(int x, int y) {}

// Before 21
// pattern matching for instanceof
void printPoint(Object obj) {
    if (obj instanceof Point p) {
        System.out.println("x = " + p.x() + ", y = " + p.y());
    }
}

// With 21
// record pattern
void printPoint(Object obj) {
    if (obj instanceof Point(int x, int y)) {
        System.out.println("x = " + x + ", y = " + y);
    }
}

🧠 Pattern Matching for switch

O Pattern Matching for switch foi apresentado nas versões anteriores Java e agora finalizado no Java 21.

Agora o switch pode verificar tipos e extrair valores diretamente, eliminando a necessidade de múltiplos if/else com instanceof.

// Before
static String process(Object obj) {
    if (obj instanceof String s) {
        return "String com %d caracteres".formatted(s.length());
    } else if (obj instanceof Integer i) {
        return "Número: " + i;
    } else {
        return "Outro tipo";
    }
}

// With 21
static String process(Object obj) {
    return switch (obj) {
        case String s -> "String com %d caracteres".formatted(s.length());
        case Integer i -> "Número: " + i;
        case null -> "Valor nulo";
        default -> "Outro tipo";
    };
}

Java 22, 23 e 24

Com exceção do Java 23, que trouxe como recurso final o Markdown Documentation Comments no JavaDoc — permitindo documentar o código com Markdown de forma moderna — as versões 22, 23 e 24 tem evoluções em preview, voltadas à clareza da linguagem.

Com elas vieram os seguintes preview:

Padrões com tipos primitivos em instanceof e switch
Importações de módulo simplificadas (Module Import Declarations)
Corpos de construtores flexíveis (Flexible Constructor Bodies)

Java 25

JDK 25 teve impacto direto na forma de escrever código mais simples e limpo. Em destaque temos o Compact Source Files and Instance Main Methods, Module Import Declarations, Corpos de construtores flexíveis

Compact Source Files and Instance Main Methods

Permite que programas Java simples ou protótipos sejam escritos com menos boilerplate, sem exigir a declaração explícita de

public class HelloWorld { 
  public static void main(String[] args) {
    System.out.println("Hello, Java!");
  } 
}

agora pode haver um arquivo com método void main() direto.

void main() {
    System.out.println("Hello, Java 25!");
}

Importações de módulo simplificadas (Module Import Declarations)

Simplifica a organização de código em projetos modulares.
Ele permite importar diretamente módulos inteiros, sem precisar listar dezenas de pacotes e classes.

Obs: Infelizmente não posso exemplificar e usar um recurso que nunca precisei usar. JPMS (Java Platform Module System) é um recurso opicional e coexiste com o modelo clássico classpath.

Corpos de construtores flexíveis

Torna os construtores mais flexíveis, permitindo executar código antes da chamada a super() ou this(), desde que esse código não use o objeto ainda não inicializado (ou seja, não acesse campos de instância nem invoque métodos de instância).

public class Produto extends Item {
    private final int preco;

    public Produto(int preco) {
        // ✅ Código permitido antes de super()
        if (preco < 0) {
            throw new IllegalArgumentException("Preço não pode ser negativo");
        }

        int precoFinal = Math.min(preco, 1000); // ajuste de valor
        super(precoFinal); // chamada pode vir depois

        this.preco = precoFinal;
    }
}

Conclusão:

A grande estrela deste artigo, sem dúvida, foi o Java 21, com novidades que realmente mudaram a forma de escrever código no dia a dia.

Meu segundo destaque vai para o Markdown Documentation Comments no JavaDoc, introduzido na versão 23.
Nos últimos anos, vimos o uso do JavaDoc diminuir, mas agora ele tem uma chance real de renascimento.
Podemos, inclusive, enxergar o JavaDoc como um par complementar ao OpenAPI/Swagger:

O JavaDoc ficando responsável pela documentação interna, voltada para quem mantém o código.
O OpenAPI/Swagger cuidando da documentação externa, voltada a times de front-end, QA e integradores.

Por fim, o recurso de Corpos de Construtores Flexíveis oferece uma casa mais natural para aquele código que precisa ser executado antes da inicialização completa de um objeto, tornando o construtor mais limpo e expressivo.

Evolução da linguagem Java (parte 4)

Paulo Porto — Thu, 16 Oct 2025 18:34:03 +0000

Neste artigo damos continuidade à nossa análise histórica sobre os recursos que cada versão do Java trouxe para tornar o código mais limpo e simples para o desenvolvedor.

Se você caiu de paraquedas aqui e ainda não leu a primeira parte, clique aqui.

Java 15

O Java 15 consolidou Text Blocks e trouxe o preview de Sealed Classes.

Text Blocks

Os Text Blocks simplificam muito o uso de strings multilinha — sem necessidade de concatenar ou escapar quebras de linha e aspas.

// Before
String json = "{\n" +
              "  \"name\": \"Maria\",\n" +
              "  \"age\": 30\n" +
              "}";
System.out.println(json);

// Text Blocks
String json = """
    {
      "name": "Maria",
      "age": 30
    }
    """;
System.out.println(json);

Java 16

O Java 16 consolidou Records e Pattern Matching para instanceof. Também trouxe o método toList() direto na Streams API, eliminando a necessidade de usar Collectors.

Records

Os Records foram criados para simplificar a criação de classes imutáveis de dados — aquelas que normalmente só têm atributos, construtor, getters, equals, hashCode e toString.

public record Person(String name, int age) {}

O compilador gera automaticamente o Construtor, equals, hashCode e toString. Os atributos são final.

Person p = new Person("Maria", 30);
System.out.println(p.name()); // Maria
System.out.println(p);

Pattern Matching para `instanceof`

Este recurso se tornou oficial no Java 16.
Ele elimina a necessidade de fazer cast manual após o instanceof.

//Before
Object obj = "Hello Java";

if (obj instanceof String) {
    String s = (String) obj;
    System.out.println(s.toUpperCase());
}

// Pattern Matching for instanceof
Object obj = "Hello Java";

if (obj instanceof String s) {
    System.out.println(s.toUpperCase());
}

Mais simples, mais seguro e mais legível.

`toList()` na Streams API.

O novo método toList() cria uma lista imutável, diferente do Collectors.toList(), que retorna uma lista mutável.

//Before
List<String> names = Stream.of("Ana", "Bruno", "Carlos")
.map(String::toUpperCase)
.collect(Collectors.toList());

System.out.println(names);

// Java 16
List<String> names = Stream.of("Ana", "Bruno", "Carlos")
.map(String::toUpperCase)
.toList();

System.out.println(names);

Se tentar adicionar elementos à lista resultante, será lançada uma UnsupportedOperationException.

Java 17

O Java 17 consolidou as Sealed Classes e as Switch Expressions, e como preview o Pattern Matching switch.

Sealed Classes

As Sealed Classes permitem controlar explicitamente quais classes podem herdar de uma classe base ou implementar uma interface.

public sealed class Forma 
    permits Circulo, Retangulo, Triangulo {}

final class Circulo extends Forma {}
final class Retangulo extends Forma {}
final class Triangulo extends Forma {}

Apenas as classes Circulo, Retangulo e Triangulo podem herdar de Forma.
Se alguém tentar criar class Hexagono extends Forma {}, o compilador retorna erro.
Além disso, subclasses devem ser final, sealed ou non-sealed, definindo se a hierarquia pode ou não continuar.

sealed class Animal permits Mamifero, Ave {}

final class Mamifero extends Animal {}
non-sealed class Ave extends Animal {}

Switch Expressions

O novo switch pode retornar valores, usar lambda arrows (->) e ainda evita fall-through acidental.

int day = 2;

//Before
String dayName;

switch (day) {
    case 1:
        dayName = "Domingo";
        break;
    case 2:
        dayName = "Segunda";
        break;
    default:
        dayName = "Outro dia";
}
System.out.println(dayName);

//Switch Expressions
String dayName = switch (day) {
    case 1 -> "Domingo";
    case 2 -> "Segunda";
    default -> "Outro dia";
};

System.out.println(dayName);

Java 18

O Java 18 não trouxe novidades de sintaxe, mas entregou outros avanços voltados à consistência do que à escrita de código em si.

Conclusão

Meus recursos favoritos dessas versões foram os Text Blocks, as Switch Expressions e o toList() na Streams API.
Os Text Blocks facilitaram muito a escrita de queries e strings longas, e as Switch Expressions economizam boas linhas de código no dia a dia.
O toList() é um método que uso bastante — mas é importante lembrar que ele cria uma lista imutável, o que pode ser um detalhe crítico quando se trabalha com enriquecimento de dados ou junção de coleções.
Gosto bastante dos Records como substitutos para a maioria dos DTOs/VOs, e estou animado para testá-los em conjunto com o OpenFeign.
Pattern Matching para instanceof éé bem interessante, embora eu ainda não tenha encontrado uma aplicação prática recente — o último projeto em que explorei bastante interfaces ainda estava em Java 8.
Já as Sealed Classes não me agradaram tanto.
Elas parecem proteger o código — mas de quem, afinal? De você mesmo? De outro colaborador?
Na prática, considero uma “proteção frágil”: um simples commit sem revisão e pronto, nada foi realmente protegido.

👉Concorda com a minha análise? Se lembrar de algum recurso relevante que não citei, compartilhe nos comentários.

Clique aqui para ler a parte final.

Java language evolution (part 1)

Paulo Porto — Thu, 02 Oct 2025 16:53:47 +0000

Have you ever thought about how the Java language has evolved in recent years?

In this article, we'll revisit the key features Java introduced in recent years that make developers’ lives easier and allow writing cleaner code.

To start, the first great leap! From Java 4 to Java 5/6.

A long time ago, I had the opportunity to work with Java 4 in a world where Java 5/6 already existed.
At this time, automatic conversion from primitive types did not exist.

List items = new ArrayList();

// add a number: needs to explicitly instantiate a new object.
items.add(new Integer(10));
items.add(new Integer(20));

// recover a number: needs to cast + call intValue()
Integer obj = (Integer) items.get(0);
int value = obj.intValue();

From Java 5, our lives became better with Autoboxing/Unboxing and Generics.

List<Integer> nums = new ArrayList<Integer>();
nums.add(10);        // autoboxing
int x = nums.get(0); // unboxing

Generics help to eliminate manual casts and make the code safer.
Furthermore we got Enum, Varargs, Annotations, for-each and Static import.

The forgotten but not less significant, Java 7

Java 7 introduced "Diamond Operator (<>)", "Multi-catch" and "Try-with-resources (ARM – Automatic Resource Management)".

Diamond Operator (<>) allows us to reduce repetition from Generic expressions when we are declaring objects.

// Before
Map<String, List<Integer>> mapp = 
             new HashMap<String, List<Integer>>();

// Java 7
Map<String, List<Integer>> mapp = new HashMap<>();

Multi-catch allows us to catch different exceptions in a single block.

try {
    someExplosiveMethod();
} catch (IOException | SQLException e) {
    e.printStackTrace();
}

Try-with-resources automatically closes resources that implement AutoCloseable. (Who hasn't ever forgotten to close a file?)

// Before
BufferedReader br = null;
try {
    br = new BufferedReader(new FileReader("dados.txt"));
    System.out.println(br.readLine());
} finally {
    if (br != null) br.close();
}

// Java 7
try (BufferedReader br = new BufferedReader(new FileReader("dados.txt"))) {
    System.out.println(br.readLine());
} // close automatically

Java 7 finally introduced Strings in switch statements.

Let's talk about the second great leap! Java 8

In this version for me the greatest highlights were "Lambda", "Streams API", "Optional" e "java.time".
So we got to Default Methods in Interfaces - It's a useful resource to evolve APIs without breaking compatibility.

Let's start with java.time

Inspired by Joda-time. It came to solve the long-standing problems of the old date and time classes.

Seriously! Have you ever tried adding days to a Date?

// before Java 8
import java.util.Calendar;
import java.util.Date;

public class ExampleBeforeJava8 {
    public static void main(String[] args) {
        // Current date
        Date today = new Date();
        System.out.println("Today: " + today);

        // Using Calendar to add 18 days
        Calendar cal = Calendar.getInstance();
        cal.setTime(today);
        cal.add(Calendar.DAY_OF_MONTH, 18);

        Date in18days = cal.getTime();
        System.out.println("In 18 days: " + in18days);
    }
}

Whenever you use Calendar, you need to remember that months start at 0 (January) and go up to 11 (December).

import java.util.Calendar;
import java.util.Date;

public class ExampleBeforeJava8 {
    public static void main(String[] args) {
        // See the trap!
        Calendar cal2 = Calendar.getInstance();
        cal2.set(2025, Calendar.SEPTEMBER, 19); // September = 8
    }
}

java.time comes with a modern model: immutable, clearer, and thread-safe.

import java.time.LocalDate;

public class ExampleWithJavaTime {
    public static void main(String[] args) {
        // Data atual
        LocalDate today = LocalDate.now();
        System.out.println("Today: " + today);

        // Adding 18 days
        LocalDate in18days = today.plusDays(18);
        System.out.println("In 18 days: " + in18days);
    }
}

Streams API changed how we do loops in Java.

// Before
List<String> names = Arrays.asList("Ana", "Bruno", "Alberto", "Carla");
int count = 0;
for (String n : names) {
    if (n.startsWith("A")) count++;
}

// Java 8
long count = names.stream()
                 .filter(n -> n.startsWith("A"))
                 .count();

Optional helps us deal with missing values in a safe way.

// Before
String city = null;
if (user != null && user.getAddress() != null) {
    city = user.getAddress().getCity();
}

// Java 8 (Optional)
String city = Optional.ofNullable(user)
                        .map(User::getAddress)
                        .map(Address::getCity)
                        .orElse("UNKNOWN");

Who hasn't used Optional in a Spring Data query method? If you haven't, you should give it a try.

To finish, Lambda

In the past we needed to use anonymous classes to implement simple behavior. Now with Lambda we can write less code.

List<String> names = Arrays.asList("Carlos", "Ana", "Bruno");

// Before
Collections.sort(names, new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return a.compareTo(b);
    }
});

// Using Java 8 (lambda)
names.sort((a, b) -> a.compareTo(b));
// OR
names.sort(String::compareTo);

Thanks for reading! Please follow me for the next part, where we’ll talk about Java 9 and 10.

Evolução da linguagem Java (parte 3)

Paulo Porto — Fri, 26 Sep 2025 16:57:15 +0000

Neste artigo damos continuidade à nossa análise histórica sobre os recursos que cada versão do Java trouxe para tornar o código mais limpo e simples para o desenvolvedor.

Se você caiu de paraquedas aqui e ainda não leu a primeira parte, clique aqui.

Java 11

O Java 11 trouxe várias melhorias pontuais. Entre elas, novos métodos em String(isBlank, lines, strip, stripLeading, stripTrailing e repeat), a possibilidade de usar var em parâmetros de expressões lambda e um novo HttpClient moderno e menos verboso.

Novos métodos em String

O isBlank(), verifica se a string é vazia ou contém apenas espaços em branco:

String texto = "  Olá  \nMundo  ";
String textoVazio = "        ";

System.out.println(texto.isBlank());  //false
System.out.println(textoVazio);       //true

O método lines() deixa o código mais limpo quando precisamos quebrar uma string em várias linhas.

String texto = "Linha 1\nLinha 2\nLinha 3";

String[] linhas = texto.split("\\R");

for (String l : linhas) {
    System.out.println(l);
}

// Java 11
texto.lines().forEach(System.out::println);

Os métodos strip, stripLeading e stripTrailing nasceram para substituir o nosso antigo método trim.

String s = "   Java   ";
System.out.println("[" + s.strip() + "]");  // [Java]
System.out.println("[" + s.stripLeading() + "]");   // [Java   ]
System.out.println("[" + s.stripTrailing() + "]");  // [   Java]

O trim não remove todos os tipos de espaço Unicode, apenas espaço comum, tab, quebra de linha e outros (menor ou igual a U+0020). Já o strip remove todos os espaços em branco Unicode do início e do fim.

String texto = "   Olá Mundo   ";
String textoUnicode = "\u2002Olá Mundo\u2002"; // contém espaço Unicode (EN SPACE)

System.out.println("[" + texto.trim() + "]");   // [Olá Mundo]
System.out.println("[" + texto.strip() + "]");  // [Olá Mundo]

// Diferença com Unicode
System.out.println("[" + textoUnicode.trim() + "]");  // [ Olá Mundo ]  (não removeu)
System.out.println("[" + textoUnicode.strip() + "]"); // [Olá Mundo]    (removeu)

O método repeat(int count), facilita muito a repetição de strings — algo que antes exigia laços ou utilitários.

// Antes - Usando StringBuilder
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 5; i++) {
    sb.append("=");
}
String repetido = sb.toString();

// Antes - Usando Collections.nCopies
String repetido = String.join("", Collections.nCopies(5, "="));

// Java 11
String repetido = "=".repeat(5);

Novo HttpClient

Este novo client, além de reduzir a verbosidade, trouxe suporte nativo a HTTP/2, eliminando a necessidade de bibliotecas de terceiros para casos simples.

// Java 11
HttpClient client = HttpClient.newHttpClient();
HttpRequest req = HttpRequest.newBuilder(URI.create("https://httpbin.org/get")).build();
HttpResponse<String> resp = client.send(req, HttpResponse.BodyHandlers.ofString());

System.out.println(resp.body());

Java 12, 13 e 14.

Nessas versões novos recursos foram adicionados, como Switch Expressions, Text Blocks, Records e Pattern Matching para instanceof.
Entretanto, todos ainda estavam sinalizados como preview. Vou falar especificamente de cada um deles nas versões em que se tornaram final.

Os métodos em String foram muito bem-vindos, mas na época eu esperava ainda mais.
Quando li sobre a novidade, imaginei que o Java finalmente eliminaria a necessidade de bibliotecas de terceiros (como a StringUtils, do Apache ou do Spring).
Ainda assim, esses métodos ajudam a reduzir linhas de código.

O uso de var em parâmetros de lambda, na minha visão, é desnecessário — acaba deixando o código mais verboso sem trazer ganho real.

Já o novo HttpClient chegou um pouco atrasado. Enquanto ele não existia, bibliotecas de terceiros já ofereciam suporte ao HTTP/2 há anos, e em grandes projetos ainda prefiro soluções maduras como OpenFeign ou OkHttp.

👉Concorda com a minha análise? Se lembrar de algum recurso relevante que não citei, compartilhe nos comentários.

Clique aqui para ler a quarta parte.

Evolução da linguagem Java (parte 2)

Paulo Porto — Thu, 25 Sep 2025 16:42:50 +0000

Neste artigo damos continuidade à nossa análise histórica sobre os recursos que cada versão do Java trouxe para tornar o código mais limpo e simples para o desenvolvedor.

Se você caiu de paraquedas aqui e ainda não leu a primeira parte, clique aqui.

Java 9

Nesta versão ganhamos métodos para criar coleções, métodos privados em interfaces, novos métodos para Streams API (takeWhile, dropWhile e iterate) e Optional (ifPresentOrElse, or, stream) e melhoria no Try-with-resources.

Novos métodos para criar coleções

Os novos métodos nos permite criar coleções imutáveis com mais facilidade.

// Antes
List<String> lista = Arrays.asList("A", "B", "C");

// Java 9
List<String> lista = List.of("A", "B", "C");
Set<Integer> set = Set.of(1, 2, 3);
Map<String, Integer> mapa = Map.of("um", 1, "dois", 2);

Arrays.asList não era imutável.

Novos métodos para Streams API

O takeWhile serve para pegar elementos de um stream até que a condição seja falsa pela primeira vez.

List<Integer> nums = List.of(1, 2, 3, 4, 5, 6, 7, 8);

List<Integer> resultado = nums.stream()
    .takeWhile(n -> n < 5)
    .collect(Collectors.toList());

System.out.println(resultado); // [1, 2, 3, 4]

Se a lista não estiver ordenada o takeWhile para na primeira condição de falha.

List<Integer> nums = List.of(1, 2, 6, 3, 4);

List<Integer> resultado = nums.stream()
    .takeWhile(n -> n < 5)
    .collect(Collectors.toList());

System.out.println(resultado); // [1, 2]

O dropWhile é o oposto do takeWhile. Ele descarta os elementos enquanto a condição for verdadeira.

List<Integer> nums = List.of(1, 2, 3, 4, 5, 6, 7);

List<Integer> resultado = nums.stream()
    .dropWhile(n -> n < 5)
    .collect(Collectors.toList());

System.out.println(resultado); // [5, 6, 7]

Como no takeWhile, em listas desordenadas o dropWhile para na primeira falha.

List<Integer> nums = List.of(2, 4, 6, 3, 1, 5);

List<Integer> resultado = nums.stream()
    .dropWhile(n -> n % 2 == 0)
    .collect(Collectors.toList());

System.out.println(resultado); // [3, 1, 5]

O iterate não é novo (veio no pacote do Java 8) mas no Java 9 ganhou uma nova versão com mais um parâmetro.

// Antes
Stream<Integer> numeros = Stream.iterate(1, n -> n + 2)
                                .limit(5);

numeros.forEach(System.out::println);
// Saída: 1, 3, 5, 7, 9

// Com Java 9
Stream<Integer> numeros = Stream.iterate(
    1,                // valor inicial
    n -> n < 20,      // condição de parada
    n -> n + 2        // passo
);

numeros.forEach(System.out::println);
// Saída: 1, 3, 5, 7, 9, 11, 13, 15, 17, 19

Novos métodos para Optional

O ifPresentOrElse executa uma função quando o valor do optional está presente ou outra função quando o valor está ausente.

Optional<String> nome = Optional.of("Maria");

nome.ifPresentOrElse(
    n -> System.out.println("Olá " + n),         // se presente
    () -> System.out.println("Valor ausente")   // se vazio
);

// Saída: Olá Maria

or permite fornecer outro Optional caso o valor esteja vazio.

Optional<String> nome = Optional.empty();

String resultado = nome
    .or(() -> Optional.of("Padrão"))
    .get();

System.out.println(resultado); // Padrão

O método stream transforma o Optional em uma Stream com no máximo 1 elemento.

Optional<String> nome = Optional.of("Ana");

List<String> lista = nome.stream()
                         .map(String::toUpperCase)
                         .collect(Collectors.toList());

System.out.println(lista); // [ANA]

Se for um Optional de uma lista, o stream gera uma Stream com um único elemento: a lista inteira.

Optional<List<String>> optLista = Optional.of(
                                List.of("A", "B", "C"));

optLista.stream()
        .forEach(System.out::println);
// Saída [A, B, C]

melhoria no Try-with-resources

Agora você pode usar recursos declarados antes do try.

BufferedReader br = new BufferedReader(new FileReader("dados.txt"));

try (br) {
    System.out.println(br.readLine());
}

Métodos privados em interfaces

Podemos extrair lógica comum dentro da própria interface.

interface Validador {
    default boolean validar(String s) {
        return s != null && comum(s);
    }
    private boolean comum(String s) {
        return !s.isEmpty();
    }
}

Java 10

O Java 10 nos trouxe o tipo var, que ajuda a aumentar a legibilidade dentro de blocos de código.

// Antes
for (Iterator<String> it = nomes.iterator(); it.hasNext();) {
    String nome = it.next();
}

// Java 10
for (var it = nomes.iterator(); it.hasNext();) {
    var nome = it.next();
}

O var não é tipagem dinâmica como em JavaScript. O tipo continua sendo estático, definido pelo compilador no momento da atribuição.
Ele não pode ser usado em:

Atributos de classe
Parametros de métodos
Retorno de métodos A tipagem continua forte, apenas evita a repetição.

Para mim, os recursos do Java 9 que mais brilham para escrever código limpo são os novos métodos do Optional e os métodos para coleções imutáveis. São sem dúvida os que mais uso no meu dia a dia.

Confesso que ainda prefiro criar classes abstratas para implementar interfaces quando quero compartilhar lógica comum, porque me sinto mais seguro do que levar esse comportamento para uma interface que pode ser implementada em classes que não precisam dele.

Já os novos métodos da Streams API (como takeWhile e dropWhile) ainda não encontrei necessidade de usar em projetos reais — mas é bom saber que estão lá quando for preciso.

O var do Java 10 é um excelente recurso, e ainda estou aprendendo a aproveitá-lo melhor no dia a dia.

👉 Será que os métodos do Optional e o List.of também foram os que mais impactaram o seu dia a dia? Ou você acha que outro recurso merece mais destaque?

Clique aqui para ler a terceira parte.

Evolução da linguagem Java (parte 1)

Paulo Porto — Sat, 20 Sep 2025 12:31:59 +0000

Você já pensou como a linguagem Java evoluiu nos últimos anos?

Neste artigo vamos relembrar os principais recursos que o Java trouxe ao longo das versões para tornar a vida do desenvolvedor mais fácil, permitindo escrever código mais limpo, conciso e simples.

Para começar, o primeiro grande salto! Do Java 4 para Java 5/6

Há muito tempo tive a oportunidade de trabalhar em um projeto com java 4 em um mundo que o java 5/6 já eram presentes.
Nesse tempo distante não existia a conversão automática de tipos primitivos para seu par em forma de objeto.

List lista = new ArrayList();

// Adicionar número: precisa criar explicitamente o objeto
lista.add(new Integer(10));
lista.add(new Integer(20));

// Recuperar número: precisa fazer cast + chamar intValue()
Integer obj = (Integer) lista.get(0);
int valor = obj.intValue();

A partir do Java 5 nossa vida de desenvolvedor melhorou muito com Autoboxing/Unboxing e Generics.

List<Integer> nums = new ArrayList<Integer>();
nums.add(10);        // autoboxing
int x = nums.get(0); // unboxing

Generics ajuda a eliminar casts manuais e tornara o código mais seguro.

Além disso tivemos a introdução de Enum, Varargs, Annotations, for-each e Static import.

na categoria qualidade de código, para mim a feature mais marcante do Java 6 foi o "Pluggable Annotation Processing Tool(APT)". Ela abriu caminho para frameworks como Lombok e JPA criarem código automaticamente.

Esquecido mas não menos importante, Java 7

Nós ganhamos o "Diamond Operator (<>)", "Multi-catch" e "Try-with-resources (ARM – Automatic Resource Management)".

Diamond Operator (<>) nos permite evitar a repetição de generics na criação de objetos.

// Antes
Map<String, List<Integer>> mapa = new HashMap<String, List<Integer>>();

// Java 7
Map<String, List<Integer>> mapa = new HashMap<>();

Multi-catch permite tratar múltiplas exceções diferentes em um único bloco.

try {
    metodoArriscado();
} catch (IOException | SQLException e) {
    e.printStackTrace();
}

Try-with-resources ajuda no fechamento automático de recursos que implementam AutoCloseable. (Quem nunca esqueceu de fechar um arquivo?)

// Antes
BufferedReader br = null;
try {
    br = new BufferedReader(new FileReader("dados.txt"));
    System.out.println(br.readLine());
} finally {
    if (br != null) br.close();
}

// Java 7
try (BufferedReader br = new BufferedReader(new FileReader("dados.txt"))) {
    System.out.println(br.readLine());
} // fecha sozinho

O Java 7 trouxe também Strings no switch (finalmente!).

Vamos falar do segundo grande salto! Java 8

Neste salto, para mim os maiores destaques vão para "Lambda", "Streams API", "Optional" e "java.time".
Também tivemos os Default Methods em Interfaces — um recurso útil para evoluir APIs sem quebrar compatibilidade, embora seu uso ainda gere discussões entre desenvolvedores.

Podemos começar com "java.time".
Inspirada no Joda-Time. Surgiu para resolver o problema histórico das classes antigas de data e hora.

É sério! Já tentou somar X dias em um Date?

import java.util.Calendar;
import java.util.Date;

public class ExemploAntesJava8 {
    public static void main(String[] args) {
        // Data atual
        Date hoje = new Date();
        System.out.println("Hoje: " + hoje);

        // Usando Calendar para somar 18 dias
        Calendar cal = Calendar.getInstance();
        cal.setTime(hoje);
        cal.add(Calendar.DAY_OF_MONTH, 18);

        Date daqui18dias = cal.getTime();
        System.out.println("Daqui a 18 dias: " + daqui18dias);
    }
}

Sempre que eu usava o Calendar precisava lembrar que os meses eram de 0 a 11 e não de 1 a 12.

import java.util.Calendar;
import java.util.Date;

public class ExemploAntesJava8 {
    public static void main(String[] args) {
        // Olha a pegadinha!
        Calendar cal2 = Calendar.getInstance();
        cal2.set(2025, Calendar.SEPTEMBER, 19); // Setembro = 8
    }
}

java.time trouxe um modelo moderno, imutável e muito mais claro com classes imutáveis e thread-safe.

import java.time.LocalDate;

public class ExemploComJavaTime {
    public static void main(String[] args) {
        // Data atual
        LocalDate hoje = LocalDate.now();
        System.out.println("Hoje: " + hoje);

        // Somando 18 dias
        LocalDate daqui18dias = hoje.plusDays(18);
        System.out.println("Daqui a 18 dias: " + daqui18dias);
    }
}

Streams API, mudou a forma de como fazemos loops no Java.

// Antes
List<String> nomes = Arrays.asList("Ana", "Bruno", "Alberto", "Carla");
int cont = 0;
for (String n : nomes) {
    if (n.startsWith("A")) cont++;
}

// Java 8
long cont = nomes.stream()
                 .filter(n -> n.startsWith("A"))
                 .count();

Optional chegou para lidar de forma segura com valores que podem estar ausentes.

// Antes (null check em cascata)
String cidade = null;
if (usuario != null && usuario.getEndereco() != null) {
    cidade = usuario.getEndereco().getCidade();
}

// Java 8 (Optional)
String cidade = Optional.ofNullable(usuario)
                        .map(Usuario::getEndereco)
                        .map(Endereco::getCidade)
                        .orElse("DESCONHECIDA");

Quem nunca retornou um Optional em um query method do Spring Data Jpa? Se não deveria tentar.

Para finalizar, Lambda!
No passado, sem os lambdas precisávamos de classes anônimas para implementar comportamentos simples.

List<String> nomes = Arrays.asList("Carlos", "Ana", "Bruno");

// Antes
Collections.sort(nomes, new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return a.compareTo(b);
    }
});

// Usando Java 8 (lambda)
List<String> nomes = Arrays.asList("Carlos", "Ana", "Bruno");

nomes.sort((a, b) -> a.compareTo(b));
// Ou ainda mais curto com method reference
nomes.sort(String::compareTo);

Veja a parte dois aqui.

Gateway-Oriented Architecture (GOA)

Paulo Porto — Sun, 03 Aug 2025 18:07:32 +0000

⚠️ This article was translated by AI.

Click here to read the original version in Portuguese.

In large-scale system development, the quantity and complexity of microservices can become a formidable enemy.

After facing this enemy multiple times, I refined a set of architectural patterns. These patterns are the foundation of an approach I call Gateway-Oriented Architecture (GOA).

GOA doesn't propose new components, but rather the disciplined organization of consolidated patterns to achieve maximum productivity and security.

🚪 What is GOA?

Gateway-Oriented Architecture (GOA) aims to simplify microservices development by isolating security and communication complexity into specialized components called Gateways.

Instead of having each microservice handle authentication, authorization, routing, and public exposure, GOA establishes clear and secure boundaries, based on the following principles:

Gateways as Explicit Boundaries: All communication entering or leaving a business area must go through a Gateway.
Isolation Between Business Domains: Services from different domains should not communicate directly.
Lean and Focused Microservices: Microservices are dedicated exclusively to their business logic.

🎯 Who is GOA for?

GOA is not a silver bullet. It shines in scenarios such as:

Organizations with multiple squads or distinct products
Companies that prioritize security, compliance, and governance
Systems where autonomy and scalability are crucial

🚫 When to avoid GOA?

GOA is not recommended for small or low-complexity projects. In such cases, the additional infrastructure might be overkill.

🧩 What architectural patterns are adopted?

API Gateway: Manages ingress/egress, authorization, routing, caching, and rate limiting.
Backend for Frontend (BFF): Data aggregation and response optimization for clients.
Domain-Driven Design (DDD): GOA materializes this concept by enforcing well-defined and isolated boundaries.
Focused Microservices: Each service owns a clear and unique responsibility.

🚀 What are the benefits of GOA?

Security: Security is not a developer-by-developer responsibility — it's a centralized architectural concern enforced through Gateways.
Productivity: Microservice developers can focus 100% on business rules. Code becomes cleaner, with fewer boilerplate dependencies, and onboarding new team members is faster.
Autonomy: Teams have full autonomy to develop, deploy, and scale services within their domain.
Improved Maintainability and Testability: Smaller services with clear responsibilities and no coupling are easier to maintain, refactor, and cover with unit and integration tests.

⚠️ Challenges and Mitigation Strategies

No architecture is free of trade-offs. Understanding GOA's challenges is key to successful implementation.

Challenge 1: Operational Complexity

More components = more infrastructure.

Mitigation strategies:

Use container orchestrators (e.g., Kubernetes, ECS)
Implement CI/CD pipelines for consistent delivery

Challenge 2: Single Point of Failure (SPOF)

A single gateway centralizing all traffic simplifies governance — but creates a SPOF. If it goes down, the entire application becomes inaccessible.

Mitigation strategies:

Never run a single gateway instance. Always deploy to a cluster with multiple replicas, load balancing, and health checks.
GOA doesn’t mandate a single gateway. As systems grow and domain autonomy becomes critical, the architecture can evolve to domain-based gateways, allowing each team to manage its own gateway.

📚 Usage Examples

Scenario 1 — New account creation

Client sends a POST to the external gateway with personal data
Gateway calls the User Data Service → persists data
Then it calls the Authentication Service → stores credentials

Scenario 2 — User authentication

Client sends a POST to the gateway with credentials
Gateway calls the Authentication Service
If valid, returns an authentication token

Scenario 3 — Community creation

Client sends a POST to the gateway with a token and community data
If the token is valid, the gateway calls the Community Service to persist the data

Scenario 4 — Viewing posts from a community

Client sends a GET request with a token and the community ID
If the token is valid, the gateway calls the Community BFF
The BFF queries the Community Service and enriches the result with data from the User Gateway

✅ Conclusion

No architecture is a silver bullet — and GOA, with its operational challenges, is no exception.

Still, it provides a scalable and robust model that optimizes what is arguably the most valuable asset in any tech company: developer time and focus.

By moving complexity to the edges, we’re not just writing cleaner code — we’re building more resilient systems and more productive teams. And in today’s tech landscape, that’s the most important competitive edge of all.

💬 And you? What strategies have you used to tame microservice complexity? Share your thoughts in the comments!

Arquitetura Orientada a Gateways (GOA — Gateway-Oriented Architecture)

Paulo Porto — Sun, 03 Aug 2025 18:01:59 +0000

No desenvolvimento de grandes sistemas, a quantidade e complexidade de microserviços podem se tornar um inimigo desafiador.

Depois de enfrentar esse inimigo diversas vezes, refinei um conjunto de padrões. Estes padrões são os pilares de uma abordagem que eu chamo de Arquitetura Orientada a Gateways (GOA).

GOA não propõe novos componentes, mas sim a organização disciplinada de padrões consolidados para alcançar máxima produtividade e segurança.

O que é a GOA?

A Arquitetura Orientada a Gateways (GOA) tem como objetivo simplificar o desenvolvimento de microserviços ao isolar a complexidade de segurança e comunicação em componentes especializados chamados Gateways.

Em vez de cada microserviço lidar com autenticação, autorização, roteamento e exposições públicas, a GOA estabelece fronteiras claras e seguras, com base nos seguintes princípios:

Gateways como Fronteiras Explícitas: Toda comunicação que entra ou sai de uma área de negócio deve passar por um Gateway.
Isolamento entre Áreas de Negócio: Serviços de diferentes domínios não se comunicam diretamente.
Microserviços Enxutos e Focados: Os microserviços são focados exclusivamente na sua regra de negócio.

Para quem é a GOA?

A GOA não é uma solução para tudo. Ela brilha em contextos como:

Empresas com múltiplas squads ou produtos distintos
Organizações que priorizam segurança, compliance e governança
Sistemas onde autonomia e escala são prioridades

Quando evitar a GOA?

GOA não é recomendada para projetos pequenos ou com baixa complexidade. Nesses cenários, a infraestrutura adicional pode ser um exagero.

Quais são os padrões arquiteturais adotados?

API Gateway: Controla entrada/saída, autorização, roteamento, caching e rate limiting.
Backend for Frontend (BFF): Composição de dados e otimização da resposta para o cliente.
Domain-Driven Design (DDD): A GOA materializa esse conceito com fronteiras bem definidas e isoladas.
Microserviços focados: Cada serviço com uma responsabilidade clara e única.

Quais as vantagens de usar GOA no desenvolvimento?

Segurança: A segurança não é uma responsabilidade de cada desenvolvedor, mas sim uma característica centralizada e garantida pela arquitetura nos Gateways.
Produtividade: Os desenvolvedores de microservices podem se concentrar 100% nas regras de negócio. O código fica mais limpo, com menos dependências repetitivas e genéricas e a curva de aprendizado para novos membros da equipe é reduzida.
Autonomia: Os times têm total autonomia para desenvolver, implantar e escalar os serviços dentro de seu contexto.
Manutenibilidade e Testabilidade Aprimoradas: Serviços menores, com responsabilidades claras e sem acoplamento. São mais fáceis de manter, refatorar e cobrir com testes unitários e de integração.

Desafios e Estratégias de Mitigação

Nenhuma arquitetura é isenta de trade-offs. Entender desafios da GOA é fundamental para uma implementação bem-sucedida.

Desafio 1: Complexidade Operacional:

Mais componentes = mais infraestrutura.

Estratégia de Mitigação

Usar orquestradores de contêineres (Kubernetes, ECS etc.)
Usar ferramentas de pipelines de CI/CD

Desafio 2: Ponto Único de Falha (SPOF)

Um único Gateway centraliza todo o tráfego. Embora isso simplifique a governança, cria um potencial ponto único de falha. Se este Gateway cair, toda a aplicação se torna inacessível.

Estratégia de Mitigação

A primeira linha de defesa é nunca rodar uma única instância do Gateway. Ele deve ser sempre implantado em um cluster com múltiplas réplicas, balanceamento de carga e health checks.
A GOA não obriga a existência de um único Gateway. À medida que o sistema cresce e a autonomia das áreas de negócio se torna mais crítica, a arquitetura pode evoluir para um modelo de Gateways por área. Assim o time pode implantar seu próprio Gateway.

Exemplos de uso

Cenário 1: Um novo cliente deseja criar uma conta na plataforma
Solução: O Cliente faz um POST no gateway externo passando seus dados pessoais. O Gateway que chama o "User Data Service" que persiste os dados pessoais do usuário e em seguida o "User Data Service" chama o "Authentication Service" para salvar os dados de autenticação.

Cenário 2: O usuário quer se autenticar para usar o sistema.
Solução: O Cliente faz um POST no gateway externo passando os dados para autenticação. O Gateway que chama o "Authentication Service" Caso os dados sejam válidos, retorna um token de autenticação.

Cenário 3: O usuário quer criar uma comunidade.
Solução: cliente faz um POST no gateway externo passando seu token de autenticação e dados necessários para criar sua comunidade. Caso o token de autenticação seja válido, o Gateway chama o "Community Service" para persistir os dados.

Cenário 4: O usuário quer ver os posts de uma comunidade.
Solução: O cliente faz um GET no gateway externo passando seu token de autenticação e o ID da comunidade que deseja ver os posts. Caso o token seja válido, chama o "Community BFF" que faz consulta no "Community Service" e depois enriquece o resultado com o nome e foto vindos do "User Gateway"

Conclusão

Nenhuma arquitetura é uma bala de prata — e a GOA, com seus desafios operacionais, não é exceção. No entanto, em última análise, a GOA é uma arquitetura que otimiza para o ativo mais valioso de qualquer empresa de tecnologia: o tempo e o foco de seus desenvolvedores.

Ao mover a complexidade para as bordas, não estamos apenas escrevendo código mais limpo; estamos construindo sistemas mais resilientes e times mais produtivos. E no cenário tecnológico atual, essa é a vantagem competitiva mais importante de todas.

E você? Que estratégias tem usado para domar a complexidade dos microservices? Deixe sua opinião nos comentários!

How to Create a New Bucket in AWS Amazon S3 and Configure Remote Access via IAM

Paulo Porto — Wed, 27 Mar 2024 23:16:40 +0000

Você pode ler este artigo na versão em português clicando aqui.

The objective of this article is to guide the reader step by step in creating a new bucket in AWS S3 (Simple Storage Service) and then creating a key in IAM (Identity and Access Management) allowing remote access.

What is AWS S3?

Amazon Simple Storage Service (S3) is an object storage service offered by Amazon Web Services (AWS). It provides a simple and scalable way to store and retrieve data, such as photos, videos, documents, and backups, in the cloud. Users can store an unlimited amount of data in S3 and access it securely over the internet. S3 is widely used for data backup, hosting static content for websites and web applications, file sharing, log storage, and more. It offers high durability, scalability, and availability, making it a popular choice for a variety of use cases.

Requirements

Have an AWS account.

Accessing the AWS console.

Access the AWS console through the browser and then search for S3 in the search bar at the top of the page.

Click the "create bucket" button to start the process.

Creating a bucket

General settings

Choose the region where your bucket will be stored. You can choose based on cost or latency. If latency is not important, prefer regions located in North America such as us-east-1 where the storage cost is lower.
Give a name to your bucket. This name must be unique to avoid conflicts with other AWS users. You can see the rules here Depending on the chosen region, you must choose a type for your bucket. When in doubt, choose "General Purpose."

Object properties

In this section, you can configure object properties for another AWS account. This means you can transfer the ownership of objects stored in S3 to another account, giving that account control over those objects. This can be useful in scenarios where you need to share data with partners or clients but want to maintain ownership of the objects.
The "ACLs disabled" option maintains the ownership of the objects in your account, while "ACLs enabled" allows transferring ownership to other accounts.

Blocking public access to bucket objects.

You can make access to your stored objects public.
It is recommended that you do not do this. Ideally, your applications should be implemented without the need for public access to bucket objects.

Versioning

You can enable versioning for objects. This creates a history of stored objects, allowing you, for example, to access previous versions of modified objects or recover deleted objects.
Remember that by maintaining this history, you may increase your storage cost.

Encryption

Before your objects are stored, they are encoded (transformed into an unreadable form) and can only be decoded (made readable again) with the correct key. This helps keep your data secure, even in the cloud.
You can specify a key or allow AWS to use one of its keys for encryption.
You can also enable two-layer encryption.

Advanced settings/Object Lock

Object Lock is a feature of Amazon S3 that provides an additional layer of protection for your data, helping to prevent accidental or malicious deletions or modifications to stored objects.
Object Lock can only be used on buckets with versioning enabled.

After going through all these settings, click "Create Bucket," and your new bucket is ready.

IAM

What is IAM?

IAM, or Identity and Access Management, is like a gatekeeper for your AWS account. It controls who can enter and what each person or program can do once inside. With IAM, you can create users, grant them specific permissions, and manage who has access to which resources in the AWS cloud. In summary, IAM helps keep your account secure and organized, allowing you to control who can do what.

What are we going to do?

Create a policy that allows specific access to our new bucket.
Create a user to associate with the new policy with an access key for use in an application.

To access the IAM dashboard, search for "IAM" in the search bar located at the top of the page.

Creating a policy

What is a policy?

A policy in IAM is the specification of the exact permissions that a user (application or resource) will have within your AWS account.

In the menu located on the left corner, click on "Policies" under "Access management."

Click on "Create Policy" to start the process.

You can create the policy in two ways:

Visually. You choose the service, and AWS lists for you each available permission for that service. This way is interesting to get to know each permission. Permissions are listed with an "info" button next to them, explaining them in detail.
With JSON. It's the best way for those who already know the permissions or are following an example.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::NAME_OF_BY_BUCKET/*",
                "arn:aws:s3:::NAME_OF_BY_BUCKET"
            ]
        }
    ]
}

After choosing which services and permissions for each service, click "next."

On the next screen, we need to give a name to our policy, we can add an optional description explaining the use of this new policy, add tags, and review the permissions added to it.

Click "Create Policy" at the bottom of the page to finish this step.

Creating a user

In the menu located on the left corner, click on "Users" under "Access management."

Click on "Create user" to start the process.

We need to provide a name for this user and decide if we want them to have access to this panel we are seeing. Since the goal is to create a user for remote access via SDK, we won't check this option.

Click "next" to proceed.

On the second screen, we'll define how to associate the user with the policy.

Add user to group: You can create a group of policies and associate this group with various users. To exemplify, think of each group as a role within a company. Roles are assigned to people who work in them.
Copy permissions: Allows you to choose an existing user and copy their permission settings.
Attach policies directly: Adds the policy directly to the user. (This is our option for now).

Click "next" to proceed.

On this screen, we have a summary of the user creation process, and we can add tags.

Click "Create user" to finish.

Creating an Access Key for this user.

After saving, we'll return to the user details screen. Click on the "User name" of your new user.

Look for the "Security credentials" tab and click on it. Then scroll down to "Access keys" and click on "Create access Key."

On this screen, we inform the reason for creating the access key. AWS has other alternatives to avoid creating fixed access keys. For our case, we'll use "Application running outside AWS."

Click "next" to proceed.

We can add a description to our access key.

Click "Create access key" to proceed.

In this final step, we have our "Access key" and "Secret access key" ready for use. You can only copy the "Secret access key" on this screen. Once you leave it, it will no longer be possible to retrieve it.

After clicking "done," we return to the user details screen. Here, you can create a new "Access key," deactivate, or delete old ones.

Conclusion

AWS's S3 service allows you to store your files securely and affordably. IAM enables you to grant access to other people or applications to the resources you've created within AWS. When using a fixed "Access key," remember to keep your "Access secret key" secret so that malicious users don't exploit your resources or cause you harm. Don't hesitate to delete old "access keys" that are unused or rotate your "access keys" if you suspect any compromise. Be sure to check out AWS's official documentation.

Como Criar um Novo Bucket no Amazon S3 da AWS e Configurar Acessos Remotos via IAM

Paulo Porto — Wed, 27 Mar 2024 21:35:40 +0000

You can click here to see the version of this post in English.

O objetivo deste artigo é guiar o leitor passo a passo na criação de um novo bucket no S3 (Simple storage service) da AWS e em seguida criar uma chave no IAM (Identity and Access Management) permitindo acessos remotos.

O que é o AWS S3?

O Amazon Simple Storage Service (S3) é um serviço de armazenamento de objetos oferecido pela Amazon Web Services (AWS). Ele fornece uma maneira simples e escalável de armazenar e recuperar dados, como fotos, vídeos, documentos e backups, na nuvem. Os usuários podem armazenar uma quantidade ilimitada de dados no S3 e acessá-los de forma segura pela internet. O S3 é amplamente utilizado para backup de dados, hospedagem de conteúdo estático para sites e aplicativos da web, compartilhamento de arquivos, armazenamento de logs e muito mais. Ele oferece alta durabilidade, escalabilidade e disponibilidade, tornando-se uma escolha popular para uma variedade de casos de uso.

Requisitos

Ter uma conta na AWS.

Acessando o console da AWS.

Acesse o console da aws pelo navegador e em seguida pesquise por S3 na barra de pesquisa no topo da página.

Clique no botão "create bucket" para iniciar o processo.

Criando bucket

Configurações gerais

Escolha a região onde seu bucket será armazedado. Você pode escolher baseado em custo vou latencia. Se a latencia não for importante de preferência as regiões localizadas na Ameria do Norte como a us-east-1 onde o custo de armazenamento é menor.
De um nome para seu bucket. Este nome precisa ser único para evitar conflitos com outros usuários da aws. Você pode ver as regras aqui
Dependendoda região escolhida, você deve escolher um tipo para seu bucket. Na dúvida escolha o "General Purpose".

Propriedade de objetos

Neste bloco você pode configurar propriedade de objetos a outra conta AWS. Isso significa que você pode transferir a propriedade de objetos armazenados no S3 para outra conta, dando a essa conta controle total sobre esses objetos. Isso pode ser útil em cenários onde você precisa compartilhar dados com parceiros ou clientes, mas deseja manter a propriedade dos objetos.
A opção "ACLs disabled" mantém a propriedade dos objetos na sua conta, enquanto "ACLs enabled" permite transferir a propriedade para outras contas.

Bloquear acesso público os objetos do bucket.

Você pode tornar público o acesso dos seus objetos armazenados.
É recomendado que você nao faça isso. O ideal que suas aplicações sejam implementadas sem precisar do acesso público aos objetos do bucket.

Versionamento

Você pode ligar o versionamento dos objetos. Isso cria um histórico dos objetos armazenados. Permitindo você, por exemplo, acessar versões anteriores de objetos modificados ou recuperar objetos deletados.
Lembre-se que ao manter este histórico você pode aumentar o seu custo de armazenamento.

Criptografia

Antes dos seus objetos serem armazenados, eles são codificados (transformados em uma forma ilegível), e só podem ser decodificados (tornados legíveis novamente) com a chave correta. Isso ajuda a manter seus dados seguros, mesmo na nuvem.
Você pode especificar uma chave ou permitir que a aws use uma das chaves dela para a criptografia.
Você também pode habilitar a criptografia em duas camadas.

Configurações avançadas/Object Lock

O Object Lock é uma característica do Amazon S3 que oferece uma camada adicional de proteção para seus dados, ajudando a prevenir exclusões ou modificações acidentais ou maliciosas nos objetos armazenados.
O Object Lock só pode ser utilizado em buckets com o versionamento ativado.

Após passar por todas estas configurações, clique em "Create Bucket" e pronto seu novo bucket está criado.

IAM

O que é o IAM?

O IAM, ou Identity and Access Management, é como um porteiro para sua conta da AWS. Ele controla quem pode entrar e o que cada pessoa ou programa pode fazer lá dentro. Com o IAM, você pode criar usuários, conceder permissões específicas a eles e gerenciar quem tem acesso a quais recursos na nuvem da AWS. Em resumo, o IAM ajuda a manter sua conta segura e organizada, permitindo que você controle quem pode fazer o quê.

O que vamos fazer?

Criar uma policy que permite acessos específicos ao nosso novo bucket.
Criar um usuário para associado a nova policy com uma chave de acesso para usar em uma aplicação.

Para acessar o painel do IAM pesquise por "IAM" na barra de pesquisa localizada na parte superior da página.

Criando uma policy

O que é uma policy?

Uma policy no IAM e a especificação das permissões exatas que um usuário (aplicação ou recurso) terá dentro da sua conta da AWS.

No menu localizado no canto esquerdo, clique em "Policies" entro de "Access management"

Clique em "Create Policy" para iniciar o processo.

Você pode criar a policy de duas maneiras.

De forma visual. Você escolhe o serviço e a aws lista para você cada permissão disponível deste serviço. Esta forma é interessante para conhecer cada permissão. As permissões são listadas com um botão "info" ao lado que a explica de forma detalhada.
Com JSON. É a melhor forma para quem já tem já conhece as permissões ou estja seguindo um exemplo.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::NAME_OF_BY_BUCKET/*",
                "arn:aws:s3:::NAME_OF_BY_BUCKET"
            ]
        }
    ]
}

Após ter escolhido quais serviços e quais permissões em cada serviço clique em "next".

Na próxima tela, precisamos dar um nome para nossa policy, podemos adicionar uma descrição opcional explicando o uso desta nova policy, adicionar tags e revisar as permissões adicionadas nela.

Clique em "Create Policy" no final da página para finalizar esta etapa.

Criando um usuário

No menu localizado no canto esquerdo, clique em "Users" entro de "Access management"

Clique em "Create user" para iniciar o processo.

Precisamos informar um nome para este usuário e se queremos que ele tenha acesso a este painel que estamos vendo.
Como o objetivo é criar um usuário para acesso remoto via sdk não vamos marcar esta opção.

Clique em "next" para prosseguir.

Na segunda tela vamos definir como associar o usuário a policy.

Add user to group: Você pode criar um grupo de policies e associar este grupo a diversos usuários. Para exemplificar, pense que cada grupo é uma função dentro de uma empresa. As funções são atribuidas as pessoas que trabalham nela.
Copy permissions: Permite você escolher um usuário já existente e copiar as opções de permissão deste usuário.
Attach policies directly: Adiciona a policy diretamente ao usuário. (É na nossa opção para este momento).

Clique em "next" para prosseguir.

Nesta tela temos um resumo do processo de criação do usuário e podemos adicionar tags.

Clique em "Create user" para finalizar.

Criando um Access Key para este usuário.

Após salvar o voltaremos a tela de listagem de usuários. Clique no "User name" do seu novo usuário.

Procure pela aba "Security credentials" e clique nela. Em seguida role a tela até "Access keys" e clique em "Create access Key".

Nesta tela informamos o motivo para a criação da access key. A Aws tem outras alternativas para não criar acess keys fixas.
Para o nosso caso vamos utilizar "Application running outside AWS".

Clique em "next" para prosseguir.

Podemos adicionar uma descrição em nossa access.

Clique em "Create access key" para prosseguir.

Nesta etapa final temos nossa "Access key" e "Secret access key" pronta para uso.
Você pode copiar a "Secret access key" somente nesta tela. Assim que você sair dela não será mais possível recuperá-la.

Ao clicar em "done", voltamos a tela de detalhes de usuário.
Aqui você pode criar uma nova "Access key", desativar ou apagar as antigas.

Conclusão

O serviço S3 da AWS permite você a armazenar seus arquivos com segurança e um custo acessível. O IAM permite que você de acesso a outras pessoas ou aplicações aos recursos que você criou dentro da AWS. Ao usar uma "Access key" fixa lembre-se de guardar sua "Access secret key" em segredo para que usuários mal intencionados não usem seus recursos para o mal ou lhe cause prejuizos. Não exite em apagar as "access keys" antigas que estão sem uso ou não exite em rotacionar suas "access keys" caso você suspeite de fazamento. Não deixe de conferir a documentação oficial da AWS.

DEV Community: Paulo Porto

AI-CLDD (AI-Change-Log Driven Development)

O problema: quando a IA esquece o porquê

A ideia central do ai-cldd

SYSTEM_BASE e FEATURE: separando contrato de mudança

SYSTEM_BASE (SB-*)

FEATURE Use Cases (UC-*)

Change-logs: a memória da IA

Estrutura esperada no projeto

O papel do ai-cldd-v1.yaml

O que o ai-cldd não é

Por que esse padrão importa

Conclusão

SSR vs SPA | Qual devo usar?

Evolução da linguagem Java (parte 5)

Java 19 e 20

Java 21

🧩 Record Patterns

🧠 Pattern Matching for switch

Java 22, 23 e 24

Java 25

Compact Source Files and Instance Main Methods

Importações de módulo simplificadas (Module Import Declarations)

Corpos de construtores flexíveis

Conclusão:

Evolução da linguagem Java (parte 4)

Java 15

Text Blocks

Java 16

Records

Pattern Matching para instanceof

toList() na Streams API.

Java 17

Sealed Classes

Switch Expressions

Java 18

Conclusão

Java language evolution (part 1)

Have you ever thought about how the Java language has evolved in recent years?

To start, the first great leap! From Java 4 to Java 5/6.

The forgotten but not less significant, Java 7

Let's talk about the second great leap! Java 8

Let's start with java.time

To finish, Lambda

Evolução da linguagem Java (parte 3)

Java 11

Novos métodos em String

Novo HttpClient

Java 12, 13 e 14.

Evolução da linguagem Java (parte 2)

Java 9

Novos métodos para criar coleções

Novos métodos para Streams API

Novos métodos para Optional

melhoria no Try-with-resources

Métodos privados em interfaces

Java 10

Evolução da linguagem Java (parte 1)

Você já pensou como a linguagem Java evoluiu nos últimos anos?

Para começar, o primeiro grande salto! Do Java 4 para Java 5/6

Esquecido mas não menos importante, Java 7

Vamos falar do segundo grande salto! Java 8

Gateway-Oriented Architecture (GOA)

🚪 What is GOA?

🎯 Who is GOA for?

🚫 When to avoid GOA?

🧩 What architectural patterns are adopted?

🚀 What are the benefits of GOA?

⚠️ Challenges and Mitigation Strategies

Challenge 1: Operational Complexity

Challenge 2: Single Point of Failure (SPOF)

📚 Usage Examples

Scenario 1 — New account creation

Scenario 2 — User authentication

Scenario 3 — Community creation

Scenario 4 — Viewing posts from a community

✅ Conclusion

Arquitetura Orientada a Gateways (GOA — Gateway-Oriented Architecture)

O que é a GOA?

Para quem é a GOA?

Pattern Matching para `instanceof`

`toList()` na Streams API.