Apesar de ser uma ferramenta poderosa e que aumenta significativamente a produtividade na escrita de aplicações corporativas, o Spring Framework ainda é alvo de críticas a respeito do tempo necessário para se iniciar o desenvolvimento de novos projetos. Pensando nisso, foi introduzido no Spring 4.0 um novo projeto que tem, dentre seus objetivos, responder a estas críticas e, como veremos neste artigo, também mudar bastante nossa percepção acerca do desenvolvimento de aplicações para a plataforma Java EE. Este projeto é o Spring Boot.

A principal crítica feita ao Spring é sobre o modo como configuramos o seu container de injeção de dependências e inversão de controle usando arquivos de configuração no formato XML. Artefatos estes que, conforme aumentam de tamanho, se tornam cada vez mais difíceis de serem mantidos, muitas vezes se transformando em um gargalo para a equipe de desenvolvimento. No decorrer da história do framework vimos que este problema foi sendo tratado a partir de uma série de melhorias no modo como declaramos nossos beans a cada novo release: namespaces na versão 1.2, anotações na versão 2.0 e, finalmente, passamos a poder tratar arquivos XML como um artefato opcional no lançamento da versão 3.0, que nos trouxe a possibilidade de declarar nossos beans usando apenas código Java e anotações.

Outra crítica relevante diz respeito à complexidade na gestão de dependências. Conforme nossos projetos precisam interagir com outras bibliotecas e frameworks como, por exemplo, JPA, mensageria, frameworks de segurança e tantos outros, garantir que todas as bibliotecas estejam presentes no classpath da aplicação acaba se tornando um pesadelo. Não é raro encontrarmos em projetos baseados em Maven arquivos POM nos quais 90% do seu conteúdo sejam apenas para gestão de dependências. E esta é apenas a primeira parte do problema. O grande desafio surge quando precisamos integrar todos estes componentes.

O projeto Spring Boot (ou simplesmente Boot) resolve estas questões e ainda nos apresenta um novo modelo de desenvolvimento, mais simples e direto, sem propor novas soluções para problemas já resolvidos, mas sim alavancando as tecnologias existentes presentes no ecossistema Spring de modo a aumentar significativamente a produtividade do desenvolvedor.

O que é o Spring Boot?

Trata-se de mais um framework, mas talvez a melhor denominação seja micro framework. Como mencionado na introdução deste artigo, seu objetivo não é trazer novas soluções para problemas que já foram resolvidos, mas sim reaproveitar estas tecnologias e aumentar a produtividade do desenvolvedor. Como veremos mais à frente, trata-se também de uma excelente ferramenta que podemos adotar na escrita de aplicações que fazem uso da arquitetura de microsserviços.

Se pudéssemos desenhar um diagrama arquitetural do Spring Boot, este seria muito similar ao que vemos no Grails: uma fina camada sobre tecnologias já consagradas pelo mercado, tal como podemos verificar na Figura 1. A grande mudança está no modo como agora empacotamos e acessamos estas soluções.

Posicionamento do Spring Boot no ecossistema Spring
Figura 1. Posicionamento do Spring Boot no ecossistema Spring.

O desenvolvedor não precisa se preocupar em aprender novas tecnologias, pois todo o conhecimento adquirido sobre o ecossistema Spring é reaproveitado. A principal diferença se dá no modo como configuramos, organizamos nosso código e executamos a aplicação, tal como veremos neste artigo.

Como sabemos, todo framework se baseia em alguns princípios. No caso do Boot, são quatro:

  1. Prover uma experiência de início de projeto (getting started experience) extremamente rápida e direta;
  2. Apresentar uma visão bastante opinativa (opinionated) sobre o modo como devemos configurar nossos projetos Spring mas, ao mesmo tempo, flexível o suficiente para que possa ser facilmente substituída de acordo com os requisitos do projeto;
  3. Fornecer uma série de requisitos não funcionais já pré-configurados para o desenvolvedor como, por exemplo, métricas, segurança, acesso a base de dados, servidor de aplicações/servlet embarcado, etc.;
  4. Não prover nenhuma geração de código e minimizar a zero a necessidade de arquivos XML.

Uma visão opinativa sobre a configuração?

Na documentação oficial do projeto Boot, assim como em posts a seu respeito, encontraremos muitas vezes o termo opinionated view (visão opinativa). Ao citá-lo, os responsáveis pelo desenvolvimento da ferramenta na realidade estão se referindo ao conceito de convenção sobre configuração, porém levemente modificado.

O conceito de convenção sobre configuração é o grande motor por trás do ganho de produtividade do Spring Boot, porém não foi algo introduzido por ele. Frameworks como Ruby on Rails e Grails já o aplicam há bastante tempo. A ideia é bastante simples: dado que a maior parte das configurações que o desenvolvedor precisa escrever no início de um projeto são sempre as mesmas, por que já não iniciar um novo projeto com todas estas configurações já definidas?

Pense no modo como estamos habituados a trabalhar, por exemplo, em um projeto baseado em Spring MVC. Nossos primeiros passos serão incluir as dependências necessárias no projeto, adequar o arquivo web.xml e organizar a estrutura do nosso código fonte para que possamos iniciar o desenvolvimento. E isto é feito no início de todo projeto. Sendo assim, por que não já começar com isto pronto?

Voltando nossa atenção para esse termo, é importante prestar atenção na palavra sobre em “convenção sobre configuração”. Note que não é “convenção em vez de configuração”. Não temos uma imposição aqui, mas sim sugestões. Deste modo, se seu projeto requer um aspecto diferente daquele definido pelas convenções do framework, o programador precisa alterar apenas aqueles locais nos quais a customização se aplica.

Indo além na análise dos termos mencionados, percebemos que no Spring Boot não foi usado o termo “convenção sobre configuração”, mas sim “visão opinada sobre configuração”. Dito isso, você pode estar se perguntando: Qual a diferença entre eles? A diferença está no fato da equipe de desenvolvimento do Spring Boot assumir que algumas escolhas tomadas baseiam-se em aspectos subjetivos e não estritamente técnicos. Um exemplo é a escolha da biblioteca de log. Foi adotado o Log4J, no entanto o Commons Logging seria uma opção igualmente competente. Sendo assim, por que um ao invés do outro? Em grande parte, preferências pessoais.

Há outra grande vantagem na adoção deste princípio. A partir do momento em que a equipe conhece as convenções, torna-se menor o tempo necessário para que novos membros se adaptem ao projeto e a manutenção passa a ser mais simples.

Spring Scripts

O projeto Spring Boot nos permite criar dois tipos de aplicações: as tradicionais, escritas primariamente em Java; e uma segunda forma, chamada pela equipe de desenvolvimento do Boot de “Spring Scripts”, que nada mais são do que códigos escritos em Groovy – o que não é de se estranhar, dado que desde o lançamento da versão 4.0 do framework há uma forte tendência da Pivotal em abraçar esta linguagem de programação e torná-la cada vez mais presente no dia a dia do programador Java.

Para ilustrar esse tipo de aplicação, vamos escrever um “Olá mundo!” bastante simples que nos conduzirá na apresentação de alguns conceitos fundamentais por trás do Spring Boot. Todo o código fonte do nosso projeto pode ser visto na Listagem 1.

	@RestController
	class OlaMundo {
		@RequestMapping("/")
		String home() {
			"Olá mundo!"
	}
	  }

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo