APIs e Microsserviços

19 mai, 2017

Migrando sua API Java para Kotlin com Spring Boot – Parte 01

Publicidade

Olá!

Hoje vou mostrar um exemplo de como podemos migrar uma pequena API Java que utiliza um banco de dados MongoDB para Kotlin. Na minha opinião, o maior facilitador dessa transposição de linguagem é o Spring Boot, além do fato do Kotlin rodar na JVM. Primeiro, vamos criar uma aplicação Java do zero, fazer alguns testes, e depois criar a mesma aplicação em Kotlin, que deverá ter os mesmos comportamentos.

Vamos lá?

Para nossa primeira POC, vamos criar um projeto do zero utilizando o Spring Boot, Java 8 e o MongoDB. Nosso projeto será bem básico e para isso, vamos usar como exemplo a criação de um objeto do tipo Carro, que terá como atributos apenas  marca e modelo. Assim que inserirmos essas informações no banco de dados, criaremos três serviços REST para consulta dos carros. Um para pesquisa geral e outros dois para consulta por marca e por modelo.

Então, mãos à obra! Pré-requisitos:

  • Java instalado (recomendo o 8);
  • IDE de sua preferência (vou usar o IntelliJ);
  • MongoDB instalado (ou qualquer outro banco) Aqui tem alguns links para ajudar na instalação do Mongo:
  • Acesso à internet para criar o projeto no Spring Initializr.

Faremos o start de nosso projeto no site do Spring Initializr para configurarmos as dependências que vamos usar na nossa app Java. Em search for dependencies, vamos selecionar WEB e MongoDB apenas.

Assim que for concluído o download do projeto, abra-o em sua IDE de preferência para iniciarmos o desenvolvimento e aguarde até que as dependências sejam baixadas. Nesse pequeno projeto, utilizarei o Intelli.

Vamos criar um package chamado Model e dentro uma classe chamada Car. Em nossa classe, vamos declarar as variáveis (id, brand e model). Anotaremos essa classe com @Document para o spring boot fazer o mapeamento para nosso banco de dados MongoDB. Faremos também a anotação do atributo id com @Id para o framework criar nossas chaves primarias dentro do banco de dados. Ao final, nossa classe deverá ficar parecida com  a imagem abaixo:

Com essa etapa concluída, vamos agora criar um package chamado repository e dentro dele, a interface CarRepository. Nossa interface vai estender MongoRepository com os atributos Car (em referência à nossa entity Car) e String (em referência ao tipo da nossa chave primária id, que nesse caso é uma String em função do nosso banco de dados Mongo). Em nossa interface, vamos declarar os métodos all(), findByBrand() e findByModel() conforme abaixo:

Vamos, agora, ao nosso controller. Seguindo a estrutura aplicada nesse projeto, vamos criar um package controller e a classe CarController. Feito isso, podemos escrever nossos endpoins de consulta para atenderem requisições em:

(“ / ”) -> para pesquisa de todos os carros;
(“ /brand”) -> para pesquisa por marcas;
(“ /model”) -> para pesquisa por modelos.

Agora, vamos inserir no banco de dados alguns registros para podermos consumir nossos endpoints. Para isso, vamos criar uma nova classe (em um package de sua preferência) e anotá-la com @Component. Essa classe deve implementar CommandLineRunner e o papel dela é inserir alguns registros no banco de dados.

Assim que nossa classe estiver pronta, como nesse exemplo, vamos usar o MongoDB. Para isso, temos que lembrar de levantá-lo primeiro. Em um terminal, digite “mongod” para subir o serviço do mongo.

Obs: esse comando pode mudar no Windows ou no Linux, ok?

Feito isso, podemos rodar nosso projeto pela primeira vez. Vamos acompanhar na saída do console e checar nos logs se os dados foram inseridos.

Legal! Mas será que, de fato, essas informações estão em nosso banco de dados? Podemos conferir no terminal. Vamos abrir uma nova instância e digitar “mongo”. Nesse momento, vamos acessar o “console” do mongo. E para verificar nosso registro, vamos digitar “db.car.find()”, onde db trata da sintaxe do mongo (isso não deve mudar entre as versões do sistema operacional), car de fato é nossa tabela e find() é a sintaxe do mongo equivalente ao select * from do mysql e outros bancos.

Agora que nossos registros de fato estão no banco de dados, podemos testar nossos endpoints. Primeiro, vamos testar o de pesquisa geral, e para isso podemos utilizar nosso bom e velho console ou algum programa de sua preferência para consumir serviços Rest. Nesse exemplo vou usar o terminal, ok? A sintaxe do comando fica assim:

“curl http://localhost:8080/ -H ‘Content-Type: application/json’ | json_pp”

Agora, podemos testar nossos outros dois endpoints de pesquisa por modelo e por marca. A sintaxe do comando será parecida, mas devemos nos atentar que como vamos passar no Body da requisição um parâmetro que utilizaremos como chave na pesquisa, nosso comando ficará assim:

Por modelo: “curl -X POST http://localhost:8080/model -H ‘Content-Type: application/json’ -d ‘{“model”:”A4″}’ | json_pp”

Por marca: “curl -X POST http://localhost:8080/brand -H ‘Content-Type: application/json’ -d ‘{“brand”:”VW”}’ | json_pp

Gostaram? Esse foi um pequeno exemplo para podermos chegar no assunto principal desse artigo: como migrar uma API Java para Kotlin.

Mas antes ainda: já ouviu falar do Kotlin? É uma linguagem de programação bem expressiva que roda na máquina virtual Java e pode igualmente pode ser compilada no código fonte do JavaScript e no Android. O Kotlin também é orientado a objetos, imutável por padrão e está focado na interoperabilidade, segurança, clareza e suporte a várias ferramentas.

É desenvolvido pela JetBrains (mesma criadora do IntelliJ, Webstorm e outros). Foi em 2011 que a JetBrains lançou o projeto do Kotlin, que já estava em desenvolvimento há um ano. O líder da JetBrains, Dmitry Jemerov, disse que a maioria das linguagens de programação não tinham as características que ele estava procurando, com exceção do Scala que, por sua vez, tinha um tempo lento de compilação como uma deficiência óbvia. Por isso, um dos objetivos do Kotlin é compilar tão rápido quanto o Java. Em fevereiro de 2012, foi aberto pela JetBrains o projeto sob licença da Apache 2.0, e a versão 1.0 do Kotlin foi lançada em 15 de fevereiro de 2016. Esta é considerada pela JetBrains a primeira versão oficialmente estável, e a empresa se comprometeu com a compatibilidade de versões anteriores a longo do prazo a partir desta versão.

Sendo uma linguagem de uso geral, o Kotlin funciona em qualquer lugar que o Java funcione, ou seja, APPs do lado do servidor, APPs móveis (Android) e APPs desktop.

Ele também funciona com todas as principais ferramentas e serviços como:

  • Eclipse, Android Studio e IntelliJ IDEA
  • Ant, Gradle e Maven
  • SpringBoot (suporte ao Kotlin lançado em fevereiro de 2016)
  • Github

Um dos focos do Kotlin é a interoperabilidade e o suporte contínuo para projetos mistos Java + Kotlin (embora esse tema ainda possa ser muito discutido, visto que mesmo que eles  possam trabalhar bem juntos, é preciso se perguntar: vale a pena o acoplamento?). De qualquer forma, essas características tornam a adoção mais fácil e levam a um menor número de código e mais segurança de tipos. Além disso, o Kotlin possui uma extensa biblioteca padrão que torna as tarefas diárias mais fáceis e suaves, enquanto mantém uma baixa marca de bytecode. Naturalmente, qualquer biblioteca Java pode ser usada com Kotlin e vice-versa.

Devemos utilizar? É maduro o suficiente e está pronto para produção?

Segundo a JetBrains, sim. Os criadores do Kotlin estão utilizado-o em projetos reais e de grande escala nos últimos dois anos. Informam também que existem algumas empresas que vêm utilizando o Kotlin na produção por algum tempo.

O Kotlin possui código aberto e, segundo a JetBrains, demorou bastante para chegar à versão 1.0 devido à grande atenção para validar as decisões de design na prática. Isso é necessário, pois mesmo com o avanço do compilador, o Kotlin deve funcionar tanto com versões anteriores, quanto futuras que não deverão quebrar o código existente.

Se o Kotlin é open source, quem o mantém? O código do Kotlin está disponível no GitHub sob a licença 2.0 Open-Source do Apache e hoje conta com aproximadamente 140 contribuintes. A JetBrains é a principal patrocinadora no momento, tem investido muito esforço no seu desenvolvimento e diz estar comprometida com o projeto a longo prazo.

Nós o escrevemos de nossa própria necessidade de usá-lo em produtos próprios. E estamos felizes em dizer que, até a data, cerca de 10 produtos JetBrains, que incluem IntelliJ IDEA, JetBrains Rider, Conta JetBrains e E-Shop, Your Track bem como algumas de nossas IDE’s menores e alguns projetos internos estão adotando. Então, podemos dizer que ele está aqui para ficar.

A JetBrain ainda comenta que desde 2012 manteve o desenvolvimento do Kotlin muito aberto, conversando com a comunidade, fazendo reuniões e abordando diversos comentários. Como avanço, estão planejando a criação de um lugar centralizado para as propostas de design e discussões, para tornar o processo ainda mais visível e organizado. Atualmente, o design de linguagem e a direção geral do projeto é feita pela equipe do JetBrains, que conta com mais de 20 pessoas trabalhando em tempo integral no Kotlin.

Curiosidade: Kotlin teve seu nome baseado na ilha de Kotlin, situada na cidade Kronstadt, próximo a São Petersburgo.

Os números do Kotlin:

  • 11K de pessoas utilizando o Kotlin até o mês passado;
  • Centenas de perguntas e respostas no StackOverflow;
  • Dois livros: Kotlin in Action e Kotlin for Android Developers;
  • Cerca de 6K de pessoas no Slack (get an invite);
  • Mais de 500K de linhas de código Kotlin em projetos como IntelliJ IDEA e Rider.

Falando sobre linhas de código, o número destes repositórios abertos no GitHub está crescendo exponencialmente ao longo do tempo (incluindo projetos da JetBrains).

Bom, acho que deu para ter um pouco de visão do Kotlin, né? Então, vamos parar de assunto chato e vamos para o código.

Mas só no próximo artigo! Na próxima sexta eu volto com os códigos. Tem alguma dúvida ou alguma observação? Aproveite os campos abaixo.

Até lá!

***

Artigo publicado originalmente em: https://www.concretesolutions.com.br/2017/05/10/api-java-kotlin-spring-boot/