DEV Community: Audrey-Albuquerque

Paginação Simples e Eficiente com Spring Data 🧙‍♂️

Audrey-Albuquerque — Sat, 25 Oct 2025 13:46:32 +0000

Fala, dev! Hoje vamos falar sobre um recurso essencial em qualquer API REST: paginação. Se você já teve que lidar com endpoints que retornam milhares de registros de uma vez, sabe o caos que isso pode causar. Vamos aprender a implementar paginação de forma elegante usando Spring Boot, e para deixar mais divertido, usaremos personagens do Senhor dos Anéis!

Por que paginar?

Imagine que você tem um endpoint que retorna todos os personagens da Terra Média. São centenas deles! Sem paginação, você teria problemas como:

Performance ruim: Carregar tudo de uma vez consome muita memória
Experiência do usuário prejudicada: Ninguém quer esperar 10 segundos para ver uma lista
Desperdício de recursos: Muitas vezes o usuário só quer ver os primeiros resultados

O que você precisa ter pronto? 📋

Antes de começar, certifique-se de que você já tem:

Uma entidade JPA (no nosso caso, Personagem)

@Entity
public class Personagem {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String nome;
    private String raca;
    private String arma;

    // Construtores, getters e setters
}

Um Repository que estende JpaRepository

public interface PersonagemRepository extends JpaRepository<Personagem, Long> {
    // O método findAll(Pageable) já vem pronto!
}

Um DTO de resposta (explicaremos o porquê logo abaixo!)

public class PersonagemResponseDTO {
    private Long id;
    private String nome;
    private String raca;
    private String arma;

    // Construtores, getters e setters
}

🎯 Por que usar DTO em vez de retornar a Entidade direto?

Essa é uma dúvida muito comum! Parece mais trabalho criar uma classe DTO só pra retornar os mesmos dados, né? Mas tem bons motivos:

1. Segurança e Controle

Sua entidade pode ter campos sensíveis (senha, dados internos) que você não quer expor na API

Com DTO, você escolhe exatamente o que vai na resposta

2. Desacoplamento

Mudanças no banco de dados (entidade) não quebram sua API

Você pode ter uma estrutura de banco diferente da estrutura de resposta

Exemplo: no banco você tem nome_completo, mas na API retorna nome e sobrenome separados

3. Performance

Você envia apenas os dados necessários pela rede

Evita serializar informações desnecessárias ou relacionamentos complexos

4. Versionamento de API

Fica mais fácil manter múltiplas versões da API (v1, v2) com DTOs diferentes usando a mesma entidade

Na prática: Sempre use DTOs em APIs REST profissionais. É uma das principais boas práticas de arquitetura! 💪

Uma Service com método de conversão

@Service
public class PersonagemService {

    private final PersonagemRepository repository;

    public PersonagemService(PersonagemRepository repository) {
        this.repository = repository;
    }

    private PersonagemResponseDTO entityParaResponseDTO(Personagem personagem) {
        return new PersonagemResponseDTO(
            personagem.getId(),
            personagem.getNome(),
            personagem.getRaca(),
            personagem.getArma()
        );
    }
}

Uma Controller REST

@RestController
@RequestMapping("/api/personagens")
public class PersonagemController {

    private final PersonagemService service;

    public PersonagemController(PersonagemService service) {
        this.service = service;
    }
}

Pronto! Com essa base, agora vamos adicionar a paginação! 🚀

Quero compartilhar o link do meu repositorio onde apliquei paginação:
https://github.com/eu-audrey/ApiNaruto

Mãos à obra! 🛠️

A boa notícia é que o Spring Data JPA torna isso super simples. Vamos precisar mexer apenas na Service e na Controller.

1. Implementando na Service Layer

public Page<PersonagemResponseDTO> listarPersonagensPaginado(Pageable pageable) {
    Page<Personagem> paginasDePersonagens = personagemRepository.findAll(pageable);
    return paginasDePersonagens.map(this::entityParaResponseDTO);
}

O que está acontecendo aqui?

Recebemos um objeto Pageable que contém todas as informações de paginação (página atual, tamanho, ordenação)
O método findAll(pageable) do repository já faz toda a mágica de paginar no banco de dados
Usamos map() para converter cada entidade em DTO, mantendo a estrutura de página

2. Criando o endpoint na Controller

@GetMapping
public ResponseEntity<List<PersonagemResponseDTO>> listarPersonagensPaginado(
    @PageableDefault(page = 0, size = 10, sort = "nome", direction = Sort.Direction.ASC) 
    Pageable pageable) {

    List<PersonagemResponseDTO> paginaDePersonagens = 
        personagemService.listarPersonagensPaginado(pageable).getContent();

    return ResponseEntity.ok(paginaDePersonagens);
}

Destrinchando o código:

@PageableDefault define valores padrão: primeira página, 10 itens por página, ordenado por nome
getContent() extrai apenas a lista de itens da página
O Spring automaticamente reconhece parâmetros de query como ?page=0&size=10&sort=nome,asc

Como usar na prática?

Agora você pode fazer requisições como:

# Primeira página com 10 personagens
GET /api/personagens?page=0&size=10

# Segunda página com 5 personagens, ordenados por raça
GET /api/personagens?page=1&size=5&sort=raca,asc

# Ordenação por múltiplos campos
GET /api/personagens?page=0&size=10&sort=raca,asc&sort=nome,asc

Testando tudo! 🧪

Testando manualmente dentro da aplicação

A forma mais rápida de testar é usando sua própria aplicação. Veja como:

1. Popule seu banco com dados de teste

Crie uma classe DataLoader para inserir personagens:

@Component
public class PersonagemDataLoader implements CommandLineRunner {

    private final PersonagemRepository repository;

    public PersonagemDataLoader(PersonagemRepository repository) {
        this.repository = repository;
    }

    @Override
    public void run(String... args) throws Exception {
        if (repository.count() == 0) {
            repository.saveAll(Arrays.asList(
                new Personagem(null, "Frodo", "Hobbit", "Bolseiro"),
                new Personagem(null, "Aragorn", "Humano", "Montante"),
                new Personagem(null, "Gandalf", "Maia", "Cajado"),
                new Personagem(null, "Legolas", "Elfo", "Arco e Flecha"),
                new Personagem(null, "Gimli", "Anão", "Machado"),
                new Personagem(null, "Sam", "Hobbit", "Panelas"),
                new Personagem(null, "Boromir", "Humano", "Espada e Escudo"),
                new Personagem(null, "Merry", "Hobbit", "Espada"),
                new Personagem(null, "Pippin", "Hobbit", "Espada"),
                new Personagem(null, "Galadriel", "Elfa", "Magia"),
                new Personagem(null, "Elrond", "Elfo", "Espada e Magia"),
                new Personagem(null, "Saruman", "Maia", "Cajado")
            ));
        }
    }
}

2. Use ferramentas como Postman, Insomnia ou cURL

# Teste básico
curl http://localhost:8080/api/personagens

# Teste com paginação customizada
curl "http://localhost:8080/api/personagens?page=1&size=3&sort=nome,desc"

3. Adicione logs temporários na Service

public Page<PersonagemResponseDTO> listarPersonagensPaginado(Pageable pageable) {
    System.out.println("Página solicitada: " + pageable.getPageNumber());
    System.out.println("Tamanho da página: " + pageable.getPageSize());
    System.out.println("Ordenação: " + pageable.getSort());

    Page<Personagem> paginasDePersonagens = personagemRepository.findAll(pageable);

    System.out.println("Total de elementos: " + paginasDePersonagens.getTotalElements());
    System.out.println("Total de páginas: " + paginasDePersonagens.getTotalPages());

    return paginasDePersonagens.map(this::entityParaResponseDTO);
}

4. Verifique o SQL gerado

Adicione isso no seu application.properties:

spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

Você verá o SQL com LIMIT e OFFSET sendo gerado automaticamente!

Testando com Testes Unitários

@SpringBootTest
@AutoConfigureMockMvc
class PersonagemControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    void deveRetornarPrimeiraPaginaComDezPersonagens() throws Exception {
        mockMvc.perform(get("/api/personagens")
                .param("page", "0")
                .param("size", "10"))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.length()").value(10));
    }

    @Test
    void deveOrdenarPersonagensPorNome() throws Exception {
        mockMvc.perform(get("/api/personagens")
                .param("sort", "nome,asc"))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$[0].nome").value("Aragorn"));
    }
}

📌 Nota sobre @Autowired: Nos testes, o @Autowired ainda é usado porque o MockMvc precisa ser injetado pelo framework de testes. Mas no código de produção (Service, Controller, DataLoader), sempre prefira injeção por construtor!

Por que usar Injeção por Construtor? 🤔

Você deve ter notado que no DataLoader usamos injeção por construtor ao invés de @Autowired no campo. Isso é uma boa prática muito recomendada! Aqui está o porquê:

Vantagens da Injeção por Construtor

1. Imutabilidade com final

private final PersonagemRepository repository;  // ✅ Pode ser final!

Com construtor, você pode marcar suas dependências como final, garantindo que elas nunca sejam alteradas após a criação do objeto. Com @Autowired no campo, isso não é possível.

2. Testabilidade

// Fica muito mais fácil testar!
PersonagemService service = new PersonagemService(mockRepository);

Você pode criar instâncias da classe manualmente em testes, sem precisar do Spring. Com @Autowired no campo, você fica preso ao container do Spring.

3. Dependências obrigatórias explícitas
O construtor deixa claro quais são as dependências necessárias. Se você tentar criar um objeto sem passar as dependências, o código nem compila! Com @Autowired, você só descobre em tempo de execução.

4. Menos "magia" do Spring
O código fica mais próximo do Java "puro", facilitando o entendimento por quem está aprendendo. Você vê claramente que está passando dependências, não precisa conhecer anotações específicas do Spring.

5. Código mais limpo
A partir do Spring 4.3, se você tem apenas um construtor, nem precisa da anotação @Autowired!

@Service
public class PersonagemService {

    private final PersonagemRepository repository;

    // Nem precisa de @Autowired aqui! O Spring injeta automaticamente
    public PersonagemService(PersonagemRepository repository) {
        this.repository = repository;
    }
}

Quando usar @Autowired então?

Em pouquíssimos casos:

Injeção em testes (como no MockMvc)
Campos opcionais com @Autowired(required = false)
Dependências circulares (mas isso geralmente indica problema de design!)

Resumo: Use injeção por construtor sempre que possível. É a forma mais profissional e recomendada pela comunidade Spring! 💪

Dicas importantes! 💡

Defina limites razoáveis: Evite permitir que o cliente solicite 10.000 itens de uma vez
Use indices no banco: Certifique-se de ter índices nas colunas usadas para ordenação
Considere retornar metadados: Em APIs REST maduras, é comum retornar informações como total de páginas e total de elementos

Conclusão

Paginação com Spring Boot é realmente simples! Com poucas linhas de código, você tem uma API profissional e eficiente. O Spring Data faz o trabalho pesado, e você só precisa conectar as peças.

Agora sua aplicação está pronta para lidar com a Sociedade do Anel inteira, e até mesmo todos os habitantes da Terra Média! 🗡️

Gostou do conteúdo? Deixe seu ❤️ e compartilhe com outros devs que estão começando com Spring Boot!

Tem dúvidas? Comenta aqui embaixo que a gente se ajuda! 🚀

Entendendo Interfaces em Java: O Modelo Que Garante Ordem no Seu Código

Audrey-Albuquerque — Fri, 24 Oct 2025 04:03:07 +0000

Olá, dev! 👋

Se você está mergulhando no mundo do Java e já se perguntou o que exatamente é uma interface, este post é pra você.

Vamos quebrar tudo em partes simples — sem enrolação — e entender por que as interfaces são tão poderosas e essenciais pra quem quer escrever código limpo, escalável e bem estruturado.

🎯 O Papel Fundamental de uma Interface em Java

Em poucas palavras, uma interface é um modelo (ou contrato) que uma classe se compromete a seguir.

Pense assim: ela define o que uma classe deve fazer, mas não como isso deve ser feito.

Quando uma classe “assina esse contrato”, ou seja, implementa uma interface, ela precisa cumprir todas as promessas definidas ali — implementando cada método que a interface declara.

👉 Em resumo:

A interface especifica obrigações — o que uma classe deve ter.
A classe garante a implementação — como ela vai fazer isso.

Um ótimo exemplo é o de uma classe Peixe que implementa as interfaces Presa e Predador .

Isso significa que um peixe pode tanto fugir de predadores quanto caçar peixes menores. 🐟⚔️

💡 Características-Chave das Interfaces

1. ✅ Suporte a Múltiplas Implementações

Essa é uma das maiores vantagens das interfaces: uma classe pode implementar várias interfaces ao mesmo tempo.

Diferente da herança tradicional, onde uma classe só pode ter uma superclasse, aqui você pode “misturar comportamentos” livremente.

📘 Exemplo:

public class Peixe implements Presa, Predador {
    ...
}

Nesse caso, o Peixe herda os métodos tanto de Presa quanto de Predador.
Resultado? O peixe pode caçar e também fugir.

2. 🧱 Métodos Abstratos por Padrão

Dentro de uma interface, os métodos são abstratos por padrão — ou seja, não têm corpo.
Você só declara o método, e quem for implementar é que define o comportamento.

📘 Exemplo:

public interface Presa {
    void fugir();
}

A classe que implementar essa interface precisa obrigatoriamente dizer o que o método fugir() vai fazer:

public class Coelho implements Presa {
    @Override
    public void fugir() {
        System.out.println("O coelho está fugindo!");
    }
}

Simples assim. 🐇💨

3. Implementação Obrigatória

Toda classe que usa (implements) uma interface precisa implementar todos os métodos declarados nessa interface.
Se não fizer isso, o compilador já reclama — sem dó nem piedade.

📘 Exemplo:

public class Hawk implements Predador {
    @Override
    public void ataca() {
        System.out.println("O falcão está atacando!");
    }
}

Se você tentar chamar falcao.fugir(), o método nem vai existir — afinal, Falcão só implementa Predador, não Presa.

4. Declaração de Variáveis

Assim como nas classes, é possível declarar variáveis dentro de uma interface.
Mas atenção: elas são automaticamente públicas, estáticas e finais (public static final).
Ou seja, funcionam como constantes que podem ser usadas por quem implementar a interface.

Exemplo Completo

Aqui está um exemplo completo com todas as classes mencionadas no vídeo:

// Interface Presa
public interface Presa {
    void flee();
}

// Interface Predador
public interface Predador {
    void hunt();
}

// Classe Coelho (implementa Presa)
public class Coelho implements Presa {
    @Override
    public void flee() {
        System.out.println("O coelho está fugindo saltitando!");
    }
}

// Classe Hawk (implementa Predador)
public class Hawk implements Predador {
    @Override
    public void hunt() {
        System.out.println("O falcão está atacando!");
    }
}

// Classe Peixe (implementa Presa e Predador)
public class Peixe implements Presa, Predador {
    @Override
    public void flee() {
        System.out.println("O peixe está fugindo de um peixe maior!");
    }

    @Override
    public void hunt() {
        System.out.println("O peixe está atacando um peixe menor");
    }
}

// Classe Principal
public class Main {
    public static void main(String[] args) {
        Coelho coelho = new Coelho();
        coelho.fugir();

        Falcao falcao = new Falcao();
        falcao.atacar();

        Peixe peixe = new Peixe();
        peixe.hunt();
        peixe.flee();
    }
}

Saída esperada:

O coelho está fugindo saltitando!
O falcão está atacando!
O peixe está fugindo de um peixe maior!
O peixe está atacando um peixe menor!

Conclusão

Pense nas interfaces como contratos ou modelos de comportamento.
Elas não dizem “como” algo deve ser feito, mas garantem que seja feito.

Elas são o coração da programação orientada a interfaces, que é uma das boas práticas mais poderosas no Java moderno.

Conceito	Explicação
O que é	Um contrato que define métodos que uma classe deve implementar
Palavra-chave	`implements`
Métodos	Abstratos por padrão (sem corpo)
Herança múltipla	Sim, pode implementar várias interfaces
Uso típico	Garantir comportamentos padronizados entre classes diferentes

Em resumo:

Interfaces trazem clareza, organização e flexibilidade. Elas são o jeitinho Java de dizer:

“Ei, se você quiser fazer parte desse grupo, siga essas regras!” 😄
E aí, já usou interfaces em algum projeto?

Monolito vs. Microsserviços: Um Guia Detalhado para Entender a Arquitetura de Software

Audrey-Albuquerque — Sun, 19 Oct 2025 23:15:29 +0000

Indo Além do Código: A Hora de Entender o "Porquê"

Olá! Chegou um momento importante na jornada de todo desenvolvedor: a hora de evoluir de apenas seguir tutoriais e focar em aulas práticas para realmente começar a entender a engenharia de software em um nível mais profundo. O objetivo é se tornar um(a) programador(a) que sabe não apenas o "como", mas principalmente o "porquê".

É necessário entender quando usar um monolito e quando usar microsserviços.

Muitas vezes nos deparamos com um paradoxo: por que tantas empresas pedem experiência em microsserviços em suas vagas, se a grande maioria das aplicações que conhecemos, incluindo as delas, foram construídas com base em monolitos? Você precisa entender essa dinâmica, porque se você não compreender o motivo por trás de uma decisão de arquitetura, você não vai entender completamente o que está construindo.

O que é um Monolito?

Vamos visualizar um cenário comum. Toda empresa precisa, no mínimo, de um cadastro de usuários. Então, para começar, nosso sistema precisará de:

Uma aplicação (usando Spring, por exemplo) para cadastrar os usuários.
Um banco de dados para armazenar as informações desses usuários.

Agora, vamos adicionar uma funcionalidade: esse usuário poderá fazer uma compra. Após a aprovação dessa compra, precisamos pegar os dados desse usuário, como endereço, nome completo e CPF, e enviar para o sistema de entrega.

Se estamos trabalhando com um monolito, todos esses sistemas — o de cadastro de pessoas, o de pagamentos com suas validações, e o de delivery — estarão contidos dentro da mesma aplicação, da mesma base de código.

O monolito é basicamente uma aplicação que faz tudo. É um sistema unificado que possui uma única codebase(o código em si) e, frequentemente, um único banco de dados para todas as suas funções.

Esse código único vai lidar com o

cadastro de usuários,
a autenticação,
o processamento do pagamento,
a consulta ao banco de dados para obter o endereço e, por fim,
acionar o serviço de entrega.

Tudo isso está dentro da mesma base de código. É um sistema unificado, um "bloco" único de código, e por isso o chamamos de monolito.

A Grande Vantagem do Monolito: A Comunicação

À primeira vista, parece a abordagem perfeita, certo? Em muitos aspectos, ela oferece grandes vantagens, principalmente na comunicação interna.

Vamos aprofundar nisso. No nosso exemplo, para saber se um usuário pagou, o sistema de entrega precisa dos dados do usuário.

Dentro de um monolito, ele simplesmente acessa a função ou a tabela do banco de dados que está ali, do lado, dentro do mesmo servidor.

Pense no monolito como a sua casa. Se você precisa de uma informação de alguém que mora na mesma casa que você, ela está no mesmo ambiente. É só perguntar, e a resposta vem de forma rápida e direta. Essa é a grande vantagem da comunicação em um monolito: ela é prática e veloz, pois tudo está "em casa".

E os Microsserviços?

Agora, como seria transformar esse mesmo produto em microsserviços? A ideia é que cada funcionalidade principal se torne um serviço independente e focado.

Microsserviços não são serviços pequenos, mas serviços especializados. E há uma diferença muito grande nisso.

Aqui, o cenário vai se complicar um pouco. Teríamos:

Um microsserviço de Usuários, com seu próprio banco de dados e rodando em seu próprio servidor.
Um microsserviço de Pagamentos, também com seu banco de dados e servidor independentes.
Um microsserviço de Delivery, seguindo o mesmo padrão.

Se cada um está em um servidor separado, com seu próprio banco de dados, como eles se comunicam?

Diferente do monolito, onde seu irmão estava na mesma casa, agora é como se ele morasse em outra cidade. Você não pode mais simplesmente "gritar" pela informação. Você precisa fazer uma "ligação", enviar uma mensagem via "whatsapp", ou seja, uma requisição de rede, seja via HTTP ou RPC (Remote Procedure Call).

O fluxo de comunicação se torna mais complexo:

O microsserviço de Usuário precisa enviar uma requisição para o de Pagamento para validar uma compra.
O serviço de Pagamento, uma vez que a compra é validada, precisa fazer uma consulta ao serviço de Usuário para obter o endereço de entrega.
Após receber o endereço, ele precisa enviar todas essas informações para o microsserviço de Delivery.

A Complexidade Adicional

Cada uma dessas comunicações entre serviços precisa ser autenticada. Nenhum serviço pode acessar o outro sem antes se identificar e provar que tem permissão. É como se ninguém pudesse entrar na sua casa sem se autenticar primeiro. Isso adiciona mais uma camada de complexidade ao sistema.

Toda vez que lidamos com microsserviços, estamos aumentando consideravelmente a complexidade do que estamos construindo.

O que antes era uma simples chamada de função dentro da mesma aplicação, agora se transforma em uma série de requisições de rede que precisam de autenticação, tratamento de falhas, latência e muito mais. Esse desafio de gerenciar e monitorar a comunicação e o estado de múltiplos serviços tem um nome: Observabilidade Distribuída (Distributed Observability).

Então, por que as empresas buscam Microsserviços?

Se é uma abordagem tão mais complexa, qual é a vantagem? A resposta, na maioria das vezes, se resume a uma palavra: dinheiro. E, mais especificamente, o estágio de maturidade e os recursos financeiros da empresa.

Mas antes, um fato crucial que responde à nossa pergunta inicial:

Praticamente todas as grandes aplicações que você já usou na vida começaram como monolitos.

É extremamente raro, talvez impossível, ver um novo projeto ou uma nova empresa começando do zero com uma arquitetura de microsserviços. O motivo é simples: monolitos são mais fáceis, rápidos e baratos para começar.

O Desafio do Monolito que Envelhece

Imagine uma codebase que começou lá em 2004. Com o passar dos anos, novas funcionalidades, regras de negócio e equipes foram adicionadas. O que acontece é que o monolito pode se tornar tão grande e complexo que a manutenção se torna um pesadelo.

Conflitos de Merge: Com uma equipe grande trabalhando na mesma codebase, a chance de um desenvolvedor, sem querer, quebrar a funcionalidade de outro ("skipar") é enorme.
Código Morto: Funcionalidades antigas e abandonadas se acumulam, e ninguém tem segurança para removê-las, gerando um código "inchado" e difícil de entender.
Dificuldade de Manutenção: Corrigir um bug ou adicionar uma nova feature pode se tornar uma tarefa lenta e arriscada, pois uma pequena mudança pode ter efeitos inesperados em outra parte do sistema.

Onde os Microsserviços Brilham

É nesse ponto que, quando uma empresa atinge um certo nível de maturidade e, principalmente, tem caixa (dinheiro) para investir, ela pode decidir migrar para uma arquitetura de microsserviços.

O motivo é estratégico e financeiro:

Times Especializados: Empresas grandes podem se dar ao luxo de ter um time focado apenas no serviço de pagamento, outro no de usuários, e assim por diante. Isso custa mais caro, mas permite que cada equipe desenvolva autonomia e expertise.
Escalabilidade Independente: Se o serviço de busca recebe 100x mais tráfego que o de faturamento, você pode escalar apenas o serviço de busca, otimizando o uso de recursos.
Resiliência: Se o serviço de envio de notificações falha, o sistema de pagamento e o de cadastro de produtos continuam funcionando normalmente.

A transição raramente é um "big bang". Geralmente, ela é gradual. A empresa pode, por exemplo, extrair o sistema de pagamentos do monolito e transformá-lo em um microsserviço que se comunica com o restante da aplicação. O Pinterest, por exemplo, possui microsserviços para comentários e notificações que operam junto ao seu sistema principal.

Conclusão: Qual é o melhor? Monolito ou Microsserviço?

Se você chegou até aqui, provavelmente já entendeu que essa é uma pergunta boba.

Não existe uma arquitetura "melhor" ou "pior" em termos absolutos. A escolha da arquitetura depende muito mais da maturidade do negócio, do tamanho da equipe e, claro, do orçamento, do que de uma preferência técnica. Como pessoa desenvolvedora, você não escolhe isso.

Monolitos: São excelentes para começar. São mais baratos, menos complexos e ideais para times menores e projetos em estágio inicial.
Microsserviços: São caros e complexos. Exigem times maiores, mais especializados e uma cultura de DevOps madura, mas oferecem escalabilidade, resiliência e autonomia para empresas em crescimento.

A realidade do mercado é esta: quase todas as empresas começam como monolitos e, com o tempo, o crescimento e os recursos, decidem migrar algumas (ou todas) as suas funcionalidades para microsserviços.

E aí, qual é a sua experiência com essas arquiteturas? Deixe um comentário

Cliente e Servidor: Definição e Interação

Audrey-Albuquerque — Tue, 01 Jul 2025 13:00:49 +0000

Antes de começar eu tenho algumas perguntas pra te fazer:
Em primeiro lugar, uma pergunta simples, mas muito importante.
Você sabe a diferença entre um cliente e um servidor para a infraestrutura da internet?
Você sabe diferenciar basicamente dentro de uma infraestrutura de redes, o que é um cliente suas tarefas?
e o que é um servidor e suas tarefas?
Outra coisa, você sabe diferenciar as tecnologias HTML, CSS, JavaScript e o que cada uma faz?
Quais são as especialidades de cada uma? Para que cada uma serve?

No modelo da infraestrutura da internet, o cliente é o seu dispositivo, ou seja, é um computador ou um celular, que está solicitando ou utilizando um serviço.

O servidor, por sua vez, é a máquina de alta performance que fornece os dados ou serviços necessários ao cliente.

Neste exato momento você está lendo esse conteúdo com seu computador ligado, ou até mesmo no celular. Pois saiba que o seu computador
ou celular são os nossos clientes. No momento em que você usa um dispositivo, ele é um cliente e precisa de dados de um servidor, às vezes até mais de um servidor.

E como você faz esse acesso na internet? Você usa um navegador.

Você está utilizando um serviço que está sendo fornecido por um servidor
nesse exato momento, por exemplo, você está pegando dados dos servidores do Dev.to.

Esses servidores, essas máquinas de alta performance são quem estão fornecendo os dados.

Esse servidor é parecido com a sua máquina de maneira fundamental. Ele tem um sistema operacional, ele tem pastas, ele tem diretórios internos. Dentro dessas pastas ele tem arquivos.
Esse arquivo é no que você está interessado. Pode ser uma foto, pode ser um texto, pode ser um vídeo. E na maioria das vezes é um documento HTML.

A interação funciona da seguinte forma:

• O cliente, através de um navegador ( Google Chrome, Edge, Mozilla, etc), digita uma URL (endereço) e envia uma solicitação para a infraestrutura da internet.
• Essa infraestrutura (representada como uma "nuvem") direciona a solicitação para um servidor específico.
• O servidor possui arquivos (como documentos HTML, imagens, textos ou vídeos) armazenados em suas pastas e diretórios.
• Ao receber a solicitação, o servidor envia uma cópia desse arquivo para o navegador do cliente.
Essa cópia é enviada diretamente para o cliente, você. No seu navegador web.
O seu navegador a partir daí vai começar a trabalhar para gerar o efeito visual, para gerar o site exatamente como você está vendo agora
• O navegador do cliente, então, trabalha para gerar o efeito visual e exibir o site conforme o usuário o vê.
Em resumo, o cliente busca arquivos, e os servidores os enviam. Existem tecnologias para clientes (client-side) e tecnologias para servidores (server-side).

O Papel do JavaScript no Modelo Cliente-Servidor

Historicamente, o JavaScript surgiu como uma tecnologia exclusivamente para clientes (client-side). Isso significa que seu foco inicial e principal no curso é a interatividade e a manipulação de elementos diretamente no navegador do usuário1011.

No entanto, as fontes destacam que o JavaScript evoluiu e, com o surgimento do Node.js em 2009 (baseado no motor V8 do Google Chrome), ele pode ser executado também no lado do servidor (server-side).
Para o desenvolvimento de sites do lado do cliente, o JavaScript trabalha em conjunto com outras duas tecnologias essenciais:

• HTML (HyperText Markup Language): Responsável pelo conteúdo e pela estrutura do site. É comparado a um jornalista que escreve o texto e organiza o material11....
• CSS (Cascading Style Sheets): Encarregado do estilo e do design visual do site, tornando-o mais atraente. É comparado a um designer que organiza cores, tamanhos e posições....
• JavaScript: Adiciona a interatividade e as integrações. É a "parte do programador" que trata da engenharia da entrega e da dinâmica do jornal/site.

É crucial entender que HTML e CSS não são linguagens de programação, mas sim tecnologias de construção de sites, enquanto o JavaScript é uma linguagem de programação completa.

Essas três tecnologias funcionam em conjunto para compor a parte do cliente na maioria dos sites modernos

Como criar uma imagem Mysql no Docker e conectar ao Dbeaver 😉

Audrey-Albuquerque — Sun, 12 Jan 2025 03:23:05 +0000

Por que usar Docker e DBeaver para trabalhar com MySQL?

Se você já trabalhou com bancos de dados, sabe que configurar tudo direitinho no seu computador pode ser complicado e demorado. Felizmente, temos algumas ferramentas que tornam isso muito mais fácil, como o Docker e o DBeaver. Vou te explicar um pouco sobre elas e como elas podem te ajudar a criar e gerenciar bancos de dados de forma rápida e simples.

O que é o Docker e por que usá-lo?

O Docker é uma ferramenta que ajuda a criar ambientes de desenvolvimento, ou seja, é como se você tivesse uma "caixinha" que já vem pronta para rodar um software, sem precisar se preocupar em configurar tudo do zero. Imagine que você quer usar o MySQL, um dos bancos de dados mais populares, mas não quer perder tempo instalando e configurando ele manualmente. O Docker te ajuda com isso!

Exemplo: Você quer rodar um banco de dados MySQL no seu computador, mas não quer precisar instalar o MySQL de verdade. Com o Docker, você pode "rodar" uma versão do MySQL dentro de uma "caixa" virtual, chamada container, e essa "caixa" já vem com tudo o que o MySQL precisa para funcionar. Ou seja, você não precisa configurar nada manualmente!

Facilidade: Usar o Docker é rápido e fácil. Você pode rodar o MySQL em minutos sem se preocupar com complicação.
Consistência: O legal do Docker é que, quando você cria um ambiente, ele funciona do mesmo jeito em qualquer computador. Isso significa que, se você tiver um colega de trabalho e ele rodar o mesmo banco de dados no Docker, tudo vai funcionar igualzinho no computador dele!

O que é o DBeaver e por que usá-lo?

Agora que você tem o MySQL rodando no Docker, precisa de uma ferramenta para visualizar e interagir com o banco de dados de forma fácil, certo? É aí que entra o DBeaver. O DBeaver é um programa que permite que você se conecte ao MySQL (e outros bancos de dados também) e faça tudo o que precisa: criar tabelas, adicionar dados, rodar comandos SQL e muito mais, tudo com uma interface bem simples e bonita.

Exemplo: Quando você abre o DBeaver, ele vai mostrar uma tela onde você pode clicar para ver as tabelas que você criou no MySQL, inserir novos dados ou até rodar consultas (comandos SQL) para pegar informações específicas.

Interface fácil de usar: Mesmo que você seja iniciante, o DBeaver facilita porque tem uma interface gráfica. Ao invés de digitar tudo em comandos, você pode clicar e fazer as coisas de maneira visual.
Multibanco de dados: O DBeaver não serve só para MySQL, você pode conectar a vários tipos de bancos de dados ao mesmo tempo, tudo em um único programa!
➡️Por que essa combinação é tão boa?
Juntar o Docker e o DBeaver é uma solução simples e poderosa. O Docker facilita a instalação e o gerenciamento do banco de dados (no nosso caso, o MySQL), enquanto o DBeaver te ajuda a gerenciar os dados de forma bem mais prática e visual.

Exemplo final: Com o Docker, você instala o MySQL em minutos e, com o DBeaver, você consegue visualizar e trabalhar com os dados de forma fácil. Juntas, essas ferramentas são uma excelente escolha para quem quer ganhar tempo e evitar complicação na hora de trabalhar com banco de dados.

Pré-requisitos: Aplicativos Necessários

Antes de começar, certifique-se de ter os seguintes aplicativos instalados em sua máquina:

Docker Desktop: Necessário para criar e gerenciar containers, como o banco de dados MySQL.
Baixe aqui: https://www.docker.com/

DBeaver: Ferramenta para gerenciar bancos de dados e testar conexões com o MySQL.

Baixe o DBeaver aqui: https://dbeaver.io/download/

1. Criação do Container Docker para MySQL

Para começar, precisamos criar um container Docker que hospedará nosso banco de dados MySQL. Abra seu app Docker Desktop

Clique em Abrir. Minimize e abra o CMD como administrador e siga os passos abaixo:

Comando para criar o container

Execute o seguinte comando no terminal:`

docker run --name meu_db -e MYSQL_ROOT_PASSWORD=senha123 -e MYSQL_DATABASE=gerenciador_contato -p 3306:3306 -d mysql:8

Explicação:

--name meu_db: meu_db deve ser alterado por você, é aqui que você define o nome do seu container.

-e MYSQL_ROOT_PASSWORD=senha123: Configura a senha do usuário root como "senha123".

-e MYSQL_DATABASE=gerenciador_contato: Aqui você dá o nome desejado para o banco de dados. Dixamos como chamado "gerenciador_contato".

-p 3306:3306: Mapeia a porta 3306 do MySQL no container para a mesma porta na máquina local.

-d mysql:8: Usa a imagem MySQL versão 8 e roda o container em segundo plano.

Pronto! O banco de dados está rodando no Docker.

2. Conexão e Teste no DBeaver

Com o container MySQL rodando, vamos conectar no banco pelo DBeaver:

Passo 1: Configuração da conexão

Abra o DBeaver e clique em File > New Database Connection.

Escolha "MySQL" na lista de bancos de dados.

Configure os seguintes campos com os dados que você coloccou na criaçao do container Docker

Host: localhost

Port: 3306

Database: gerenciador_contato

Username: root

Password: senha123

Clique em Test Connection.

Se tudo estiver correto, o DBeaver se conectará ao banco com sucesso!

Para mim ocorreu uma menagem de erro de PublicKeyRetrieval. Se esse for o seu caso também, vá na aba Propriedades do Driver e escreva true na allowPublicKeyRetrieval

E a mensagem de Conectado deve aparecer

Dicas de SQL para Iniciantes: Consultando Proprietários de Animais de Estimação (Joins)

Audrey-Albuquerque — Tue, 08 Oct 2024 20:22:08 +0000

O SGBD escolhido para essa amostra foi o MySql, e seu Workbench.

Vamos criar um banco de dados.

Imagine que temos um hotelzinho de pets e vamos hospedar Gatos e Caezinhos. Precisamos também ter o nome de seus donos, chamaremos essa tabela de Pessoa.

As tabelas serão simples para focar no conceito.

Explicando o Projeto

Tabelas:

Gato: 🐈‍⬛contém os gatos que estão no hotelzinho.

id_gato
nome_gato
id_pessoa

Cachorro: 🐕‍🦺contém os cachorros que estão no hotelzinho.

id_cachorro
nome_cachorro
id_pessoa

Pessoa: 🚶🏻‍♂️contém as pessoas que são donas dos pets.

id_pessoa
nome_pessoa
cpf

Criando o Banco

Vamos iniciar nosso banco:

Logo que abrimos os schemas temos a query1. Vamos utilizá-la.
Digitamos o comando:

CREATE DATABASE hotelzinho;

e em seguida o raiozinho com o número 1.
Esse botão nos permite executar uma linha de cada vez.

o check verdinho indica que tudo deu certo na criação do nosso Banco

e você pode salvar esse Script, indo em File, save Script as :

Aqui eu salvei como HotelzinhoPets em uma pasta somente de Scripts Sql que facilitam a minha vida.😄

Para criarmos tabelas dentro do nosso banco hotelzinho temos que indicar que queremos usar o banco. Para isso precisamos do comando:
USE hotelzinho;

Para executar um comando no MySQL Workbench, basta posicionar o cursor na linha desejada e clicar no botão: "Execute o comando debaixo do meu cursor". Eu prefiro chamar esse botão de "raio único", ok? 😊

Quando o comando for executado com sucesso, um check verde aparecerá, indicando que tudo está correto.

Criando as Tabelas

Agora, vamos criar as tabelas Pessoa, Gato e Cachorro.

⚠️ Dica: Se você preferir usar os nomes das tabelas no plural (como Gatos, Cachorros e Pessoas), certifique-se de que todas as tabelas sigam esse padrão. Isso mantém o projeto dentro das boas práticas de consistência na nomeação.

Vamos criar a tabela Pessoa primeiro, pois ela será a nossa chave estrangeira nas outras duas tabelas:

Este comando cria uma tabela chamada Pessoa que armazena informações sobre pessoas, com três colunas: id_pessoa, nome_pessoa e cpf.

A coluna id_pessoa é um identificador único que se incrementa automaticamente, enquanto nome_pessoa e cpf devem ser fornecidos sempre que uma nova pessoa é adicionada, garantindo que o CPF seja único na tabela.

Em seguida, as demais tabelas:

Nessas outras tabelas Cachorro e Gato, podemos dar um nome que faça mais sentido para o dono do pet. Por exemplo, podemos chamar a pessoa de Proprietário na tabela Gato, o que torna a relação mais intuitiva.
Dessa forma, o nome da coluna será id_proprietario, e ela ainda funcionará como uma Foreign Key, referenciando a chave primária da tabela Pessoa.

Isso deixa claro tanto o propósito da coluna quanto o processo de criação da chave estrangeira, mantendo a integridade do banco de dados.

Posicione o cursor em cima da primeira linha de cada comando de criação de tabela e clique no botão raio único para executar, uma tabela de cada vez. Isso permite que você crie as tabelas separadamente e garanta que cada uma seja processada corretamente.

sucesso!

Até o momento, usamos comandos DDL (Data Definition Language) do SQL, que são responsáveis pela definição e estruturação do banco de dados. Esses comandos incluem a criação de tabelas e a definição de chaves estrangeiras, como vimos nos exemplos anteriores.

Inserindo Valores nas Tabelas

A partir de agora, vamos usar um pouco de DML (Data Manipulation Language), que é responsável por manipular nossos dados. Com esses comandos, vamos inserir valores nas colunas das tabelas que criamos para podermos utilizar os Joins em seguida.

Para inserir os dados em uma tabela em que o Id é do tipo Auto_increment, não é necessário lhe dar algum valor. Isso é feito automaticamente.

Usamos o comando INSERT INTO seguido do nome da tabela. Em seguida, abrimos parênteses e digitamos os nomes das colunas que queremos popular. Fechamos os parênteses e acrescentamos a palavra VALUES.

Para cada registro, abrimos parênteses, inserimos os valores separados por vírgula, e, quando chegamos ao final, usamos o ponto e vírgula para finalizar o comando.

Ao final da inserção de cada tabela, é importante clicar no Raio único, para que a próxima tabela possa usar corretamente o id_proprietario ao referenciar a tabela Pessoa. Isso garante que o relacionamento entre as tabelas seja feito corretamente.

Fazemos isso também com as demais tabelas, garantindo que cada uma seja inserida e relacionada adequadamente.

Consultando as tabelas

Com o comando SELECT * FROM seguido do nome da tabela, podemos visualizar todos os valores presentes nela. A sintaxe é a seguinte:

1. INNER JOIN - Listando todas as Pessoas que têm gatos no hotelzinho

Agora, precisamos saber a lista de todas as pessoas que deixaram seus gatos em nosso hotel. Queremos ofertar uma raçao especial para estes proprietários de gatos.

SELECT 
    Pessoa.nome_pessoa,
        Gato.nome
FROM
        Pessoa
INNER JOIN
        Gato
ON
        Pessoa.id_pessoa = Gato.id_proprietario;

Traduzindo a Consulta:

Select Pessoa.nome_pessoa, Gato.nome
isso é o que eu preciso na minha consulta:
o nome da pessoa, na tabela Pessoa, e o nome na tabela Gato.
Poderiam ter mais atributos, como telefone, se fosse o caso, ou o cpf, email, etc

Em seguida
FROM Pessoa INNER JOIN Gato

FROM: Esta palavra-chave indica de qual tabela queremos recuperar os dados.
Pessoa: Estamos especificando que a tabela principal de onde vamos buscar os dados é a tabela Pessoa. Ou seja, as informações que você obtém inicialmente virão desta tabela.

INNER JOIN: Este comando indica que estamos combinando (ou "juntando") a tabela Pessoa com outra tabela, que neste caso é a tabela Gato. O INNER JOIN retorna apenas as linhas que têm correspondência em ambas as tabelas.

Gato: Estamos especificando que a segunda tabela que queremos juntar à tabela Pessoa é a tabela Gato. Isso significa que estamos interessados em obter dados de ambas as tabelas.

ON Pessoa.id_pessoa = Gato.id_proprietario;
ON aqui podemos entender o ON como um EM QUE o id_pessoa na tabela Pessoa seja igual ao id_proprietario na tabela Gato.

2. LEFT JOIN:

SELECT 
    Pessoa.nome_pessoa, 
    Gato.nome 
FROM 
    Pessoa 
LEFT JOIN 
    Gato 
ON 
    Pessoa.id_pessoa = Gato.id_proprietario;

O LEFT JOIN é como se você estivesse dizendo: "Quero ver todas as pessoas, e se elas tiverem gatos, mostre os gatos também. Se não tiver, tudo bem, só mostre as pessoas mesmo!"

Dessa forma, o LEFT JOIN garante que todas as Pessoa sejam vistos, mesmo que alguns não tenham Gato.

Note que Roberto Carlos e a Mariana não tem gato, mas estão aparecendo. Esse é o Left Join.

3. RIGHT JOIN

O RIGHT JOIN retorna todas as linhas da tabela à direita (Cachorro) e as linhas correspondentes da tabela à esquerda (Pessoa). Se não houver correspondência, os resultados da tabela à esquerda serão NULL.


SELECT 
    Pessoa.nome_pessoa, 
    Cachorro.nome 
FROM 
    Pessoa 
RIGHT JOIN 
    Cachorro 
ON 
    Pessoa.id_pessoa = Cachorro.id_proprietario;

Esse comando retorna todos os cachorros, incluindo aqueles que não têm um proprietário registrado. Mas no nosso hotelzinho todos os cachorros tem seus proprietários, por isso nao tivemos um null.

4. FULL OUTER JOIN

O FULL OUTER JOIN retorna todas as linhas quando há uma correspondência em uma das tabelas. Porém, esse tipo de JOIN não é suportado diretamente pelo MySQL. Você pode simular um FULL OUTER JOIN usando a combinação de LEFT JOIN e RIGHT JOIN.

Se por exemplo tivéssemos Gatos sem o id_proprietario apareceria aqui com essa consulta:

SELECT 
    Pessoa.nome_pessoa, 
    Gato.nome 
FROM 
    Pessoa 
LEFT JOIN 
    Gato 
ON 
    Pessoa.id_pessoa = Gato.id_proprietario

UNION

SELECT 
    Pessoa.nome_pessoa, 
    Gato.nome

FROM 
    Pessoa 
RIGHT JOIN 
    Gato 
ON 
    Pessoa.id_pessoa = Gato.id_proprietario;

Agora precisamos de uma última consulta. Precisamos de uma listagem por Pessoa de todos os animais que elas tem. Cachorros, Gatos ou ambos

SELECT 
    Pessoa.nome_pessoa,cpf,
    Gato.nome AS nome_gato,
    Cachorro.nome AS nome_cachorro
FROM 
    Pessoa
LEFT JOIN 
    Gato ON Pessoa.id_pessoa = Gato.id_proprietario
LEFT JOIN 
    Cachorro ON Pessoa.id_pessoa = Cachorro.id_proprietario;

Explicação da Consulta

SELECT: Estamos selecionando o nome da pessoa, o cpf dela; o nome do gato e o nome do cachorro. E como quero identificar os nomes dos animais de um modo mais específico, passo Gato.nome As nome_gato. A palavra-chave AS significa Como

FROM: Começamos pela tabela Pessoa, que é a nossa tabela principal.

LEFT JOIN:

Gato: Estamos unindo a tabela Gato à tabela Pessoa usando a coluna id_proprietario. Isso traz os gatos dos proprietários.
Cachorro: Fazemos o mesmo para a tabela Cachorro.
Resultado: Esta consulta retorna todos os proprietários. Se um proprietário não tiver um gato ou um cachorro, o resultado mostrará NULL (ou uma célula em branco, dependendo do cliente SQL que você está usando).