Quarkus: um ambiente local para vários serviços
O Quarkus já resolveu a parte que a maioria dos frameworks faz mal: o dev mode recarrega ao guardar e os Dev Services levantam-te um contentor para a base de dados que te esqueceste de arrancar. O que não resolve é o serviço do lado, nem o seguinte.
Onde para o dev mode
- É por serviço. Cinco serviços são cinco terminais, cinco dev modes e lembrar-se de que porta cada um apanhou.
- Os Dev Services também são por serviço. Cada um que quer uma base de dados leva o seu próprio contentor. Isso é bom para isolar e é mau para um fluxo em que três serviços leem o mesmo topic de Kafka.
- Os URLs entre serviços continuam a ser coisa tua. Cada
@ConfigPropertyou URL base de um cliente REST que aponta a outro serviço tem de apontar para algum sítio quando não levantas o sistema inteiro. - A ordem continua a importar. O reload não ajuda se a dependência não estava a responder quando arrancou quem a chama.
O que o Aseptic acrescenta
O Aseptic deteta um serviço Quarkus pelo seu manifesto e arranca-o como processo nativo com a
tua ferramenta de build, injetando a configuração ao arrancar como propriedades
-D ou variáveis de ambiente. Os URLs entre serviços são reescritos aí, por isso o
application.properties fica exatamente como está em git.
Um cenário é o fluxo: os serviços que participam, a ordem de que precisam e onde se resolve cada dependência —um serviço local, o vosso ambiente partilhado na nuvem ou um mock—. As portas que colidem são remapeadas e o valor novo é o que se conta a quem chama.
Para a infraestrutura comum, o Aseptic levanta Kafka, Redis e PostgreSQL em Docker uma vez, para todo o cenário, e aponta todos os serviços à mesma instância. Essa é a diferença com os Dev Services: um broker que o fluxo partilha, em vez de um por serviço. Se para uma execução concreta preferires os Dev Services, nada to impede: o Aseptic arranca o teu serviço como tu lhe disseres.
Bibliotecas em que estás a mexer ao mesmo tempo
Se a funcionalidade abrange um serviço e uma biblioteca tua, o Aseptic constrói a biblioteca e liga-a onde o Maven e o Gradle a resolvem, reconstruindo-a e voltando a ligá-la quando muda. O ficheiro de build do consumidor nunca é editado, e desligar desfaz só o que o Aseptic pôs.
O que não faz
Não substitui o dev mode, nem devia: recarregar ao guardar é coisa do Quarkus e fá-lo melhor do que qualquer lançador poderia acrescentar. Não constrói imagens nativas nem executa um cluster de Kubernetes, por isso tudo o que precises de verificar a esse nível é de outro sítio. E precisa de Docker instalado para a infraestrutura comum.
Está em beta pública, publica-se para Windows, macOS e Linux, e é grátis para uso pessoal.
Ao lado das alternativas
Se os teus serviços já estão em contentor e são implantados com manifestos que manténs, o Tilt e o Skaffold dão-te um ciclo com a forma de produção. A página de alternativas ao Docker Compose cobre o campo inteiro.
Há equivalentes desta página para Spring Boot e para Node.
Perguntas frequentes
Não me basta o modo dev do Quarkus?
Para um serviço, é excelente. O que o modo dev não resolve é quem arranca os restantes, por que ordem e contra o quê: assim que o fluxo passa por três serviços, essa parte continua a ser tua.
O Aseptic parte o hot reload do Quarkus?
Não. O serviço é arrancado como processo nativo com o seu próprio comando, por isso o hot reload é o do costume.
Posso misturar Quarkus com serviços de outro stack?
Sim. O motor não leva lógica de uma tecnologia concreta: cada stack tem o seu perfil e podem conviver num mesmo cenário.