Kotlin e Spring Boot: Uma transição natural para aplicações legadas em JAVA.

Quem já não passou pelo problema de ter um sistema grande e complexo que tanto em tecnologia como em regras de negócio foi ficando obsoleto? O que fazer nesses casos? Começar de novo, implementar as novas funcionalidades utilizando uma outra tecnologia, são algumas das perguntas frequentes que enfrentamos. Recentemente, tivemos que responder essas perguntas difíceis e gostaria de compartilhar um pouquinho o porquê das nossas escolhas e o que nos fez “virar a chave” e começar esse novo desafio.

Bom vamos lá!

Temos uma API gigantesca escrita em JAVA na qual foi fruto de muito pivot de projeto. Atualmente, estamos atuando em uma área mais específica e muita implementação desta API não faz mais sentido. Mas como assim não faz mais sentido? Nossa aplicação sempre foi focada em coleta de dados offline de qualquer informação. E como funciona? Hoje, possuímos uma rede de crowdsourcing (modelo de mão de obra e conhecimentos coletivos) com 55 mil usuários em nossa base de dados que são nossos “coletores” de dados. Basicamente, o usuário registrado recebe em seu celular um chamado pra coletar dados no local, data e horário específicos e cada coleta ele recebe $$ por isso! 😊. Além disso, 100% de nossas coletas são auditadas. Atualmente, não estamos coletando qualquer tipo de informação, mas apenas informações sobre Apartamentos, nossa função é entregar informações de leads relevantes e integrarmos esses dados com o restante da empresa. Por conta disso, acreditamos que nossa API precisa ser reformulada sendo que muita regra de nosso business “não faz mais sentido! Dessa forma surgiu a grande questão: Já que vamos reestruturar muita coisa, por que não iniciar em uma stack mais atual?

Figura 1 — Tela do nosso aplicativo que exibe os prédios a serem visitados por nossos usuários

Escolhemos começar continuando hahahahaha. Mas como assim? Muitas das regras do nosso modelo de negócio podem ser reaproveitadas, então porque reescrever tudo? Isso com certeza influenciou em nossa decisão tecnológica: Spring Boot com Kotlin. Hoje, temos algumas bibliotecas que nós mesmo desenvolvemos em Java e com a utilização do Kotlin, conseguimos aproveitá-las tranquilamente pois ele é totalmente interoperável com Java. Isso significa que, você pode começar a usá-lo assim que quiser em um projeto Java existente, sejam eles uma API, WEB e até mesmo um aplicativo Android, sem a necessidade de migrar nenhum código, e sem precisar esperar a oportunidade de um novo projeto para começar a utilizar a linguagem. Você pode inclusive inserir o código Kotlin em um projeto já existente hoje, chamá-lo a partir do código Java, e vice-versa, e não terá nenhum problema com isso. Este é mais um motivo para dar uma chance para a linguagem 😊. Outro fator que pesou bastante em nossa decisão foi a curva de aprendizado na linguagem. Além do Kotlin ser uma linguagem de sintaxe bem fácil, quando as coisas “apertam” podemos escrever código em Java e o IntelliJ (IDE criada pela JetBrains, a mesma que criou a linguagem Kotlin) converte para Kotlin 😮. E por último, por ser uma linguagem que está ganhando muitos adeptos por conta da sua sintaxe ser muito mais legível que o Java, podemos ter outros desenvolvedores na empresa nos ajudando, compartilhando e até porque não, implementando funcionalidades.

Ainda sobre a escolha do Kotlin, segue alguns dados divulgados pela JetBrains:

“Quase todos os desenvolvedores Kotlin (92%) estavam usando Java antes de começarem a usar o Kotlin. A maioria deles (86% de todos os usuários do Kotlin) ainda continua usando o Java.” Fonte: https://www.jetbrains.com/pt-pt/lp/devecosystem-2019/kotlin/

Ótimo!

Mas e o Spring Boot? Pra começar, o que é o Spring Boot?

É um framework Java que auxilia na criação de aplicações standalone. Logo, em sua configuração inicial, o Spring já lhe entrega ferramentas pré-configuradas que auxiliam a organização de tarefas de infraestrutura do projeto, que normalmente são bem custosas e levam um tempo considerável sempre que vamos iniciar um projeto. Assim, é possível deixar o desenvolvedor livre para pensar no que realmente importa, como as regras de negócio da aplicação gerando, consequentemente, um aumento de produtividade. O Spring adota convenção sobre configuração, evitando assim, o excesso de código. Logo, ele fornece as configurações de forma simplificada, com o mínimo necessário para criar uma aplicação e implantá-la no ambiente de produção.

Como é a estrutura do Spring Boot?

Ele está configurado para ter o mínimo de uma aplicação otimizada pronto pra subir em produção. Através do site https://start.spring.io/ conseguimos criar um template básico com as seguintes configurações.

Figura 2— Como criar um bootstrap da sua aplicação

Além disso, é possível criar um projeto Spring com Java ou Kotlin. Ou seja, isso já nos dá uma boa dica de interoperabilidade entre essas duas linguagens. Abaixo, segue um exemplo de configuração básica de um projeto Spring Boot:

Spring Boot

• spring-starter-web — Responsável por habilitar a parte web. Essa dependência entrega toda configuração necessária para rodar uma aplicação web. Ex: o Spring cria um servidor Apache Tomcat embarcado. Dessa forma não precisamos nos preocupar onde iremos rodar nossa aplicação;
• spring-starter-data-jpa — Responsável por habilitar o JPA e Hibernate;
• spring-starter-data-mongodb — Tudo que é necessário para plugar o mongodb na aplicação. Também podemos usar para outros tipos de banco de dados como Mysql e PostgreSQL;
• org.springframework.boot:spring-boot-devtools (Ferramenta de auxílio no desenvolvimento).

Obs: todos esses pacotes já possuem customizações para o ambiente de produção.

Essa estrutura inicial, favorece a configuração das dependências do projeto como o JPA/Hibernate, Web, Segurança. Ainda, ele já possui um servidor embarcado, facilitando a implantação em ambientes de desenvolvimento e produção. Para usuários de Maven ou Gradle, ele ajuda na organização das sub-dependências. Exemplo: Quando adicionamos uma dependência no pom.xml de um projeto Maven, através das sub-dependências ele já coloca todas as outras necessárias, facilitando a organização e gerenciamento de conflito, validação e compatibilidade. O dev-tools possui um conjunto de ferramentas para ajudar no desenvolvimento, como live-reload. Isso é ótimo principalmente em aplicações Java. O dev-tools utiliza cache para melhorar a performance, um exemplo disso é quando alteramos uma view no Thymeleaf (template engine para Java), ela automaticamente realiza as alterações e permite que você veja o resultado sem a necessidade de reiniciar o servidor. O Spring oferece diversas outras ferramentas como o Actuator que auxilia no entendimento do trafego e o estado da aplicação disponibilizando métricas como: health-check, http trace, entre outros. Ele faz tudo isso sem gerar linhas e mais linhas de código fonte, apenas através das convenções.

Bom, são por esses motivos que decidimos ir migrando aos poucos nossa API utilizando essa stack. Ambas as tecnologias são muito fortes no mercado, possuem uma grande comunidade e suporte.

Quais são nossos próximos passos?

Começar pelas beiradas, e implementar serviços e regras que não possuem ou possuem interdependência mínima com nosso modelo atual. A principal desvantagem que senti em relação a isso foi: um novo projeto, novo deploy, nova integração contínua, novo repositório, nova máquina, novo endpoint, entre outras. Ainda, nosso cliente deve ter o cuidado em tratar de forma correta as chamadas.

Espero ter conseguido compartilhar com vocês um pouquinho da nossa estratégia que, ao realizar mudanças no modelo de negócio, pode pintar aquela dúvida: continuar ou pivotar?

“Quer se juntar a nós e fazer parte dessa mudança? Se inscreva nas nossas vagas!” — link: https://jobs.lever.co/loft/

Até mais!