Transformando seus scripts Groovy em microserviços com Spring Boot!
Tags: groovy, spring, braziliandevs, tutorial
Published: 2021-06-15 14:03:01

---
title: Transformando seus scripts Groovy em microserviços com Spring Boot!
published: true
tags: Groovy,Spring, braziliandevs, tutorial
cover_image: https://devkico.itexto.com.br/wp-content/uploads/2014/08/spring-boot-project-logo.png
---
<!-- wp:paragraph -->
<p>Quando o Spring Boot foi lançado este veio com uma ferramenta chamada "Spring CLI". Brinquei um pouco com ela na época mas confesso que não vi muita graça: até agora.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Dentre as suas funcionalidades há uma bastante interessante: a possibilidade de criarmos microserviços usando scripts escritos em Groovy. Mas atenção: digo aqui <strong>micro</strong>serviços MESMO: <strong>não use esta solução para seus amáveis monolitos.</strong></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>O tipo de aplicação que podemos criar com base nesta estratégia não chamaria sequer de microserviços, mas <em>nanoserviços</em>. Aplicações realmente úteis, compostas por um número muito pequeno de endpoints (um, dois no máximo) que são simples e podem quebrar diversos galhos na sua infraestrutura.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Não espere que este post vá lhe servir de guia completo para este tipo de solução: a ideia é apenas apresentar a vocês esta possibilidade, mas não fiquem tristes, colocarei links que lhes ajudarão a aprender mais sobre o assunto durante e após sua leitura.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>Spring CLI?</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>É muito curioso que com tantos tutoriais, cursos e livros sobre Spring e Spring Boot (me salvo nesta: meu primeiro livro foi sobre o Spring Framework, não Spring Boot!) pouca gente mencione esta ferramenta. Talvez seja por que todo mundo pense da mesma forma na hora de escrever... talvez por que seja algo que não envolva a linguagem Java, mas sim Groovy... não entendo (mas tenho minhas suspeitas).</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Mas fato é que apesar de pouco falado o Spring CLI existe desde que o Boot foi lançado. E era inclusive usado na época para demonstrar o poder do framework como algo super produtivo, bem na mesma pegada que o povo demonstrava o Node.js quando saiu.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Se você já programou em Grails ou Express o Spring CLI lhe parecerá familiar. É uma interface de linha de comando (<strong>C</strong>ommand <strong>L</strong>ine <strong>I</strong>nterface) que você instala e pode executar as seguintes funções:</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><li>Criar novos projetos baseados no Spring Boot, tal como faria no site <a href="https://start.spring.io" class="rank-math-link">https://start.spring.io</a> só que com sua linha de comando.</li><li>Executar "Spring Boot Groovy Scripts" (nosso assunto aqui).</li><li>Empacotar sua aplicação (seja ela Java ou estes scripts que menciono acima).</li><li>Outras pequenas funções que li rapidamente e minha preguiça impediu que me aprofundasse nelas.</li></ul>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p>O recurso ainda está ativo (e em contínuo desenvolvimento!) no Spring Boot e você pode ler sua documentação neste <a href="https://docs.spring.io/spring-boot/docs/2.2.2.RELEASE/reference/html/spring-boot-cli.html" class="rank-math-link">link</a> em sua versão mais atual, ou seja, se é mantido até hoje com certeza muita gente usa!</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":3} -->
<h3><strong>Instalando</strong> o Spring CLI</h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Há duas formas de fazer isto: a fácil, que ensino aqui e outra que você pode ver no link que mencionei agora há pouco. A fácil e que recomendo é usando o Sdkman (não conhece? Escrevi um guia a respeito que você pode ler aqui: <a href="https://www.itexto.com.br/guias/?guia=configurando-seu-ambiente-de-desenvolvimento-java-com-sdkman" class="rank-math-link">https://www.itexto.com.br/guias/?guia=configurando-seu-ambiente-de-desenvolvimento-java-com-sdkman</a> ).</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Execute o comando a seguir com o sdkman:</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">sdk install springboot 2.2.2.RELEASE</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>Para testar sua instalação execute o comando a seguir:</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">spring --version</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>Será apresentada para você a versão instalada. Mencionei aqui que vamos usar Groovy, certo? Você não precisa ter a linguagem instalada em seu computador. O Spring CLI já inclui tudo o que você precisa para poder trabalhar.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>Nosso primeiro "Olá mundo!"</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Cabe aqui um "Olá mundo" para mostrar a simplicidade do código que escrevemos para termos um "nano serviço" em execução com o Spring CLI. Nosso pimeiro "Olá mundo" pode ser visto a seguir:</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">@RestController
class OlaMundo {
    @RequestMapping("/")    
    String olaMundo() { 
      "Que negócio simples!"}
}</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>Repare que não há instruções <strong>import</strong>. Não é necessário importar as classes: o próprio CLI vai importá-las para você de forma automática. </p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Note que é apenas uma classe Groovy padrão com algumas anotações: as mesmas que usamos ao implementar endpoints com o Spring tradicional: <strong>@RestController</strong> pra informar que a classe é um controlador e <strong>@RequestMapping</strong> para informar que aquele método disponibiliza um endpoint.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>E como fazemos para executar este script? Usando o comando spring novamente.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><code>spring run ola-mundo.groovy</code></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>A sua linha de comando irá apresentar uma saída que se você já programou com Spring com certeza já conhece:</p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":2938,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large"><img src="https://i1.wp.com/www.itexto.com.br/devkico/wp-content/uploads/2020/01/image.png?fit=800%2C344&amp;ssl=1" alt="" class="wp-image-2938"/></figure>
<!-- /wp:image -->

<!-- wp:paragraph -->
<p>E se acessar o endereço http://localhost:8080, o que você vai ver?</p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":2939,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large"><img src="https://www.itexto.com.br/devkico/wp-content/uploads/2020/01/image-1.png" alt="" class="wp-image-2939"/></figure>
<!-- /wp:image -->

<!-- wp:paragraph -->
<p>Paramos por aqui com este exemplo. Vamos para algo mais útil.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>Um exemplo um pouco mais útil: monitorando o servidor usando Groovy e Actuator</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>No exemplo anterior você viu essencialmente como usando Groovy criamos um nano serviço com Spring Boot, certo? Se é Spring Boot, podemos usar <strong>todos</strong> dos seus recursos como o <a href="https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html" class="rank-math-link">Actuator</a>, por exemplo: que nos permite monitorar os serviços que implementamos.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Então que tal implementarmos aqui um micro serviço que verifique se tudo está ok no nosso servidor? Ele poderia usar as validações padrões do <a href="https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html" class="rank-math-link">Actuator</a> e ainda implementar nossas próprias regras de validação. Imagine que por alguma razão é necessária a presença do arquivo <em>felicidade.txt</em> no diretório home do usuário responsável por executar a aplicação. Como faríamos isto?</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Já que estamos falando de <strong>Spring</strong>, será que nossos scripts podem ter seus próprios beans? A resposta é sim: observe o código que escrevi (está tudo em um mesmo arquivo chamado <em>monitor.groovy</em>):</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">@Grab("spring-boot-starter-actuator")

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;

@Component
class FelicidadePresente implements HealthIndicator {
    public Health health() {
        def arquivo = new File("${System.getProperty('user.home')}/felicidade.txt")
        arquivo.exists() ? Health.up().build() : Health.down().withDetail("infeliz", "Servidor infeliz").build()
    }
}

@RestController
class Monitor {

   
}</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>Há algumas coisas interessantes aqui que você deve prestar atenção. Talvez você não conheça esta anotação: <strong>@Grab</strong>. Ela faz parte de um recurso <strong>incrível</strong> do Groovy chamado <a href="http://docs.groovy-lang.org/latest/html/documentation/grape.html" class="rank-math-link">Grape</a>. Enquanto na maior parte das aplicações você usa soluções como Maven ou Gradle para resolver as suas dependências, como você faria se precisasse escrever apenas um script? Faria sentido ter um arquivo pom.xml ou build.gradle só para executá-lo? Não! Se você incluir a anotação @Grab do Groovy em seu script, ele irá incluir estas dependências no classpath de forma automática durante a execução: lindo, né?</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>No caso, eu precisei incluir as dependências do Actuator no projeto e importar duas classes para implementar o nosso HealthIndicator: Health e... HealthIndicator.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>E dali pra baixo você que já conhece o Spring não verá novidade alguma: temos um componente e um controlador. Mas observou que este controlador é uma classe vazia sem nenhum endpoint exposto? Precisamos dela para que o Spring CLI execute nossa aplicação. Experimente executar o script acima sem o controlador para ver o que ocorre.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Com nosso código pronto, basta executar agora:</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">spring run monitor.groovy</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>E acessando <em>http://localhost:8080/actuator/health</em> temos a seguinte saída:</p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":2943,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large"><img src="https://www.itexto.com.br/devkico/wp-content/uploads/2020/01/image-2.png" alt="" class="wp-image-2943"/></figure>
<!-- /wp:image -->

<!-- wp:heading {"level":3} -->
<h3>Mas e as configurações?</h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Mas se você já usou o Actuator antes deve ter observado que esta <strong>não é a saída padrão</strong> do mesmo. Então, aonde coloquei as configurações? Simples: você pode seguir uma convenção: se no diretório em que seu script se encontra existir uma pasta chamada <em>config</em>, basta deixar ali um arquivo <em>application.properties</em> ou <em>application.yml</em>. Seguem as minhas configurações:</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">management.endpoints.web.exposure.include=*
management.endpoint.health.show-details=always</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>Você também pode passar suas configurações por linha de comando ou variáveis de ambiente, <strong>exatamente como faria em uma aplicação baseada em Spring Boot</strong> por que, bem: <strong>esta é uma aplicação baseada em Spring Boot</strong>. Sugiro a leitura <a href="https://www.baeldung.com/spring-boot-cli" class="rank-math-link">deste post</a> do Baeldung sobre o Spring CLI que descreve em maiores detalhes como estas configurações se aplicam.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>Minha aplicação pode ter mais de um arquivo de script?</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Claro! Como você faz para executar a aplicação então? Bem simples.</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">spring run *.groovy</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>Ou qualquer outra expressão que seu shell aceite para a seleção de múltiplos arquivos.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>Gerando um arquivo JAR executável</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Executar o seu script com o CLI é bastante útil no ambiente de desenvolvimento, mas em produção não é uma boa ideia. Sendo assim, como você faz para implantar a sua aplicação? Basta usar o comando <strong>spring jar</strong> com a seguinte sintaxe essencial:</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">spring jar [nome do arquivo .jar] [scripts que compõem sua aplicação]</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>Nosso último exemplo poderia ser empacotado portanto com o comando a seguir:</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">spring jar monitor.jar monitor.groovy</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>Feito: agora basta executar o comando <strong>java -jar monitor.jar</strong> e nossa aplicação estará disponível. Neste arquivo estarão todas as dependências necessárias para a execução do projeto. </p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Apenas por curiosidade, o arquivo gerado para o nosso monitor tinha 24Mb de tamanho. Um overhead significativo para algo tão pequeno, huh?</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>Aplicações mais práticas</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Não recomendo o uso do Spring CLI para a criação de aplicações complexas, isto é, compostas por uma quantidade significativa de scripts (3 ou mais). Se você quer usar Groovy como linguagem no desenvolvimento de aplicações baseadas em Spring Boot, saiba que ele oferece <strong>total suporte</strong>, sendo inclusive uma das opções quando criamos um novo projeto no site <a href="https://start.spring.io" class="rank-math-link">Spring Initializr</a>:</p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":2944,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large"><img src="https://www.itexto.com.br/devkico/wp-content/uploads/2020/01/image-3.png" alt="" class="wp-image-2944"/></figure>
<!-- /wp:image -->

<!-- wp:paragraph -->
<p>Mas existe um nicho de aplicações para o qual este tipo de desenvolvimento cai como uma luva. É algo para o qual eu já uso Node.js faz um bom tempo inclusive: consiste em aplicações que sejam essencialmente utilitárias, isto é, que desempenhem <strong>uma única função</strong> e cuja interação com as mesmas se dê através da disponibilização de um conjunto ínfimo de endpoints. Seguem alguns exemplos:</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><li>Monitoramento de servidores, como o que escrevi acima.</li><li>Scripts que executem tarefas agendadas e que cujo resultado do processamento você precise acompanhar.</li><li>Ferramentas de integração: quando implemento webhooks, por exemplo, costumo ter um destes scripts que sirva para me mostrar como é o corpo das requisições recebidas assim como seus cabeçalhos.</li><li>Ferramenta de consultas simples a bases de dados: algo que retorne, por exemplo, se ocorreu determinado evento em um período de tempo que não justificaria sua inclusão na aplicação.</li><li>Seu script usa classes que façam parte de uma outra aplicação: você pode incluí-las no seu classpath tanto na execução quanto no empacotamento da sua solução.</li></ul>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p>Podem ser também simplesmente aplicações compostas por um único endpoint. Fiz uma prova de conceito, por exemplo, para o <a href="https://devall.com.br" class="rank-math-link">/dev/All</a> que era a implementação do RSS do site e funcionou muito bem. Resumindo: é uma ferramenta para a construção de microserviços (eu diria <em>nano</em>) que sejam <strong>realmente</strong> pequenos.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>Para saber mais</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Achou legal esta possibilidade? Quer se aprofundar a respeito? Então seguem alguns links que me ajudaram e com certeza vão te ajudar também.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><strong>Documentação oficial do Spring CLI</strong> - <a href="https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-cli.html#cli-multiple-source-files" class="rank-math-link">https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-cli.html#cli-multiple-source-files</a> </p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><strong>Introduction to Spring Boot CLI - Baeldung</strong> - excelente texto por sinal - <a href="https://www.baeldung.com/spring-boot-cli" class="rank-math-link">https://www.baeldung.com/spring-boot-cli</a></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><strong>Documentação do Actuator, que usei neste post como exemplo</strong> - <a href="https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html" class="rank-math-link">https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html</a></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Conhecia a solução? Já a experimentou? Compartilhe conosco sua experiência com esta!</p>
<!-- /wp:paragraph -->