Se você chegou até aqui, é por que está interessado nas vantagens que a ferramenta JHipster pode trazer aos seus projetos de desenvolvimento de aplicações como, por exemplo, ganho de produtividade, utilização de tecnologias modernas, robustez, desempenho e boas práticas de mercado. Mas caso você tenha caído de paraquedas neste conteúdo, talvez queira dar uma conferida neste outro artigo onde apresento a ferramenta e detalho melhor essas vantagens: Introdução ao JHipster.

Dando início à nossa jornada, vale lembrar que para percorrê-la você vai precisar do Java 17 e do Node.js 18 ou versões mais recentes destes, além, claro, do próprio JHipster. Como utilizaremos o utilitário Maven, sua instalação também será necessária.

Informações sobre o ambiente

Este tutorial foi realizado em um Ubuntu 22.04.1 executando dentro do WSL em um host com Windows 11. As linhas de comando apresentadas são compatível com o Zsh (Z shell). Abaixo um quadro com a configuração utilizada para criar e executar o presente tutorial:

• Open JDK: 21.0.2 2024–01–16
• Maven: 3.9.6
• Node.js: 20.11.1
• npm: 10.2.4
• JHipster (generator-jhipster): 8.2.1

IMPORTANTE: caso ao executar o comando “jhipster” no terminal ele não seja reconhecido, confirme que o path “/bin/” esteja na sua variável de ambiente PATH. Para obter o HOME_NODE, execute o comando a seguir:

npm config get prefix

Iniciando a saga

O primeiro passo é criar um diretório onde será gerado o código da nossa aplicação e mover-se para dentro deste diretório:

mkdir minha-aplicacao-monolitica
cd minha-aplicacao-monolitica

Já dentro do diretório da futura aplicação, executamos o JHipster para iniciar a brincadeira:

jhipster

Conforme é possível ver no print logo a seguir, o JHipster exibirá uma sequência de prompts para o desenvolvedor responder. O primeiro deles é o nome da aplicação que, se não informado, usará uma variante do nome da pasta como resposta padrão. Em seguida, pede para o desenvolvedor selecionar um de três tipos de aplicação oferecidos pela ferramenta:

• Monolithic application
• Gateway application
• Microservice application

Para o propósito deste artigo, onde estamos criando uma aplicação simples, selecionaremos a primeira opção: Monolithic application.

Moldando o backend

A partir deste ponto, o desenvolvedor será questionado sobre um conjunto de opções de configuração voltadas para o backend da sua aplicação. A primeira delas é se o desenvolvedor quer utilizar outros frameworks de teste para a aplicação além do JUnit. Aqui poderíamos selecionar Gatling, Cucumber ou mesmo ambos. Para o nosso primeiro tutorial, vamos dispensar esses frameworks adicionais.

Na sequência, questiona se quer utilizar o framework Spring Webflux para tornar a aplicação reativa. Para este tutorial, vamos recusar e, assim, nossa aplicação utilizará o Spring MVC.

Ele pergunta então qual o nome padrão do pacote Java, vamos de: br.com.meucodigoagil.minhapp.

A seguir, ele pede para o desenvolvedor selecionar o tipo de autenticação que a aplicação deverá utilizar dando três opções:

• JWT authentication (stateless)
• OAuth 2.0 / OIDC Authentication (stateful)
• HTTP Session Authentication (stateful)

Ficamos com a primeira opção.

Então ele questiona sobre o tipo de banco de dados que a aplicação utilizará, tendo como opções SQL, algumas opções NoSQL e até mesmo a opção da aplicação não utilizar banco de dados:

• SQL (H2, PostgreSQL, MySQL, MariaDB, Oracle, MSSQL)
• MongoDB
• Cassandra
• Couchbase
• Neo4j
• No database

Após selecionar o tipo SQL, que é o que queremos para este tutorial, ele questionará qual banco SQL será utilizado em produção e, logo em seguida, pergunta se utilizaremos o mesmo banco em desenvolvimento ou se selecionaremos um banco de dados H2 com persistência em disco ou em memória. Selecionamos PostgreSQL e H2 com persistência em disco.

Na sequência, devemos selecionar uma das opções de cache suportadas:

• Ehcache
• Caffeine
• Hazelcast
• Infinispan
• Memcached
• Redis
• No cache

Para nosso tutorial, a primeira opção, Ehcache, nos atende. Logo a seguir, o JHipster questiona se queremos utilizar cache de segundo nível do Hibernate. Ficaremos com a reposta default: “Y” (sim).

A seguir podemos escolher entre Maven e Gradle como a ferramenta de build para o backend deste projeto. Selecionamos Maven.

Então, o JHipster nos oferece um cardápio de diversas outras tecnologias que queiramos acrescentar ao projeto:

• Elasticsearch
• WebSockets
• Apache Kafka
• Apache Pulsar
• API first development using OpenAPI-generator

Por ora, vamos manter a simplicidade do nossa aplicação e não marcaremos nenhuma opção.

A seguir uma imagem resumindo tudo que definimos até aqui e que será utilizado para geração do backend da nossa aplicação.

Moldando o frontend

Enfim, o CLI do JHipster começa a fazer questionamentos sobre o frontend da nossa aplicação. Começando por pedir que se escolha uma das opções de frontend possíveis:

• Angular
• React
• Vue
• No client

Das quais selecionaremos o Angular.

De forma semelhante ao que fez em relação ao backend, o JHipster também questionará se será utilizado um framework de testes adicional para o frontend, além do padrão Jest/Vitest. Para este caso, temos como opção a inclusão do Cypress. Vamos marcá-lo!

A seguir, será questionado se deve ser gerada ou não uma UI para administração da aplicação. Marcamos: “Y” (sim).

Na sequência, o JHipster lista um conjunto de temas Bootswatch para seleção. Deixamos marcada a opção padrão “Default JHipster”.

Quase perto do fim, temos a opção de internacionalizar nossa aplicação, selecionar o idioma nativo e os idiomas adicionais que serão suportados. Respondemos respectivamente: “Y” (sim), “Portuguese (Brazilian)” e “English”.

Finalmente, ele questiona se gostaríamos de utilizar uma funcionalidade experimental de cobertura de código para os testes do Cypress e, em seguida, se queremos auditar os testes Cypress. Respondemos “Y” (sim) para ambos.

No próximo print podemos visualizar todas as definições relacionadas ao frontend da nossa aplicação.

Pronto! Após responder a última pergunta, a mágica começa! Pode demorar alguns bons minutos dependendo da configuração da máquina sendo utilizada e da conexão com a internet.

Enquanto o JHipster trabalha duro nos bastidores, serão geradas várias mensagens de log no console. Ao final, se tudo correu bem, você deve visualizar mensagens semelhantes às da imagem a seguir.

Primeiros resultados

Finalmente, vamos ver o que o JHipster construiu pra nós. Para isso, vamos compilar a aplicação e executá-la para ver o que temos sob o ponto de vista do usuário. Para tal, basta executar o comando abaixo no diretório raiz da nossa aplicação recém nascida:

./mvnw

Na primeira vez, o Maven fará download das dependências para poder compilar o backend, o que pode demorar um pouco. Quando concluir todo o build e a aplicação for inicializada, você verá uma mensagem semelhante a esta no console:

----------------------------------------------------------
        Application 'minhaAplicacaoMonolitica' is running! Access URLs:
        Local:          http://localhost:8080/
        External:       http://127.0.1.1:8080/
        Profile(s):     [dev, api-docs]
----------------------------------------------------------

A partir de agora você poderá utilizar o seu navegador para acessar a URL apresentada na mensagem: http://localhost:8080/.

Ao carregar, será possível visualizar a página inicial da aplicação com três menus na parte superior direita.

Ao acessar o menu “Conta” e a opção “Entrar”, um formulário de login será exibido e você poderá se autenticar utilizando o usuário “admin” e a senha também “admin”. Neste instante, mais dois menus são exibidos: “Entidades” e “Administração”.

No menu “Administração”, podemos acessar telas de papéis/roles (Authorities), gerenciamento de usuários, métricas da aplicação, estado do sistema, configurações de níveis de logging, documentação swagger das APIs etc.

Contudo, você notará que se clicarmos no menu “Entidades”, nada acontece e nenhuma opção é exibida. Bem … você se lembra que passamos por uma variedade de perguntas, mas em nenhuma delas nós informamos quais seriam as entidades que nossa aplicação manteria. Pois chegou a hora!

Criando Entidade

Criaremos neste tutorial nossa primeira entidade e, para isso, utilizaremos novamente o JHipster CLI. Mas antes precisamos definir que tipo de aplicação estamos criando … bem … que tal fazermos uma aplicação para gerenciar investimentos, assim podemos cadastrar produtos de investimento, transações de compra e venda/resgate, proventos etc. Vamos nessa!

Para criar uma entidade basta executar o comando "entity" do JHipster CLI informando seu nome. O nome da nossa primeira entidade será "produto":

jhipster entity produto

A partir daí, seremos questionados sobre a entidade Produto que estamos criando, começando pela pergunta se queremos adicionar um campo a nossa nova entidade, que respondemos com "Y" (sim).

Em seguida, informamos qual seria o nome deste campo. Talvez, a primeira opção que veio à sua mente foi um campo identificador da entidade, mas este campo não é necessário pois ele já faz parte de uma entidade criada pelo JHipster. Assim, vamos responder com: “nome” e, para o tipo, “String”.

A seguir, o JHipster pergunta se queremos incluir alguma regra de validação para o nosso campo “nome”, que responderemos com “Y” (sim). Entre as opções de validação oferecidas para um campo String temos:

• Required (campo obrigatório)
• Unique (campo de valores únicos na tabela)
• Minimum length (número mínimo de caracteres para os valores)
• Maximum length (número máximo de caracteres para os valores)
• Regular expression pattern (expressão regular)

Podemos marcar múltiplos ou nenhuma. Marcaremos “Required”, “Unique”, “Minimum length” e “Maximum length” e, na sequência, informaremos que o tamanho mínimo são 3 caracteres e o tamanho máximo são 100. Os prompts e respostas do nosso primeiro campo podem ser visualizados na imagem a seguir.

O JHipster repetirá então a primeira pergunta que ele fez logo no início, se gostaríamos de adicionar mais um campo à nossa entidade. Vamos responder “Y” (sim) e desta vez daremos o nome “tipo” e selecionaremos o tipo “Enumeration (Java enum type)”. Então, informamos o nome da classe do nosso enumerador como “TipoProduto” e, em seguida, informamos os valores possíveis separados por vírgulas e sem espaços: “Tesouro,CDB,Fundo,CRI,CRA,Debenture,Acao,FII,ETF,BDR,PGBL”.

Novamente, adicionaremos regras de validação ao nosso novo campo que, no caso de “Enumeration”, possui apenas as opções:

• Required
• Unique

Marcaremos apenas “Required” e, a fim de simplificarmos e agilizarmos a conclusão da nossa primeira aplicação, encerraremos aqui nossa primeira entidade informando ao JHipster que não adicionaremos mais campos.

Na sequência, o JHipster questiona se queremos usar uma classe de serviço separada para a lógica de negócio e são oferecidas as seguintes opções:

• No, the REST controller should use the repository directly
• Yes, generate a separate service class
• Yes, generate a separate service interface and implementation

Se selecionarmos a primeira opção, o controller do nosso Spring MVC chamará de forma direta os métodos da classe de dados anotada com @Repository. Como o propósito da nossa primeira aplicação é manter a simplicidade, ficaremos com a primeira opção por enquanto. Então, o JHipster CLI questiona se nossa entidade é somente leitura e respondemos com “N” (não).

Na sequência, seremos questionados se desejamos que nossa entidade tenha funcionalidade de paginação e ordenação de dados e temos as opções:

• No
• Yes, with pagination links and sorting headers
• Yes, with infinite scroll and sorting headers

Vamos mais uma vez optar pela simplicidade na nossa primeira aplicação: “N” (não) e o JHIpster começará a trabalhar para atender nosso pedido com as especificações que passamos ao longo dos prompts.

Durante a execução, o JHipster irá gerar novamente mais uma grande quantidade de mensagens de log no console e, em algumas delas, ele reportará conflito ao escrever alguns arquivos. Para esses, devemos responder se desejamos sobrescrever a versão anterior daquele arquivo. Vamos responder “a” (sobrescrever todas).

Resultado final

Quando o JHipster concluir seu trabalho, você poderá inicializar novamente a aplicação executado o comando abaixo:

./mvnw

Ao se autenticar com o usuário “admin” (senha “admin”), você perceberá que o menu “Entidades” agora possui uma opção “Produto”.

Ao clicar em "Produto", será exibida uma lista de produtos com dados sintéticos. Nesta nova tela, você poderá realizar as operações de CRUD na entidade produto: cadastrar, visualizar, atualizar e excluir.

Enfim, chegamos ao final do nosso primeiro tutorial que, diga-se de passagem, produziu uma aplicação bastante simples é verdade. Mas o propósito aqui foi apenas introduzir ainda de forma bem superficial o JHipster.

Brinque à vontade com a sua mais nova aplicação gerada com o menor esforço. Experimente cada uma das funcionalidades! Tente cadastrar ou alterar um produto de investimento que tenha menos de 3 ou mais de 100 caracteres.

Continue me acompanhando por aqui pois farei novas publicações a fim de aprofundarmos cada vez mais e, assim, explorarmos todo o potencial desta ferramenta.