O Que é Graceful Shutdown e Por Que Ele é Importante?

O graceful shutdown é um mecanismo que permite a um servidor web pausar a aceitação de novas requisições enquanto conclui as que estão em andamento, liberando recursos de forma ordenada. Embora não seja exclusivo do Spring Boot — sendo um conceito comum em servidores web e frameworks como Node.js, Django e Quarkus —, o Spring Boot oferece uma implementação poderosa e integrada ao seu ciclo de vida. Introduzido na versão 2.3 (2020), o graceful shutdown é essencial para aplicações em produção, especialmente em ambientes de microservices ou orquestrados por Kubernetes, onde atualizações e escalonamentos são frequentes.

Sem esse recurso, um desligamento forçado pode interromper requisições ativas, causar inconsistências em bancos de dados ou deixar conexões abertas, impactando a confiabilidade. Com o graceful shutdown, sua aplicação ganha um “período de graça” para finalizar tarefas, garantindo maior resiliência e uma manutenção mais suave.

Como Funciona o Graceful Shutdown no Spring Boot

O Spring Boot suporta o graceful shutdown para servidores web embutidos como Tomcat, Jetty, Undertow e Netty. Quando ativado, o processo segue estas etapas:

1. Captura de Sinais de Shutdown: O Spring registra hooks na JVM para detectar sinais como SIGTERM, comuns em containers Docker ou pods Kubernetes, iniciando um encerramento controlado.

2. Bloqueio de Novas Requisições: O servidor para de aceitar novas conexões:

• Tomcat e Netty: Rejeitam conexões no nível de rede.
• Undertow: Retorna HTTP 503 (Service Unavailable) para novas requisições.
• Jetty: Fecha novos sockets, mas permite conclusão de requisições ativas.

3. Conclusão de Requisições Ativas: Requisições em andamento têm um tempo limite configurável para finalizar. Se ultrapassarem, o shutdown prossegue, mas com liberação de recursos.

4. Fechamento de Recursos: Beans com métodos @PreDestroy são invocados para liberar recursos como conexões de banco de dados, pools de threads ou clientes externos.

Esse processo é gerenciado pelo ciclo de vida do ApplicationContext, funcionando tanto em aplicações baseadas em Servlet quanto em aplicações reativas com WebFlux.

Configurando o Graceful Shutdown

A configuração no Spring Boot é simples e feita no arquivo application.properties ou application.yml. Exemplo em YAML:

server:
  shutdown: graceful

spring:
  lifecycle:
    timeout-per-shutdown-phase: 45s

• server.shutdown: graceful: Ativa o modo gracioso (o default é immediate, que desliga instantaneamente).
• spring.lifecycle.timeout-per-shutdown-phase: Define o período de graça para conclusão de requisições (ex.: 10s para 10 segundos).

Para testar, inicie sua aplicação, envie requisições e simule um shutdown com kill -SIGTERM <pid> ou Ctrl+C. Monitore os logs para verificar se as requisições ativas são concluídas e os recursos liberados corretamente.

Em ambientes orquestrados, como Kubernetes, combine com readiness probes para sinalizar que o pod não está mais pronto para receber tráfego, evitando requisições durante o shutdown. Ajuste o terminationGracePeriodSeconds no manifesto do pod para alinhar com o timeout configurado.

Atualizações Recentes no Spring Boot (Até 2025)

O graceful shutdown é um recurso consolidado desde o Spring Boot 2.3, mas melhorias incrementais nas versões 3.x e 4.x (2024–2025) trouxeram refinamentos:

• Ciclo de Vida Aprimorado: O Spring Boot 3.3.x (2024) melhorou o DefaultLifecycleProcessor, garantindo uma ordem mais confiável na destruição de beans, especialmente para conexões Redis e RabbitMQ, evitando fechamentos prematuros.
• Suporte a WebFlux: Em aplicações reativas, o graceful shutdown agora lida melhor com fluxos assíncronos, mas operações longas podem exigir ajustes manuais de timeout para evitar bloqueios no Netty.
• Spring Boot 4.0-M2 (2025): Focado em compatibilidade com Java 21 e Jakarta EE 10, não introduziu mudanças diretas no graceful shutdown, mas melhorias em dependências como Tomcat 10.1 e Jetty 12 otimizam a performance do shutdown.
• Spring Cloud: Em arquiteturas de microservices, o graceful shutdown agora integra melhor com balanceadores de carga, permitindo que serviços como Eureka marquem instâncias como “DOWN” antes do shutdown.

Sempre consulte as notas de release da sua versão no repositório oficial do Spring Boot para detalhes específicos.

Conclusão

O graceful shutdown é uma prática indispensável para aplicações modernas, e o Spring Boot oferece uma implementação robusta e fácil de configurar. Com ajustes simples no application.yml e atenção a recursos personalizados, você garante que sua aplicação encerre com elegância, protegendo dados e usuários. À medida que o Spring Boot evolui, melhorias no ciclo de vida e suporte a novos servidores tornam o recurso ainda mais confiável.

Teste o graceful shutdown em seu próximo deploy e veja como ele eleva a confiabilidade da sua aplicação.

Este texto não é um tutorial, nem uma explicação técnica sobre Protobuf. É mais um convite para refletirmos juntos sobre os desafios e peculiaridades que enfrentamos com ele. Espero que vocês se identifiquem com esse sentimento e compreendam o que tentei expressar aqui.

ProtoBuff (Protocol Buffers) é, na essência, uma maneira eficiente de serializar dados, ou seja, transformar objetos em um formato que possa ser facilmente transmitido ou armazenado. Teoricamente, é a solução perfeita para lidar com grandes volumes de dados, substituindo formatos mais verbosos como XML ou JSON. Na prática, no entanto, essa “pitada de serialização misteriosa” é o que mantém a vida do desenvolvedor mais empolgante, rs.

A cada nova tecnologia, uma promessa: “isso vai facilitar sua vida.” Mas, como desenvolvedores, sabemos que toda escolha vem com suas peculiaridades. E é aqui que entra ProtoBuff, uma ferramenta poderosa de serialização que promete simplicidade, desempenho e economia de espaço. Mas, como qualquer tecnologia robusta, também vem com seus próprios enigmas.

Primeiro desafio

Lidar com ProtoBuff é como entrar em um clube exclusivo: só quem entendeu suas peculiaridades pode realmente apreciar sua beleza. ProtoBuff exige que você defina um esquema de dados, uma estrutura que mapeia o que pode ser transmitido ou recebido. Isso é fantástico para garantir que seu sistema tenha dados consistentes e bem organizados.

Além disso, há a “mágica” por trás da compactação de dados. Enquanto ProtoBuff realmente reduz o tamanho das mensagens transmitidas, o que é ótimo para desempenho, às vezes o resultado final parece uma caixa preta. Você envia um dado para o sistema e recebe algo que parece saído de um romance criptográfico. É neste momento que o desenvolvedor se depara com a realidade: “isso é incrível, mas como eu debugo isso?”.

Talvez essa seja a beleza de trabalhar com ProtoBuff. Ele te desafia. Ele não entrega tudo de bandeja. Cada vez que você encontra uma nova peculiaridade, você mergulha mais fundo na compreensão de como seus dados são processados e otimizados. E, no fim do dia, ao resolver aquele “mistério” técnico, a sensação de vitória é indescritível.

Então, sim, ProtoBuff é eficiente, é poderoso, mas, acima de tudo, traz uma camada de complexidade que faz com que o trabalho de serializar e desserializar dados seja mais do que uma tarefa técnica: torna-se uma pequena aventura. Afinal, a vida de um desenvolvedor seria bem menos emocionante sem essa pitada de serialização misteriosa.

Mais sobre Protobuf

Varda, K. Protocol Buffers: A Simple Way to Serialize Data. Google Developers, 2023. Disponível em: developers.google.com/protocol-buffers. Um guia técnico oficial sobre o Protobuf, explicando seu funcionamento e aplicação em ambientes de alto desempenho como gRPC.

Utilizando o Hibernate Dynamic Update em entidades que contém mapeamento JSON em colunas de uma tabela.

Para fins didáticos, vamos utilizar a entidade Product. Utilizando Hibernate 6

Disclaimer

Hibernate ORM não contém suporte para colunas do tipo JSON, então nesse exemplo estou utilizando a lib Hypersistence Utils, que fornece um JsonType que permite mapear objetos como String, Map, List, JsonNode ou Pojos em colunas colunas JSON, indepedente de banco de dados (PostgreSQL, MySQL ou H2 por exemplo).

Continuando..

A coluna properties da nossa tabela nesse exemplo está sendo mapeada como jsonb do PostgreSQL, por isso utiliza o JsonType da lib mencionada acima.

Problema

Quando atualizamos uma entidade do Hibernate sem o Dynamic Update, por padrão, após modificar uma entidade

O Hibernate executa uma instrução UPDATE que inclui todos os atributos da entidade, mesmo que eles não tenham sido modificados

Analisando a instrução executada podemos ver que o atributo properties da tabela product também foi incluído, ou seja, quanto maior o objeto JSON, maior será o impacto no desempenho da execução, pois está enviando dados desnecessários.

Solução

A anotação @DynamicUpdate garante que o Hibernate utilize apenas as colunas alteradas na instrução SQL, ou seja

Muito melhor, concorda? Então concordamos que sempre devemos utilizar essa anotação "mágica", certo? Errado!

Acabamos de ver os prós e concordamos que uma instrução SQL gigante que contenha colunas JSON gigantescas podem se beneficiar com o Hibernate Dynamic Update

Como o Hibernate Dynamic Update funciona

Primeiro precisamos saber que o Hibernate utiliza um sistema de cache para gerar as atualizações SQL, mas quando usamos a anotação @DynamicUpdate, o Hibernate precisa gerar uma nova instrução SQL. Este SQL gerado inclui apenas as colunas alteradas.

O Hibernate precisa identificar o estado da entidade atual para descobrir quais colunas foram alteradas, ou seja, quando alteramos qualquer campo de uma entidade, ela compara os estados atual e modificado para saber quais campos foram alterados.

Conclusão

Saber quando utilizá-lo é imprescindível.

Referência

• https://thorben-janssen.com/dynamic-inserts-and-updates-with-spring-data-jpa/

O que vem primeiro autorização ou autenticação

Não podemos autorizar um usuário ou serviço antes de identificá-lo, ou seja, a autenticação sempre vem antes da autorização.

Semelhanças

Autenticação e autorização são semelhantes porque são duas partes implícitas do processo que fornecem acesso. Com isto, ambos são confundidos, um dos motivos de serem confundidos é que compartilham a mesma abreviação auth.

Diferenças

Autenticação e Autorização podem ter semelhanças, mas cada uma tem um papel diferente na proteção de uma aplicação. Um verifica uma identidade antes de conceder acesso, enquanto o outro usa essa identidade verificada para controlar o acesso.

Vamos ver um exemplo com um cenário bem básico?

Digamos que você esteja indo visitar um parente bem próximo. Ao chegar, você toca o interfone e seu parente te reconhece (autenticação), como seu parente lhe reconheceu (autenticou), o mesmo permite deixá-lo entrar em sua casa. Porém, com base no seu nível de relacionamento, existem certas coisas que você pode e outras não (autorização). Por exemplo, você pode entrar na sala de estar, mas não pode entrar no escritório particular do seu parente, ou seja, você tem autorização para entrar na cozinha, mas é proibido o acesso ao escritório particular.

Alguns tipos de autenticação

O mais comum, para verificar a identidade de um usuário, os processos de autenticação utilizam algo que o usuário — tem — sabe, por exemplo:

Na categoria:

— você sabe senhas e perguntas de segurança são fatores de autenticação.

— você tem tokens de segurança USB, celular e outros dispositivos físicos são fatores de autenticação.

Alguns tipos de autorização

Toda aplicação têm (ou deveria ter) um controle de acesso aplicando regras de permissão com base no nível de autorização do usuário, por exemplo, geralmente existem usuários comuns e/ou administradores. Se um usuário padrão quer deletar algo, possivelmente seu acesso será negado, mas os administradores têm autorização para realizar esse tipo de alteração.

Outro tipo comum é o controle de acesso aos dados, usuários comuns tem visibilidade de dados que normalmente são públicos e que podem ser expostos, já usuários administradores conseguem visualizar dados confidenciais. Neste exemplo, a autorização determina quais usuários podem acessar os diversos tipos de dados.

Controle de acesso

A autorização define políticas sobre o que um usuário ou serviço pode acessar. O controle de acesso impõe essas políticas.

Embora muitas políticas de autorização façam parte do controle de acesso, o controle de acesso é um componente da autorização. O controle de acesso utiliza o processo de autorização para conceder ou negar acesso a aplicação ou aos dados da mesma.

Se compararmos autenticação e controle de acesso, a comparação entre autenticação e autorização ainda se aplica. A autenticação verifica a identidade do usuário e o controle de acesso usa essa identidade para conceder ou negar acesso.

Referências

• Auth0
• Javapoint

A Keycloak é um produto open source da Red Hat, cuja versão enterprise é o Red Hat Single Sign-On, que permite o login único com o Gerenciamento de Identidades e Gerenciamento de Acesso, destinado a aplicativos e serviços modernos. Em vez de fazer login em aplicativos individuais, os usuários se autenticam no Keycloak.

O foco principal deste resumo completo é adicionar segurança a APIs REST Spring Boot com Keycloak Spring Boot Adapter.

Keycloak oferece alguns recursos como,

1. Suporte para OpenID Connect, OAuth 2.0 e SAML.

2. Single Sign-On

Suas aplicações não tem a necessidade de lidar com armazenamentos de usuários, armazenamento de credenciais, autenticação, formulários de login ou gerenciamento de sessão.

Com o recurso Single Sign-On, uma vez que um usuário faz login no Keycloak, os usuários não precisam fazer login novamente para acessar uma aplicação diferente e o mesmo se aplica ao logout.

3. Federação do usuário

Keycloak possui suporte integrado para conectar-se a servidores LDAP ou Active Directory existentes.

4. Provedores de identidade

O Keycloak pode autenticar usuários com provedores de identidade OpenID Connect ou SAML 2.0 configurando o mesmo por meio do console de administração. Além disso, sem código, seus aplicativos podem ser integrados a redes sociais como Facebook, Google, Microsoft, GitHub entre outros.

5. Serviços de autorização

Keycloak fornece autorização para gerenciar permissões para todos os serviços, usuários e grupos.

As funções podem ser definidas com o console de administração, bem como por meio de APIs, SDK.

Keycloak — Instalação

Existem algumas formas de se instalar o Keycloak. Neste artigo vou mostrar como instalar o Keycloak utilizando Docker.

Keycloak — Instalação com Docker

1. Garanta que tenha o Docker instalado em seu computador. Doc. Docker.

2. Abra seu Terminal e execute o seguinte comando. Substitua os campos <username>e <password>no comando abaixo, que será o nome de usuário e senha do administrador inicial.

docker run -p 8080:8080 -e KEYCLOAK_USER=<username> -e KEYCLOAK_PASSWORD=<password> quay.io/keycloak/keycloak:13.0.1

Existem várias variáveis ​​de ambiente disponíveis para configurações Keycloak adicionais, como integração com alguns bancos de dados (MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server), Importar/Exportar Realms, Temas Personalizados, Provedores Personalizados, Clustering e muito mais.

Keycloak — Configuração

Criar Realm

Um Realm gerencia um conjunto de usuários, credenciais, funções e grupos. Um usuário pertence e efetua login em um domínio. Os realms são isolados uns dos outros e só podem gerenciar e autenticar os usuários que controlam.

1. Vá para http://localhost:8080/auth/admin/ e faça login no Keycloak Admin Console usando as credenciais de administrador que você adicionou ao executar o comando Docker no tópico anterior.

2. Clique menu suspenso Master localizado do lado esquerdo de sua tela e em seguida clique em Add Realm.

Quando você está conectado ao domínio master, este menu suspenso exibe todos os domínios existentes. Quando o domínio é criado, a página principal do console de administração é aberta. Observe que o domínio atual agora está definido como Demo, clique em Create.

Alterne entre o gerenciamento do domínio Master para o domínio que você acabou de criar, passe o mouse sobre o domínio Master,

E selecione o domínio Demo,

Certifique-se de que Demo está selecionado para as configurações abaixo. Evite usar o domínio Master. Você não precisa criar um Realm todas as vezes. É um processo único.

Criar Cliente

Os clientes são entidades que podem solicitar que o Keycloak autentique um usuário. Na maioria das vezes, os clientes são aplicativos e serviços que desejam usar o Keycloak para se proteger e fornecer uma solução de logon único.

Os clientes também podem ser entidades que desejam apenas solicitar informações de identidade ou um token de acesso para que possam invocar com segurança outros serviços na rede protegidos pelo Keycloak.

1. Clique no menu Clients no painel esquerdo. Todos os clientes disponíveis para o Realm selecionado (Demo) serão listados neste menu.

2. Para criar um novo cliente, clique em Create . Você será solicitado a fornecer um ID de cliente, um protocolo de cliente e uma URL raiz.

Uma boa escolha para o ID do cliente é o nome do seu aplicativo (demo-springboot-with-keycloak), o protocolo do cliente deve ser definido como openid-connecte o URL raiz deve ser definido como o URL da aplicação e como estamos testando localmente neste exemplo, vou adicionar a URL raiz como localhost.

3. Após de salvar o cliente, será exibida a página de configuração do mesmo, onde você pode atribuir um nome e uma descrição ao cliente, se desejar.

Defina o Access Type como confidential,

Authorization Enable para ON,

Service Accounts Enable para ON,

e clique em Save.

4. Clique na aba Credentials que mostrará o Client Secret que é necessário para as configurações do Spring Boot Application Keycloak.

Agora clique na aba Roles para criar as roles do cliente. Imagine que a aplicação com o qual você está construindo tenha diferentes tipos de usuários com diferentes permissões de usuário. Ex: usuários e administradores.

• Algumas APIs só podem ser acessadas por usuários.
• Algumas APIs podem ser acessadas apenas por administradores.
• Algumas APIs podem ser acessadas por usuários e administradores.

Então, vamos criar duas roles: user e admin. Clique no botão add role localizado na lateral direita de sua tela,

Crie a role user,

Crie a Role admin,

Roles cadastradas,

Criar Roles de Realm

As aplicações geralmente atribuem acesso e permissões a roles específicas, em vez de usuários individuais, pois lidar com usuários pode ser muito trabalhoso e difícil de gerenciar.

Vamos criar app-user e app-admin Realm Roles atribuindo demo-springboot-with-keycloak roles correspondentes (user, admin).

1. Clique no menu Roles no painel esquerdo. Todas as roles disponíveis para o Realm selecionado serão exibidas,

2. Para criar uma role app-user de role, clique em Add Role localizado na lateral direita de sua tela. Você será solicitado a fornecer um nome para a role e uma descrição . Forneça os detalhes abaixo e salve.

Após salvar, habilite Composite Roles para ON e pesquise por demo-springboot-with-keycloak no campo Client Roles.

Selecione a role user de demo-springboot-with-keycloak e clique em Add Selected>.

Esta configuração atribuirá a demo-springboot-with-keycloak a role user de cliente à role de app-user. Se você tiver vários clientes com várias funções, escolha as funções necessárias de cada cliente para criar funções de domínio com base na necessidade.

3. Realize os mesmos passos para criar o app-admin, mas atribua a role admin do cliente em vez da role user.

Criar Usuários

Vamos criar seguintes usuários e conceder-lhes app-user e app-admin para realizarmos os testes.

• funcionario1 com app-user Realm Role.
• funcionario2 com app-admin Realm Role.
• funcionario3 com funções de app-user & app-admin Realm Roles.

1. No menu, clique em Users para exibir a página da lista de usuários.

2. No lado direito da lista de usuários vazia, clique em Add User.

3. Informe o username; este é o único campo obrigatório.

3.1 Habilite o botão Email Verified de OFF para ON e clique em Save para salvar os dados e abrir a página de gerenciamento para o novo usuário.

4. Clique na aba Credentials para definir uma senha temporária para o novo usuário.

5. Digite uma nova senha e confirme-a. Mude o botão Temporary de ON para OFF e clique em Set Password para definir a senha do usuário para a nova que você informou. Para simplificar, vamos definir a senha mypassword para todos os usuários.

6. Clique na guia Role Mappings para atribuir Realm Roles ao usuário. A lista de roles do realm estará disponível na lista de Available Roles,

Selecione uma role necessária e clique em Add Selected> para atribuí-la ao usuário,

Acredito que tenha achado um pouco complicado passar por todas as configurações. Mas quando você começar a utilizar o Keycloak com mais frequência, essas configurações se tornarão muito simples.

Gerar Tokens

Agora vamos aprender como gerar um token de acesso para usuários do Keycloak.

1. Vá para o menu Realm Settings do domínio Demo no menu à esquerda,

No campo Endpoints clique em OpenID Endpoint Configuration,

Para visualizar os detalhes do OpenID Endpoint,

2. Copie token_endpoint da OpenID Endpoint Configuration. A URL seria semelhante a:

<KEYCLOAK_SERVER_URL>/auth/realms/<REALM_NAME>/protocol/openid-connect/token

Ex: http://localhost:8080/auth/realms/Demo/protocol/openid-connect/token

3. Use o seguinte comando CURL para gerar as credenciais do usuário. Substituir KEYCLOAK_SERVER_URL, REALM_NAME, CLIENT_ID, CLIENT_SECRET, USERNAME, PASSWORD,

curl -X POST '<KEYCLOAK_SERVER_URL>/auth/realms/<REALM_NAME>/protocol/openid-connect/token' \
 --header 'Content-Type: application/x-www-form-urlencoded' \
 --data-urlencode 'grant_type=password' \
 --data-urlencode 'client_id=<CLIENT_ID>' \
 --data-urlencode 'client_secret=<CLIENT_SECRET>' \
 --data-urlencode 'username=<USERNAME>' \
 --data-urlencode 'password=<PASSWORD>'

Exemplo,

curl -X POST 'http://localhost:8080/auth/realms/Demo/protocol/openid-connect/token' \
 --header 'Content-Type: application/x-www-form-urlencoded' \
 --data-urlencode 'grant_type=password' \
 --data-urlencode 'client_id=demo-springboot-with-keycloak' \
 --data-urlencode 'client_secret=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' \
 --data-urlencode 'username=funcionario1' \
 --data-urlencode 'password=mypassword'

Caso tenha se esquecido, o client_secret se localiza no Menu Clients, após acessar este menu clique em demo-springboot-with-keycloak e vá até a aba Credentials, veja,

Execute o CURL do Terminal ou use o Postman. Veja a resposta da requisição feita no Postman,

Request,

Response,

Vamos decrypt o token access_token JWT emitido para que o funcionario1 possa utilizar. Clique aqui.

• access_token contém os detalhes da permissão do usuário.
• realm_access.roles contém app_user realm role.
• resource_access.demo-springboot-with-keycloak.roles contém a user roles do cliente.
• preferred_username contém o nome de usuário do usuário (funcionario1)

Veja o payload,

• iat, exp,

Contém o tempo de emissão do token, bem como o tempo de expiração do mesmo. Os tempos de expiração do token de acesso podem ser personalizáveis ​​em Realm Settings,

Aba Tokens,

Por padrão, o Access Token Lifespan seria definido para 5 minutos, que pode ser personalizado com base em seus requisitos de segurança.

Na fase de teste da aplicação com Spring Boot, use as etapas acima para gerar tokens de acesso para vários usuários com as credenciais de usuário correspondentes. Além disso, se o token expirar, gere um novo token com o mesmo processo.

Clique aqui para continuar para a parte 2.

Construindo uma aplicação Spring Boot e configurando com Keycloak Spring Boot Adapter.

• Certifique-se de que o Maven esteja instalado e configurado.
• Vamos gerar o projeto utilizando a IDE Spring Tools 4

• Você também pode gerar o projeto utilizando o Spring Initializr

Criando aplicação Spring Boot

Utilizando Spring Tools vá em File -> New -> Spring Starter Project.

Preencha os campos da seguinte forma:

Clique em Next, e adicione as seguintes dependências,

• Spring Web
• Spring Security
• Spring Boot DevTools

Alguns detalhes no POM.xml

1. Adicione a propriedade de versão do Keycloak

• Encontre a seção <properties> e adicione a propriedade <keycloak.version>
• Os valores das propriedades devem corresponder à versão do Keycloak. Se você instalou o Keycloak a partir deste artigo, utilize a versão 13.0.1.

Exemplo:

<properties>
  <java.version>11</java.version>
  <keycloak.version>13.0.1</keycloak.version>
</properties>

2. Adicione a dependência do Keycloak

<dependency>
   <groupId>org.keycloak</groupId>
   <artifactId>keycloak-spring-boot-starter</artifactId>
   <version>13.0.1</version>
</dependency>

3. Adicione gerenciamento de dependências, abaixo da tag <dependencies>

<dependencyManagement>
  <dependencies>
   <dependency>
    <groupId>org.keycloak.bom</groupId>
    <artifactId>keycloak-adapter-bom</artifactId>
    <version>${keycloak.version}</version>
    <type>pom</type>
    <scope>import</scope>
   </dependency>
  </dependencies>
</dependencyManagement>

Alguns detalhes no application.properties

Abra o arquivo application.properties em src/main/ esources e adicione as configurações Keycloak necessárias,

server.port                         = 8000

keycloak.realm                      = <REALM_NAME>
keycloak.auth-server-url            = <KEYCLOAK_SERVER_URL>/auth
keycloak.ssl-required               = external
keycloak.resource                   = <CLIENT_ID>
keycloak.credentials.secret         = <CLIENT_SECRET>
keycloak.use-resource-role-mappings = true
keycloak.bearer-only                = true

Exemplo:

Classe de configuração Java — KeycloakSecurityConfig.java

O Keycloak fornece um KeycloakWebSecurityConfigurerAdapter como uma classe base conveniente para a criação de uma instância WebSecurityConfigurer. A implementação permite personalização por meio de métodos de substituição. Embora seu uso não seja obrigatório, ele simplifica muito a configuração do contexto de segurança.

Vamos criar KeycloakSecurityConfig.java no package config,

• Métodos
  - configureGlobal()
  Registra o KeycloakAuthenticationProvider com o gerenciador de autenticação
• - sessionAuthenticationStrategy()
  Define a estratégia de autenticação da sessão.
• - KeycloakConfigResolver
  Por padrão, o Spring Security Adapter procura um arquivo keycloak.json de configuração.

A propriedade jsr250Enabled nos permite usar a anotação @RoleAllowed . Exploraremos mais sobre essa anotação na próxima etapa.

Classe de teste Java — TestController.java

Precisamos de algumas APIs fictícias para testar a segurança da API.

Crie a classe TestController.java no package controller.

Execute a aplicação Spring Boot

Você pode executar a aplicação através de seu terminal ou através da IDE Spring Tool.

1. Terminal utilizando o comando:

mvn spring-boot: run

2. IDE Spring Tool

Log da aplicação em execução:

Request nas APIs

Agora vamos realizar a chamada das nossas APIs REST utilizando CURL no terminal,

curl -X GET 'http://localhost:8000/test/anonymous'

curl -X GET 'http://localhost:8000/test/user'

curl -X GET 'http://localhost:8000/test/admin'

curl -X GET 'http://localhost:8000/test/all-user'

Response dos requests,

Como pudemos ver, todas as APIs não requerem autenticação ou autorização. Agora, vamos tentar proteger esses endpoints da API.

Definindo o acesso baseado em Role com a anotação @RolesAllowed

Endpoints

/test/user:
Esta API deve ser acessível aos usuários com demo-springboot-with-keycloak com a role app-user. Isso pode ser definido apenas adicionando a anotação @RolesAllowed passando o parâmetro “user”, assim,

/test/admin:
Esta API deve ser acessível aos usuários com demo-springboot-with-keycloak a role app-admin. Isso pode ser definido apenas adicionando a anotação @RolesAllowed passando o parâmetro “admin”, assim,

/test/all-user:
Esta API deve ser acessível aos usuários com demo-springboot-with-keycloak com as roles app-user e app-admin. Isso pode ser definido apenas adicionando a anotação @RolesAllowed passando os parâmetros “user” e “admin”, assim,

/test/anonymous:
Esta API deve ser acessível sem qualquer token de autorização, sem restrições. Ele já atende aos nossos requisitos e não precisa de alterações adicionais.

Classe TestController.java atualizada,

Execute a aplicação novamente para expor os endpoints com a autenticação adicionada.

Testando Endpoints com autenticação

1. Endpoint /test/user requer um usuário com a role app-user, o usuário funcionario1 contém esta role, sendo assim, vamos realizar uma nova requisição para capturarmos os access_token do funcionario1,

Copie o access_token e adicione em uma nova requisição no campo Authorizarion com o tipo Bearer Token,

Após adicionar o Token realize uma requisição no Endpoint /test/user

Response,

Sucesso!

Realizando request no endpoint /test/admin para validar que este usuário não tem permissão para consultar o endpoint /test/admin por ter somente a role que permite realizar requests no endpoint test/user,

“Acesso negado”, status HTTP 403. Correto!

2. Endpoint /test/admin requer um usuário com a role app-admin, o usuário funcionario2 contém esta role, sendo assim, vamos realizar uma nova requisição para capturarmos os access_token do funcionario2,

Request na API /test/admin passando o token,

Obtivemos sucesso nesta requisição também.

Realizando request no endpoint /test/user para validar que este usuário não tem permissão para consultar o endpoint /test/user por ter somente a role que permite realizar requests no endpoint test/admin,

“Acesso negado”, status HTTP 403. Correto!

3. Realize o request para obter o access_token do funcionario3 que, por sua vez, contém as roles app-admin e app-user. Este usuário deve conseguir realizar uma requisição em ambos os Endpoints e obter sucesso.

Request no endpoint /test/user com o usuário funcionario3,

Request no endpoint /test/admin com o usuário funcionario3,

Todos os endpoints estão com autenticação adicionada.

Removendo anotação @RolesAllowed e adicionando complemento no método configure() da classe de configuração.

Nossa classe de configuração KeycloakSecurityConfig.java contém um método chamado configure() e o mesmo está permitindo qualquer requisição, por isso a necessidade de adicionarmos a anotação. Mostrei como adicionar as roles através da anotação inicialmente porque achei interessante mostrar que também existe essa possibilidade.

Basicamente basta sobrescrever seu método configure, disso:

Para isso:

FIM!

Caso tenha interesse em consultar o projeto no github, clique aqui.

REFERÊNCIAS

• JSON Web Tokens - jwt.io
• O que é Keycloak e como começar a usar - Blog DB1
• Tipo de provedor de autenticação LDAP
• Single sign-on - Wikipedia
• OpenID - Wikipédia, a enciclopédia livre
• Como funciona o protocolo OAuth 2.0 - iMasters - We are Developers
• Security Assertion Markup Language - Wikipedia
• Docker
• curl - How To Use
• Tools
• 401 Unauthorized - HTTP | MDN
• 403 Forbidden - HTTP | MDN

Neste pequeno tópico vou mostrar como remover todos os elementos nulos de uma lista. Usando Java simples, Guava, as coleções Apache Commons e o suporte a lambda Java 8 mais recente.

Opção 1:

Removendo valores nulos de uma lista usando o Java simples.

Um loop while básico :

Como outra alternativa, também podemos chegar no mesmo resultado:

Observe que ambas as soluções modificaram a lista de fontes.

Opção 2:

Removendo valores nulos de uma lista usando o Google Guava.

Também podemos remover nulos usando Guava, por meio de predicados:

Como alternativa, se não quisermos modificar a lista, o Guava nos permite criar uma nova lista de filtros:

Opção 3:

Removendo valores nulos de uma lista usando Apache Commons Collections.

Vejamos agora uma solução simples usando a biblioteca Apache Commons Collections:

Opção 4:

Removendo valores nulos de uma lista usando Lambda (Java 8)

Vamos olhar agora para uma solução Java 8 usando Lambdas para filtrar a Lista ; o processo de filtragem pode ser feito em paralelo ou serial:

Espero ter ajudado com algumas soluções rápidas e muito úteis para se livrar de todos os valores nulos de uma Lista.

Conclusão

Neste tópico, exploramos diferentes abordagens que podemos ter para remover nulos de uma lista usando Java simples, Guava ou Lambdas.

Neste tópico vou abordar como podemos definir qual a ordem de execução de nossos testes utilizando JUnit5.

Vamos iniciar com um test case.

Dado que

Precisamos criar testes de integração para uma aplicação simples que realiza um CRUD.

Ordem de execução

Para que o teste integrado da API responsável por receber uma requisição para DELETAR um objeto seja um teste efetivo, precisamos primeiramente ter um objeto salvo no nosso banco de dados, ou seja, o teste de requisição na API responsável por SALVAR um objeto deve ser executado primeiro.

Particularmente encontrei vários exemplos como este aqui na internet:

Perceba que antes de iniciar a execução dos testes, o método setUp() está realizando uma requisição para popular a base antes de efetuar o DELETE, mas após rodar a classe de teste o que teremos como teste real será apenas o método shouldDeleteObject() e sabemos que isso não é o que queremos.

Executando testes na ordem desejada

O JUnit5 desenvolveu uma anotação chamada @Order que recebe como parâmetro um número inteiro, de acordo com a documentação:
“Os elementos são ordenados com base na prioridade, onde um valor inferior tem maior prioridade do que um valor superior. Por exemplo, Integer.MAX_VALUE tem a prioridade mais baixa.”

Ou seja, se tivermos um método anotado com @Order(1) o mesmo deve ser executado primeiro, sendo assim, podemos alterar o nome do método setUp() para shouldPersistObject() para que ele tenha um nome que de fato descreva qual a sua verdadeira responsabilidade e por fim bastaria anotarmos os dois métodos da seguinte maneira:

PS: Adicione a seguinte anotação em sua classe de testes @TestMethodOrder(MethodOrderer.OrderAnnotation.class)

Agora temos de fato, dois testes. O primeiro teste a ser executado será o método shouldPersistObject(), onde sua responsabilidade é enviar uma requisição que resultará na persistência de um objeto. O teste shouldDeleteObject() será executado logo após a conclusão do primeiro.

Espero que esta informação seja útil para você como foi para mim!

Referência

Order (JUnit 5.4.0-RC1 API)

A API Postmon é baseada em REST, basta fazermos uma chamada para a url abaixo:
https://api.postmon.com.br/v1/cep/*cep_a_consultar*

Antes de começarmos a exibir códigos e falarmos algumas palavras "difíceis", vamos começar entendendo o que seria REST e o que seria essa "chamada".

REST, o que seria?

A Representational State Transfer (REST), em português Transferência de Estado Representacional, é uma abstração da arquitetura da World Wide Web, mais precisamente, é um estilo arquitetural que consiste de um conjunto coordenado de restrições arquiteturais aplicadas a componentes, conectores e elementos de dados dentro de um sistema de hipermídia distribuído.

O REST ignora os detalhes da implementação de componente e a sintaxe de protocolo com o objetivo de focar nos papéis dos componentes, nas restrições sobre sua interação com outros componentes e na sua interpretação de elementos de dados significantes.

Ele foi definido oficialmente pela W3C.
Fonte: Wikipedia (em inglês)

Ele é frequentemente aplicado à web services fornecendo APIs para acesso a um serviço qualquer na web. Ele usa integralmente as mensagens HTTP para se comunicar através do que já é definido no protocolo sem precisar "inventar" novos protocolos específicos para aquela aplicação.

Você trabalha essencialmente com componentes, conectores e dados.

• Ele usa o protocolo HTTP (verbos, accept headers, códigos de estado HTTP, Content-Type) de forma explícita e representativa para se comunicar. URIs são usados para expor a estrutura do serviço. Utiliza uma notação comum para transferência de dados como XML ou JSON.

No caso da API Postmon a transferência dos dados é em formato JSON e a "chamada" é feita utilizando o verbo HTTP GET.

FAZENDO A CHAMADA MANUALMENTE

Copie e cole a URI abaixo em seu navegador:
[https://api.postmon.com.br/v1/cep/adicione_seu_cep_aqui]

Você terá uma resposta semelhante a imagem abaixo:

O RestTemplate

Não vamos entrar em detalhes sobre como funciona o RestTemplate, já que o foco aqui é consumir a API Postmon. Mas vale adicionar uma frase da documentação, rs.

The RestTemplate offers templates for common scenarios by HTTP method, in addition to the generalized exchange and execute methods that support of less frequent cases.

Já que a classe está pronta e consegue executar exatamente o que precisamos para consumirmos a API Postmon, bora por a mão na massa!

CRIANDO PROJETO SPRING BOOT

Crie seu projeto Spring Boot, dê o seguinte nome para o projeto ConsumerApiPostmon e siga o passo-a-passo abaixo:

Agora que sabemos como é a resposta da API Postmon precisamos mapear isso em nossa aplicação (que acabamos de criar). Para que o conteúdo deste artigo fique sincronizado com o projeto que você criou, deixe seus pacotes no formato br.com.postmon.

Seu projeto deve estar assim:

ENTENDENDO NOSSO MODELO

De acordo com a resposta da API Postmon temos 3 objetos dentro do JSON:

1 Objeto principal contendo todas as informações agrupadas;

1 Objeto com algumas informações da cidade;

1 Objeto com algumas informações do estado;

CRIANDO NOSSOS MODELOS

Todos os modelos devem ficar dentro do pacote br.com.postmon.model

Para conseguirmos consumir a API precisamos criar 3 classes modelos que representam esses 3 objetos contidos na resposta da requisição.

Crie uma classe com o nome CityInfo para representar o objeto "cidade_info" do JSON e adicione 3 atributos do tipo String, como os atributos do JSON estão com Underline ( _ ), e não é uma boa prática adicionar isso em nomenclatura de variáveis ou classes vamos utilizar uma anotação chamada @JsonProperty passando entre parênteses o valor do atributo contido no JSON.

Link da dependência @JsonProperty

Abaixo temos um exemplo de como a classe CityInfo deve ficar:

Faremos o mesmo com a classe que deve representar o objeto "estado_info":

E por fim, nosso último objeto que contém todas as informações agrupadas:

Perceba que nosso objeto Address contém 2 objetos como atributo, o CityInfo e também o StateInfo, ambos estão anotados com @JsonProperty("nome_que_o_mesmo_representa_dentro_do_json").

Agora, seus pacotes e classes devem estar assim:

CONSUMINDO A API POSTMON

Agora que mapeamos o JSON e sabemos que a classe RestTemplate é capaz de realizar requisições HTTP, vamos consumir a API Postmon e popular nossos objetos com a resposta.

Crie sua classe de serviço que deverá ficar dentro do pacote br.com.postmon.service com o seguinte nome, ConsumerApiPostmonService

Anote sua classe com a anotação @Service do próprio Spring.

Vamos bem devagar para que você não fique perdido(a).
Seu serviço deve estar assim até o momento:

URL BASE

Sabemos que para realizar uma chamada na API Postmon é necessário ter a URL BASE que é [ https://api.postmon.com.br/v1/cep/ ].

Exemplo do que é uma URL BASE:

Se um sistema conter várias APIs para realizar um CRUD de um usuário:
/save
/update
/delete
/find

A URL BASE das APIs acima poderia ser http://crud.com.br/ e consequentemente após a br/ seria o /save /update /delete e por fim /find .

Em uma URL, o nome do que vem depois da URL BASE, por exemplo, /save é chamado de endereço de caminho. A URL BASE nunca muda, ou seja, sempre vamos precisar da seguinte URL:
[https://api.postmon.com.br/v1/cep/] para consumir a API Postmon.

Quando costumo criar requisições em sistemas externos, gosto de adicionar essas URLs base como variáveis de ambiente.

Variável de ambiente

Basicamente basta adicionarmos uma variável dentro do nosso arquivo application.properties e adicionar um valor a ela (o valor será a URL BASE da API Postmon).

O arquivo application.properties fica dentro do diretório src/main/resources de sua aplicação conforme a representação da imagem abaixo:

Abra o arquivo adicione o seguinte texto:
url.postmon=https://api.postmon.com.br/v1/cep/
url.postmon é a nossa variável e o valor dela é a URL BASE

Seu arquivo deve ficar assim:

Agora que já adicionamos a URL BASE como variável de ambiente, só precisamos adicionar a anotação @Value("${nome_variável_de_ambiente}") em uma variável no nosso serviço, assim o Spring consegue atribuir a uma variável o valor da URL BASE que está dentro do arquivo application.properties.

Após adicionar a variável seu serviço:

Como nosso serviço deve receber um CEP para concatenar com a URL BASE, precisamos criar um método que deve receber um CEP e consequentemente concatena o CEP com o atributo URL e assim montar nossa URL completa.

Seu método deve ficar assim:

Enfim, o RestTemplate!

Crie uma instancia do RestTemplate utilizando o comando new. Ou seja, new RestTemplate();
Crie também uma variável de referência desta instancia:

Conforme a documentação do RestTemplate existe um método nesta classe chamado getForObject. Ele é responsável por realizar uma requisição utilizando o verbo HTTP GET, após realizar arequisição na URL que passarmos para ele, o mesmo converte a resposta em objeto, no caso o que criamos [Address, CityInfo e StateInfo]. Incrível, não?

Vamos ver na prática como isso funciona:

Sintaxe:
getForObject(url_completa, objeto_esperado_na_resposta)

Muito simples, não?
Vamos adicionar um retorno em nosso método para conseguirmos testar esta requisição, adicione a nossa classe Address como retorno:

TESTE DE INTEGRAÇÃO DO SERVIÇO

Vamos utilizar o JUnit para testarmos nosso serviço.

Seu projeto contém um diretório chamado src/test/java com apenas 1 classe de teste. Vamos criar uma nova classe dentro do pacote service do diretório de teste com o nome do nosso serviço + a palavra Test na frente, ficará assim ConsumerApiPostmonServiceTest:

A intenção deste teste é validar se a integração entre nosso serviço e a API Postmon está funcionando. Então vamos anotar nossa classe com:
@SpringBootTest
@RunWith(SpringRunner.class)

Vamos fazer a injeção do nosso serviço na classe de teste adicionando nosso serviço como atributo da classe e anotando o mesmo com @Autowired .

Classe de teste:

Crie o método responsável por testar o serviço, vamos chamá-lo de consumerTest():

Vamos utilizar o mesmo CEP do início do artigo para realizar o teste, se quiser, adicione o CEP de sua preferência.
Utilize a variável de referência do nosso serviço que chamamos de service para chamar o método consumer(informe_um_cep) e atribua o retorno a uma variável de referência do tipo Address:

Como sabemos dentro do JSON de resposta temos 2 Objetos o cidade_info e o estado_info. Esses 2 objetos estão contidos como atributos dentro da nossa classe Address. Pegue os 2 atributos conforme a imagem abaixo:

Agora, vamos utilizar o método assertEquals para validar se o que esperamos de resposta realmente é o que retornou da API Postmon.

Sintaxe:
assertEquals(O que esperamos, O que retornou)

Para executarmos nosso teste, precisamos clicar com o lado direito do nosso mouse em cima do nome do método, ir até a opção RunAs e clicar em JUnit Test:

Após a execução, nosso teste ficará verde:

Nosso teste está verde porque o que esperávamos de resposta da API Postmon retornou, ou seja, nosso serviço consumiu a API Postmon e retornou com os dados que queríamos.

Caso você queira ver o retorno com os seus próprios olhos, adicione o método toString() dentro dos 3 objetos e adicione o Address dentro de um sysout():

Resposta:
Address [neighborhood=Centro, city=Salvador, stateInfo=StateInfo [area=564.732,642, codeIBGE=29, name=Bahia], postalCode=40020160, cityInfo=CityInfo [area=692,819, codeIBGE=2927408], state=BA]

De acordo com o teste nossa aplicação está funcionando como esperado. Podemos concluir que consumir uma API externa é bem simples e objetiva quando utilizamos o getForObject do RestTemplate.
O intuito deste artigo é ajudar iniciantes que tem uma certa dificuldade para conseguir entender como funciona o consumo de uma API externa.

Espero ter ajudado.

Referências:

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/client/RestTemplate.html#getForObject-java.net.URI-java.lang.Class-

https://blog.indrek.io/articles/using-environment-variables-with-spring-boot/

https://junit.org/junit5/

Vamos utilizar um Docker do metabase e conectar o mesmo ao Athena (AWS).

Sem enrolação, vamos por a mão na massa!

Baixando imagem Docker do Metabase

Precisamos de uma imagem Docker do metabase, para fazer download execute o comando $docker run -d -p 3000:3000 --name metabase metabase/metabase.

Após efetuar o download, verifique se a imagem está up utilizando o comando $docker ps . Precisamos que seu terminal retorne algo parecido com a imagem abaixo:

Agora que sua imagem Docker está up abra seu navegador e digite http://localhost:3000 .

Conta do administrador

Agora você deve configurar seu usuário de acesso, aparecerá uma tela parecida com esta:

Configurando acesso ao banco de dados Athena

Veja que em database type o Athena não está disponível como opção.

Para conectar o Athena ao Metabase precisamos do Driver de conexão do Athena, os Drivers de conexões com os bancos de dados disponíveis atualmente (2019/11/30) são limitados e não temos por padrão a conexão com o Athena.

Depois de muita procura, encontrei este Driver: https://github.com/dacort/metabase-athena-driver/releases/tag/v0.0.3

Faça download do driver, pois ele será o responsável por habilitar a conexão com o Athena.

Após efetuar o download, precisamos adicionar o jar dentro do diretório plugins/ do container Docker metabase . Fazer isso é bem simples, siga o passo a passo abaixo.

Adicionando Driver do Athena no container Docker do Metabase

Acesse seu container utilizando o comando docker exec -it (container_id) /bin/bash .

Liste os diretórios contidos em seu container utilizando o comando ls :

Veja que o diretório plugins está ali!

Utilize o comando exit para sair do container.

Acessamos o container Docker para que vocês vejam que está tudo conforme esperávamos. Agora para que o Athena fique disponível precisamos copiar o jar para dentro do diretório plugins/ do container Docker.

Para executar esta ação, utilize o comando $ docker cp driver_athena.jar seu_container_id:/plugins/ .

Agora que adicionamos o Driver no diretório correto, reinicie seu container Docker utilizando o comando $docker restart seu_container_id .

Acesse novamente através do navegador o metabasehttp://localhost:3000 .

Agora voltando a configuração do seu banco de dados veja que em database type o Athena está disponível, aparecerá uma tela similar a esta após selecionar o Athena como database:

Você precisa ter os seguintes dados para se conectar ao banco de dados:

Em database type selecione o Athena que agora estará disponível;

Nome para o banco de dados;

Região em que o s3 (local onde o Athena estará consumindo) se localiza;

AccessKey: credenciais do usuário de acesso ao Bucket s3;

SecrectKey: credenciais privadas do usuário de acesso ao Bucket s3;

Se seu banco não for muito grande, pode deixar marcado apenas a opção execute queries automaticamente ao filtrar ou sumarizar.

Clique em salvar e pronto, sua conexão com o banco de dados Athena estará concluída.

Dica:

Seu usuário de acesso (IAM na AWS) precisa ter as permissões abaixo, para que o Metabase consiga chegar ao Athena, catálogo de dados (tabela, AWSGlue) e ao AmazonS3.

AmazonS3FullAccess;

AmazonAthenaFullAccess;

AWSGlueConsoleFullAccess;

Referências:

• Docker Hub
• Metabase documentation