# Quarkus framework
## Introdução

Quarkus é um Java framework adaptado para implantação em Kubernetes. Os principais componentes tecnológicos que o cercam são OpenJDK, HotSpot e GraalVM. O objetivo do Quarkus é tornar o Java uma plataforma líder em Kubernetes e ambientes sem servidor, oferecendo aos desenvolvedores um modelo de programação reativo e imperativo unificado para atender de maneira ideal a uma ampla gama de arquiteturas de aplicativos distribuídos.

## Histórico da versão

| Versão | Data | Notas |
| 0.12 | Mar 20, 2019 | Lançamento inicial |
| 1.0 | Nov 2019 | |
| 1.3 | Mar 2020 | |
| 1.7 | Jun 2020 | |
| 1.11 | Ago 2020 | |
| 1.13 | Mar 2021 | |
| 2.0 | Jun 2021 | |
| 2.2 | Ago 2021 | |
| 2.4 | Out 2021 | |
| 2.5.2 | Dez 2021 | |
| 2.7.5 | Maio 2022 | Final - versão de manutenção |
| Nota | GraalVM é uma máquina virtual Java para compilar e executar aplicativos escritos em diferentes linguagens para um binário de máquina nativa. Existem três distribuições do GraalVM: GraalVM Community Edition (CE), GraalVM Enterprise Edition (EE) e Mandrel. GraalVM CE e EE têm diferentes support and licensing requirements. Mandrel é uma distribuição downstream do GraalVM CE, suportando os mesmos recursos para construir executáveis ​​nativos, mas com base no OpenJDK de código aberto. O Mandrel visa tornar o GraalVM fácil de consumir pelos aplicativos Quarkus, incluindo apenas os componentes GraalVM CE de que o Quarkus precisa. A Red Hat oferece suporte comercial para o uso do Mandrel para criar aplicativos Quarkus nativos desde o lançamento do Quarkus 1.7 em outubro de 2020. |
O Quarkus também oferece expansão quase instantânea e utilização de alta densidade em plataformas de orquestração de contêineres, como o Kubernetes. Muitas outras instâncias de aplicativos podem ser executadas com os mesmos recursos de hardware. Após sua estreia inicial, o Quarkus passou por vários aprimoramentos nos meses seguintes, culminando em um lançamento 1.0 na comunidade de código aberto em outubro de 2019. Como uma nova estrutura, o Quarkus não precisa tentar adaptar novos padrões e princípios a uma base de código existente . Em vez disso, pode se concentrar na inovação.

## Pilares de design
### Pasta primeiro

Desde o início, o Quarkus foi projetado com base na filosofia nativa do Kubernetes e container-first, otimizando para baixo uso de memória e tempos de inicialização rápidos.
O máximo de processamento possível é feito no tempo de compilação, incluindo uma abordagem de suposição de mundo fechado para criar e executar aplicativos. Essa otimização significa que, na maioria dos casos, todo código que não possui um caminho de execução no tempo de execução não é carregado na JVM.
No Quarkus, as classes usadas apenas na inicialização do aplicativo são invocadas no tempo de construção e não são carregadas na JVM em tempo de execução. O Quarkus também evita a reflexão tanto quanto possível, ao invés disso favorecendo a vinculação estática de classes. Esses princípios de design reduzem o tamanho e, em última análise, o consumo de memória do aplicativo em execução na JVM, além de permitir que o Quarkus seja nativo nativo.
O design do Quarkus foi responsável pela compilação nativa desde o início. Ele foi otimizado para usar a capacidade de imagem nativa do GraalVM para compilar o bytecode da JVM em um binário de máquina nativa. O GraalVM remove agressivamente qualquer código inacessível encontrado no código-fonte do aplicativo, bem como qualquer uma de suas dependências. Combinado com contêineres Linux e Kubernetes, um aplicativo Quarkus é executado como um executável Linux nativo, eliminando a JVM. Um executável nativo do Quarkus inicia muito mais rápido e usa muito menos memória do que uma JVM tradicional. Aqui está um exemplo de quão rápido o Quarkus pode fornecer eficiências de tempo de execução significativas com base nos testes da Red Hat:
* A inicialização rápida (dezenas de milissegundos) permite a ampliação e redução automática de microsserviços em contêineres e Kubernetes, bem como a execução de FaaS no local
* A baixa utilização de memória ajuda a otimizar a densidade de contêineres em implantações de arquitetura de microsserviços que exigem vários contêineres
* Aplicação menor e pegada de imagem de contêiner

#### Codificação em tempo real

Um dos principais problemas de produtividade enfrentados pela maioria dos desenvolvedores Java é o fluxo de trabalho de desenvolvimento Java tradicional. Para a maioria dos desenvolvedores da Web, isso geralmente será:
Escrever código → Compilar → Implantar → Atualizar navegador → Repetir
Isso pode ser um grande dreno de produtividade, pois o ciclo de compilação + reimplantação geralmente pode levar até um minuto ou mais. O Quarkus visa resolver esse problema com seu recurso Live Coding. Ao executar no modo de desenvolvimento, o fluxo de trabalho é simplesmente:
Escrever código → Atualizar navegador → Repetir
Isso funcionará imediatamente, sem necessidade de configuração especial. Isso funciona para arquivo Java, configuração de aplicativo e recursos estáticos.
| Nota | Quando você roda mvn compile quarkus:dev O Quarkus será lançado no modo de desenvolvimento. Quando ele recebe uma solicitação HTTP, ele retém a solicitação e verifica se algum arquivo de origem do aplicativo foi alterado. Se tiverem, compilará de forma transparente os arquivos alterados, reimplantará o aplicativo com os arquivos alterados e, em seguida, a solicitação HTTP continuará para o aplicativo reimplantado. As reimplantações do Quarkus são muito mais rápidas do que um servidor de aplicativos tradicional, portanto, para todos os aplicativos, exceto os maiores, isso deve levar bem menos de um segundo. |

#### Interface de usuário do desenvolvedor interativo ( UI )

O Quarkus fornece uma IU de desenvolvedor interativa para mostrar todas as dependências adicionadas quando um desenvolvedor acessa ohttp://localhost:8080/q/dev endpoint após o modo dev do Quarkus ser iniciado por meio da linha de comando mvn quarkus:dev. Os desenvolvedores também podem atualizar as configurações e as alterações sincronizarão o arquivo application.properties automaticamente.

#### Configuração zero com serviços de desenvolvimento

Instalar um banco de dados no ambiente local de um desenvolvedor não é uma tarefa trivial se o banco de dados for igual à versão de produção. Obviamente, os usuários do Linux (desenvolvedores) podem executar o banco de dados facilmente usando uma ferramenta de linha de comando de contêiner (ex., Docker) e um motor de contêiner (ex., Docker). Eles ainda tendem a não executar bancos de dados prontos para produção (ex., PostgreSQL e MariaDB) devido ao alto consumo de recursos (por exemplo, CPU, memória e espaço em disco). Em vez disso, eles preferem usar armazenamentos de dados na memória, como o banco de dados H2.
Quarkus fornece os Serviços de Desenvolvimento construídos em Testcontainers para resolver este problema. Por exemplo, um desenvolvedor pode fazer aplicativos de teste se eles trabalharem no banco de dados de produção, PostgreSQL em vez do armazenamento de dados na memória H2 no arquivo application.properties:
quarkus.datasource.devservices.image-name=postgres:latest
DevServices geralmente é ativado por padrão, a menos que haja uma configuração existente presente. Quando o DevServices estiver ativado, o Quarkus tentará configurar e iniciar automaticamente um banco de dados ao executar no modo de desenvolvimento ou teste.

#### Teste contínuo

O teste não é uma opção para desenvolver aplicativos robustos no desenvolvimento de software de monolito a microsserviços. Os desenvolvedores provavelmente pensam em ferramentas externas de integração contínua (CI) que uma equipe de controle de qualidade provavelmente tem a responsabilidade de verificar os casos de teste. E se os desenvolvedores não precisarem integrar as ferramentas de CI, mas realizar os casos de teste em um ambiente de tempo de execução em que os aplicativos de negócios estão sendo desenvolvidos e executados? O Quarkus fornece um recurso de teste contínuo por meio da interface de linha de comando, bem como da IU DEV. Esse recurso remove os esforços do desenvolvedor para integrar uma ferramenta CI externa e garante a funcionalidade enquanto desenvolve continuamente a lógica de negócios.

### Construído em padrões

O Quarkus se baseia em um vasto ecossistema de tecnologias, padrões, bibliotecas e APIs. Os desenvolvedores não precisam gastar muito tempo aprendendo um conjunto totalmente novo de APIs e tecnologias para aproveitar os benefícios que o Quarkus traz para a JVM ou imagens nativas. Entre as especificações e tecnologias subjacentes ao Quarkus estão Contexts & Dependency Injection(CDI), JAX-RS, Java Persistence API (JPA), Java Transaction API (JTA), Apache Camel, and Hibernate, apenas para citar alguns.
Quarkus também é um Ahead-of-Time compilation(AOT), otimizando o código para a JVM, bem como compilando para o código nativo para melhorar o desempenho. Todas as tecnologias subjacentes são habilitadas para AOT, e o Quarkus está continuamente incorporando novas tecnologias, padrões e bibliotecas habilitadas para AOT.
Todas as tecnologias e recursos necessários para a construção de microsserviços estão disponíveis e otimizados para o Quarkus. Essas tecnologias aproveitam todas as otimizações de tempo de compilação e de execução que já foram discutidas. Tecnologias como Keycloak para autenticação e autorização, ou Infinispan para cache distribuído, são otimizadas para uso no Quarkus, independentemente de serem executadas no HotSpot JVM ou como uma imagem nativa. Desenvolvedores de frameworks e bibliotecas de terceiros podem aproveitar esta plataforma AOT para otimizá-los para o Quarkus.