Revista /dev/All

Texto originalmente publicado no meu blog pessoal: https://www.itexto.com.br/devkico/?p=2850

Já ouviu falar deste framework? Ele foi criado por Graeme Rocher, o mesmo sujeito que criou o Grails e promete resolver diversos dos problemas que temos tanto no Grails quanto no Spring. Mas ele substitui estes frameworks? No caso do Grails, não, já quando o assunto é Spring, talvez. Neste post vou colocar aqui minhas primeiras impressões.

O que é o Micronaut

Pelo primeiro parágrafo você já sabe: é mais um framework voltado para o desenvolvimento web, mas não qualquer desenvolvimento web, e sim APIs, mais especificamente micro serviços. Então ao ler sua documentação você verá diversos termos usado para este tipo de aplicação: cloud native, service configuration, serverless functions e todas aquelas palavrinhas que já estamos pra lá de acostumados a ouvir.

Até aí não há grandes novidades: tanto Spring quanto Grails já nos oferecem suporte a todas estas tecnologias de forma direta ou indireta. Estou desenvolvendo alguns pequenos projetos com ele (um inclusive de grande importância) algo que posso afirmar com segurança é: não há um significativo salto de produtividade para o desenvolvedor tal como experimentamos no primeiro contato com Grails ou Spring Boot.

Então o que motivou a equipe de Graeme Rocher a criar este novo framework? Quais os problemas que foram detectados no Spring e Grails que ele tenta resolver? É aí que a coisa fica interessante: do ponto de vista estritamente ligado à autoria de código você vai trabalhar com o mesmo JPA que já conhece, a escrita dos controladores é essencialmente igual, é possível inclusive usar quase todas as anotações do Spring e implementar suas interfaces no Micronaut. Em relação à linguagem de programação, também não há grandes ganhos: você pode usar Groovy, Java ou Kotlin, então sem choques aqui também. O que muda é a infraestrutura.

Que infraestrutura?

É aqui que a coisa fica realmente interessante: temos agora uma infraestrutura realmente nova. E isto se aplica em alguns pontos que, confesso, mudaram minha maneira de pensar como frameworks são escritos de uma forma bastante radical.

A reflexão mostra seu preço – boot instantâneo e baixíssimo consumo de memória

A reflexão tem seu preço, no entanto a primeira vez que realmente o experimentei de verdade este custo foi escrevendo projetos com Micronaut.

Explico: praticamente todo framework Java usa anotações para identificar seus componentes: a anotação @Controller, por exemplo, identifica uma classe como um bean que irá disponibilizar endpoints HTTP. Quando sua aplicação inicia o framework lê o classpath da aplicação, identifica todas as classes anotadas e, na sequência, aplica as ações necessárias para que desempenhem o papel definido por estas anotações.

O Micronaut segue o caminho oposto: ainda temos as anotações, tal como disse acima, você irá codificar suas classes de uma forma bastante similar à que já está acostumado no Spring (é quase igual). A diferença é que usando um recurso pouco conhecido pela maior parte dos programadores (annotation procesors do Java e processamento de bytecode usando a biblioteca ASM) temos um novo container de injeção de dependências e inversão de controle.

Um container que não descobre quem são os nossos beans em tempo de execução, mas sim em tempo de compilação. E isto faz toda a diferença. Qual? Basicamente uma aplicação que use os recursos de segurança providos pelo Micronaut, muito similares aos que temos no Spring Security e JPA é iniciada quase que instantaneamente (no máximo 2 segundos em meus testes).

(se você tem aplicações feitas em Grails que usam o Spring Security sabe muito bem do que estou falando: temos uma inicialização leeeeeenta)

O modo como lidamos com classes proxy também é diferenciado. Neste container de IoC também podemos trabalhar com AOP, tal como no caso do Spring, mas com advices e interceptadores também definidos em tempo de compilação.

E não temos apenas aqui a inicialização instantânea do projeto: outro problema também é resolvido. O consumo de memória é significativamente menor. Algo que já havia experimentado com Node.js estou vivenciando agora: tenho APIs executando agora que consomem menos de 100 Mb de memória. Você consegue imaginar isto com Java? Eu também não acreditava, mas to vendo isto aqui na minha frente agora!

Servlets? Finalmente uma alternativa

Esta é outra mudança surpreendente. Todos os frameworks que conheço para o desenvolvimento web usam a mesma base: servlets. E aqui pela primeira vez na JVM vejo uma alternativa emergir: não mais uma solução baseada no Java Enterprise Edition padrão, mas sim o provimento de um servidor de aplicação próprio, embutido no projeto.

Este novo servidor web é o primeiro que vejo na plataforma Java que é independente do Java EE tradicional, baseado em servlets. Se baseia em uma outra tecnologia bastante antiga e infelizmente pouco conhecida pelos desenvolvedores hoje: Netty.

Um framework usado para a construção de aplicações de rede assíncronos, de altíssima disponibilidade e desempenho que tem como resultado um novo servidor HTTP diferente daquele com o qual estamos acostumados. Um servidor focado não no padrão MVC tradicional no qual pode haver o retorno de páginas HTML, mas sim uma solução projetada desde o primeiro momento tendo como foco a troca de mensagens (JSON) entre micro-serviços.

Em um primeiro momento você pode pensar nesta mudança como um mero ganho de desempenho. Eu já a vejo como um precedente importantíssimo, que abrirá as portas para um universo de inovações no Java simplesmente maravilhoso.

Como é programar usando o Micronaut

Se você quer novidade é bastante decepcionante por que é basicamente como estamos acostumados a escrever APIs no Spring. Não há novidades: até as anotações são essencialmente as mesmas, mudando apenas o pacote para que possamos tirar proveito da geração de código em tempo de compilação.

Como disse antes, não há um salto de produtividade aqui: talvez você consiga um pouquinho mais de produtividade se gosta de Groovy ou Kotlin, que também podem ser usadas no framework, mas já aviso, não terá uma mudança significativa.

Algo muito bacana no Micronaut é que ele nos perite uma curva de aprendizado mais amigável. Por padrão é usado o Gradle como mecanismo de build, mas se você quiser trabalhar com Maven, é possível também. Recomendo ir pro Maven neste caso? Não, por que a documentação hoje fala mais sobre o Gradle e quase não menciona Maven.

No uso da IDE a adoção do Gradle faz diferença: se você tentar iniciar o projeto a partir de uma classe isolada, por exemplo, terá problemas neste primeiro momento. Na prática sempre deverá tanto executar a aplicação quanto seus testes a partir do Gradle, o que pode ser um pouco chato no início mas com o tempo você se acostuma.

Além da infraestrutura, o que há de interessante

Não se engane: temos aqui uma ferramenta voltada para o desenvolvimento de micro serviços, o que fica claro nos recursos que o framework nos fornece de cara.

Escrita de testes muito mais simples

Dentre os recursos, aquele que mais gostei foi o fato de nos fornecer um servidor HTTP embarcado, mas mais do que isto, também um cliente HTTP. Pra escrita de testes é maravilhoso, por que nos permite instanciar o servidor e realizar nossos testes escrevendo requisições HTTP e não apenas chamada a métodos. Isto faz toda a diferença se você, como eu, prefere escrever testes que verificam comportamentos da nossa IDE. A escrita deste tipo de testes tanto no Spring quanto no Grails pode ser bastante trabalhosa: aqui é trivial.

Você pode escrever seus testes inclusive usando aquilo que já conhece: jUnit ou Spock. Existe inclusive um módulo que torna a configuração destes testes algo simples.

Um framework de segurança pronto e fácil de usar

No Grails e Spring temos o Spring Security, e no caso do Micronaut também temos uma solução para esta questão, só que não é um módulo a parte, mas sim parte do próprio framework.

Se você já conhece o Spring Framework irá se sentir em casa aqui: a solução proposta pelo Micronaut é quase uma cópia, só que mais simples e já vindo com os recursos que são essenciais na escrita de micro-serviços nesta área:

• JWT
• Autenticação por sessão.
• LDAP.
• Autenticação básica (jamais recomendo, mas para legados é interessante)
• Um mecanismo que nos permite flexibilidade na construção de nossos próprios provedores de autenticação.
• Endpoints de autenticação prontos pra serem usados.

Prover isto já pronto para o desenvolvedor pode e irá reduzir significativamente os custos na implementação destes requisitos de restrição de acesso. Inclusive, novamente, as mesmas anotações que temos no Spring Security vemos aqui, como a @Secured, por exemplo.

Multi tenância

O framework também oferece suporte a multi tenância pronta para ser usada. E com um detalhe interessante: nos permite usar o GORM como solução. Sim, o mesmo framework de persistência que usamos no Grails e que é uma das razões pelas quais o adotamos.

Monitoramento

Se vamos construir micro-serviços, temos aqui a necessidade de monitorarmos a qualidade do serviço. Tal como o Spring Boot nos fornece o Actuator (um módulo a parte), Micronaut nos oferece o básico para que possamos monitorar sua qualidade.

É uma versão bem mais simples do Actuator, mas na minha opinião bem mais funcional. Nos permite, por exemplo, criar rapidamente (usando apenas configuração) endpoints que nos permitem verificar as configurações do servidor, checagem de versão, beans carregados, recursos computacionais, etc. Muito útil.

E a adoção? E pra onde vamos? E o Grails?

Faz pouco mais de um mês que a primeira versão final do Micronaut saiu. Naturalmente, este ainda não é uma solução amplamente adotada pela comunidade, mas já é uma solução que está chacoalhando a comunidade Java. O tweet a seguir de Graeme Rocher é bastante significativo:

Amazing thing about the 9 months since we open sourced @micronautfw is the impact it has had on server side @java. Inspiring @Redhat to come up with @quarkusio. Pushing @springboot to improve performance. Micronaut shifted industry strategy. That is what I call groundbreaking!— Graeme Rocher (@graemerocher) 18 de março de 2019

Não é uma solução mainstream, assim como Grails nunca foi, mas trás algo que é fenomenal: incomoda e inspira. Faz com que outras empresas, como a própria Red Hat venha com novas soluções e faz com que soluções já consagradas como o Spring comecem a tomar uma atitude.

E é o fim do Grails? Não, pelo contrário. Enquanto o Grails 3 tinha como base o Spring Boot, sabe qual a base do Grails 4? Yeap: Micronaut, ou seja, todos os problemas que temos hoje com a inicialização de nossos projetos pode estar com os dias contados.

E também não é algo que substituiria o Grails por que o objetivo aqui é outro: enquanto Grails nos fornece um framework fullstack baseado em MVC que cuida tanto do backend quanto do frontend, temos aqui um outro alvo com Micronaut: construir APIs (focado em micro serviços) e ser a base para outros frameworks, como Grails, que agora se tornará muito mais atraente do que já era.

(e a boa notícia é que pela documentação do Grails 4, o upgrade é relativamente simples, sem quebras significativas com as versões anteriores).

Agora vamos discutir!

A conversa não acaba aqui. Convido todos vocês a continuarem conosco esta conversa experimentando o Micronaut e compartilhando suas experiências. Se quiser, pode compartilhar com seus comentários neste post o que achou, mas temos um lugar bem melhor que é a Taverna do /dev/All, na qual criamos uma categoria só para este assunto. Interessou e quer aprender mais? Faça parte do /dev/All: cadatre-se aqui!

Também criei um grupo no Facebook caso queira discutir por lá: é aberto e qualquer pessoa pode entrar. Basta clicar neste link.

E se estiver em Belo Horizonte, participe do nosso meetup sobre Spring, Groovy e Grails: o próximo assunto será justamente sobre Micronaut. O link para o grupo é este, e maiores detalhes sobre quando e onde será o próximo encontro virá em breve (esta semana).

E minha jornada no Micronaut

Está apenas começando, e estou aprendendo bastante com ela. Mais artigos serão publicados aqui e na Revista do /dev/All em breve. Estou inclusive pensando em gravar alguns vídeos, por que tem oisas que vocês tem de ver.

Estamos dando nossos primeiros passos neste framework, e estamos gostando, ainda há muito o que ser aprendido. Vou contando para vocês conforme aprendo. Até lá!