DEV Community: Meu Código Ágil

JHipster 8 - Analisando o código da nossa primeira aplicação monolítica - Parte 3/3

Meu Código Ágil — Wed, 22 May 2024 12:01:50 +0000

Chegamos finalmente à parte final da análise do código da nossa aplicação, vamos encarar agora o código frontend gerado pelo JHipster que, como escolhido durante os prompts apresentados, está baseado no framework Angular.

Vimos ao longo desta análise que o código do frontend está sob o diretório src/main/webapp. Assim como no backend, o JHipster também gera um volume grande de código. Assim, vou manter o foco nos pontos mais importantes.

Vale relembrar que os arquivos de configuração do nosso frontend, tais como package.json, tsconfig.json, angular.json, jest.conf.jsetc, são armazenados na raiz da nossa aplicação e já foram abordados no primeiro post desta série de análise de código.

webapp/i18n/

Sob este diretório encontramos um subdiretório para cada um dos idiomas suportados pela nossa aplicação, os quais selecionamos durante os prompts apresentados pelo JHipster:

└── webapp
    ├── i18n
    │   ├── en
    │   └── pt-br

Dentro de cada um dos subdiretórios, encontramos 18 arquivos JSON contendo textos no respectivo idioma a serem exibidos nas diversas páginas da UI da aplicação de acordo com o idioma selecionado pelo usuário. Abaixo um exemplo do arquivo pt-br/error.json:

{
  "error": {
    "title": "Página de erro!",
    "http": {
      "400": "Requisição inválida.",
      "403": "Você não tem autorização para acessar esta página.",
      "404": "A página não existe.",
      "405": "O verbo HTTP utilizado não é suportado para essa URL.",
      "500": "Erro interno do servidor."
    },
    "concurrencyFailure": "Outro usuário modificou esses dados ao mesmo tempo que você. Suas modificações foram rejeitadas.",
    "validation": "Erro de validação no servidor."
  }
}

Portanto, quando precisar fazer um ajuste nos textos exibidos na interface com o usuário, você já sabe onde alterar.

webapp/content/

Aqui o JHipster incluiu os assets do frontend: arquivos de imagem e arquivos de estilo CSS ou SCSS. Quando for trocar a logo da aplicação, por exemplo, é aqui que você vai guardar o arquivo de imagem. Quando for mudar cores, tamanho, fontes etc ... vai ser aqui também.

└── webapp ├── content │ ├── css │ ├── images │ └── scss

webapp/app/

No subdiretório app encontraremos a grande maioria dos arquivos fonte do frontend. Aqui está o código de todos os componentes da interface com o usuário, das telas compostas por esses componentes, rotas, serviços, interceptadores etc.

☢️ EITA! PARA TUDO!!!⚠️
Caso você seja um desenvolvedor backend raiz, tenho certeza que quase infartou no último parágrafo. Na verdade, já está sentido calafrios desde que resolveu parar pra ler este post, correto?

Já que você me deu essa moral de chegar até aqui, eu escrevi um outro post Off Topic com uma nano introdução sobre alguns conceitos básicos de Angular.

Acredito que vai ajudar pra que esse post não fique muito abstrato e uma leitura excessivamente chata pra você. Acessa aí, veja se ajuda, dê seu feedback e depois volte aqui pra continuar nossa análise:

[Off Topic] Nano introdução do framework Angular para Devs do back

Mas se você já está familiarizado com o Angular e quiser dar umas dicas de como a gente pode deixar esse post mais didático ou mais preciso, dá um confere lá também e mande seus comentários ;)

Começando pela raiz do subdiretório app, alguns elementos aqui merecem atenção:

app-routes.ts: como o nome já sugere, aqui estão declaradas as rotas principais da nossa aplicação.

const routes: Routes = [
  {
    path: '',
    component: HomeComponent,
    title: 'home.title',
  },
  ...
  {
    path: 'login',
    component: LoginComponent,
    title: 'login.title',
  },
  ...
  {
    path: 'admin',
    data: {
      authorities: [Authority.ADMIN],
    },
    canActivate: [UserRouteAccessService],
    loadChildren: () => import('./admin/admin.routes'),
  },
  {
    path: 'account',
    loadChildren: () => import('./account/account.route'),
  },
  ...

app.config.ts: entre outras coisas, neste arquivo está o provimento das rotas declaradas acima:

import routes from './app.routes';
...
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, ...routerFeatures),
    ...

webapp/app/account/

Adentrando na estrutura em ordem alfabética, temos este diretório que reúne todos os componentes e serviços relacionados às contas de usuários da nossa aplicação. Como podemos observar, o JHipster ainda subdividiu os componentes e serviços em grupos relacionados ao registro, a ativação de usuário, reinicialização de senha etc.

├── account
│   ├── activate
│   ├── password
│   │   └── password-strength-bar
│   ├── password-reset
│   │   ├── finish
│   │   └── init
│   ├── register
│   └── settings

webapp/app/admin/

Neste diretório, encontramos os componentes e serviços relacionados à administração da aplicação. Uma das principais e sempre é gerada pelo JHipster é a de administração de usuários da aplicação, user-management. Através do serviço e do conjunto de componentes ali implementados, um administrador poderá visualizar os dados dos usuários registrados e dar manutenção. Um outro grupo de funcionalidades, relacionados a métricas, logs e informações sobre o estado da aplicação, só está disponível porque, durante os prompts do JHipster, nós optamos pela geração da UI de administração.

├── admin
│   ├── configuration
│   ├── docs
│   ├── health
│   ├── logs
│   ├── metrics
│   └── user-management

webapp/app/config/

Aqui fica uma série de configurações default da aplicação. Por exemplo:

authority.constants.ts: declara um enumerador Typescript com as roles ADMIN e USER utilizadas ao longo da aplicação para condicionar seu funcionamento. Suponhamos que e a lógica da nossa aplicação demandasse um outro papel com acessos intermediários entre o ADMIN e o USER, poderíamos criar aqui um novo elemento MANAGER no enumerador e referenciá-lo ao longo da aplicação onde fosse aplicável.

font-awesome-icons.ts: temos o import de alguns ícones específicos da dependência @fortaawesome/free-solid-svg-icons que são utilizados ao longo da nossa UI.

pagination.constants.ts: define, entre outros, o número de registros padrão em cada página para as entidades que possuem busca paginada. Caso queiramos modificar essa quantidade de registros para todas as entidades paginadas, simplesmente podemos editar aqui essa constante.

webapp/app/core/

Aqui encontramos uma série de serviços e classes com funcionalidades auxiliares que serão utilizadas de forma transversal ao longo da aplicação segmentados em subdiretórios:

auth: implementa serviços relacionados a autenticação com JWT, manutenção de estado na sessionStorage e lógica de autorização baseda em papéis utilizada na declaração das rotas (CanActivate).

config: possui um serviço de configuração da aplicação.

interceptors: contém um conjunto de interceptadores de requisições HTTP utilizados, por exemplo, para adicionar o HTTP HEADER Authorization com o token JWT às requisições aos endpoints do backend, identificar requisições com JWT expirado e redirecionar o usuário para a tela de login, tratar outros erros HTTP não relacionados a autenticação etc.

webapp/app/entities/

Neste diretório encontramos a lógica associada às entidades suportadas pela aplicação. Tanto as entidades relacionadas ao contexto de segurança, user e authority quanto as entidades do domínio da nossa aplicação que, até agora, temos tão somente a produto.

├── entities
│   ├── produto
│   │   ├── delete
│   │   ├── detail
│   │   ├── list
│   │   ├── route
│   │   ├── service
│   │   └── update

Podemos ver já pela estrutura que a entidade tem suas funcionalidades segmentadas em subdiretórios:

list: provê o componente que é a porta de entrada da entidade Produto, responsável por carregar os dados e apresentar em forma tabular.

 @if (produtos && produtos.length > 0) {
    <div class="table-responsive table-entities" id="entities">
      <table class="table table-striped" aria-describedby="page-heading">
        <thead>
        ...

details: implementa o componente que exibirá os dados detalhados de um produto.

delete: dispõe do componente que solicita a confirmação do usuário quando solicitada a exclusão de um produto e, confirmando-se, faz chamada ao método delete do ProdutoService.

update: provê o componente de formulário tanto para criação quanto para manutenção dos dados de um produto.

    <form name="editForm" role="form" novalidate (ngSubmit)="save()" [formGroup]="editForm">
      <h2
        id="jhi-produto-heading"
        data-cy="ProdutoCreateUpdateHeading"
        jhiTranslate="minhaAplicacaoMonoliticaApp.produto.home.createOrEditLabel"
      >
        Criar ou editar Produto
      </h2>
      ...

service: implementa o serviço da entidade produto ProdutoService que provê as funcionalidades de interação com os endpoints do backend para realizar CRUD na entidade:

export class ProdutoService {
  protected http = inject(HttpClient);
  protected applicationConfigService = inject(ApplicationConfigService);

  protected resourceUrl = this.applicationConfigService.getEndpointFor('api/produtos');

  create(produto: NewProduto): Observable<EntityResponseType> {
    return this.http.post<IProduto>(this.resourceUrl, produto, { observe: 'response' });
  }

  update(produto: IProduto): Observable<EntityResponseType> {
    return this.http.put<IProduto>(`${this.resourceUrl}/${this.getProdutoIdentifier(produto)}`, produto, { observe: 'response' });
  }
  ...
  find(id: number): Observable<EntityResponseType> {
    return this.http.get<IProduto>(`${this.resourceUrl}/${id}`, { observe: 'response' });
  }
  ...
  delete(id: number): Observable<HttpResponse<{}>> {
    return this.http.delete(`${this.resourceUrl}/${id}`, { observe: 'response' });
  }

Vale chamar atenção também para o fato de que, na raiz do webapp/app/entities/produto, encontraremos um arquivo de definição de rotas específico para a entidade Produto, produto-routes.ts. É possível observar que a exibição de cada um dos componentes contidos nos subdiretórios que acabamos de analisar está atrelada ao path da URL:

const produtoRoute: Routes = [
  {
    path: '',
    component: ProdutoComponent,
    data: { defaultSort: 'id,' + ASC },
    canActivate: [UserRouteAccessService],
  },
  {
    path: ':id/view',
    component: ProdutoDetailComponent,
    resolve: { produto: ProdutoResolve },
    canActivate: [UserRouteAccessService],
  },
  {
    path: 'new',
    component: ProdutoUpdateComponent,
    resolve: { produto: ProdutoResolve },
    canActivate: [UserRouteAccessService],
  },
  {
    path: ':id/edit',
    component: ProdutoUpdateComponent,
    resolve: { produto: ProdutoResolve },
    canActivate: [UserRouteAccessService],
  },
];

webapp/app/layouts/

Neste diretório são implementados uma série de componentes relacionados ao layout visual da aplicação: rodapé, barra de navegação, componente de erro etc.

├── layouts
│   ├── error
│   ├── footer
│   ├── main
│   ├── navbar
│   └── profiles

webapp/app/shared/

Aqui temos componentes compartilhados entre as diversas telas, tais como: paginação, filtros, exibição de mensagem, formatação de data etc.

└── shared
    ├── alert
    ├── auth
    ├── date
    ├── filter
    ├── language
    ├── pagination
    └── sort

Conclusão

Ufa! Concluímos por aqui a série de análises do código da nossa aplicação monolítica gerado pelo JHipster. Neste último post da série, percorremos a estrutura de diretórios do frontend Angular. Detalhei um pouco aqueles pontos que me pareceram mais relevantes. Acredito que após esses três posts já temos uma boa noção do código que temos em mãos.

Nossa próxima missão é evoluir essa aplicação de forma que possamos conhecer outras funcionalidades do JHipster e, assim, aprofundarmos nosso conhecimento sobre essa poderosa ferramenta que tem um potencial enorme de acelerar os projetos de desenvolvimento das nossas organizações.

Fique à vontade para enviar suas dúvidas, comentários, sugestões e continue me acompanhando pois tem muito mais conteúdo vindo por aí! ;)

[Off Topic] Nano introdução do framework Angular para Devs do back

Meu Código Ágil — Wed, 22 May 2024 11:52:42 +0000

Fugindo um pouco do tema do canal, resolvi escrever esse post destinado aos Devs do backend que estão acompanhando a nossa jornada de descoberta da ferramenta JHipster. Caso você tenha caído aqui de paraquedas, trata-se de uma série de posts que começamos aqui.

Esse post não tem nem mesmo a pretensão de ensinar você a fazer um mero “Hello World” em Angular. A intenção aqui é apenas introduzir um conjunto pequeno de conceitos básicos do Angular para que os desenvolvedores que não têm a menor desenvoltura com frontend possam acompanhar menos agoniados as análises de código gerado pelo JHipster.

Durante as descrições dos conceitos abaixo, quando eu fizer referência a “nossa aplicação”, estou me referindo a uma aplicação monolítica exemplo que foi gerada com o JHipster 8 durante essa série de posts que citei acima. O post da geração da aplicação em si é este aqui, mas se preferir, o código também está no Github.

Estando tudo isso esclarecido, vamos começar? :)

Componente

uase tudo é um componente no Angular. Podemos entendê-lo como um código que encapsula HTML, CSS e lógica em Typescript. Não por acaso, tipicamente, um componente no Angular é formado por 3 arquivos: um HTML, um arquivo de estilos (CSS ou SCSS) e um arquivo TS. Tomemos como exemplo o componente app/home da nossa aplicação:

No arquivo home.component.scss, não tem nada além da definição de classes de estilos que vão estipular todas aquelas coisinhas que a galera de UI se amarra: posicionamento, tamanho, fontes, cores … nada que desperte encantos em um Dev do back, mas se for só pra dar uma olhadinha sem compromisso, também não assusta.

.hipster {
  display: inline-block;
  width: 347px;
  height: 497px;
  background: url('../../content/images/jhipster_family_member_3.svg') 
    no-repeat center top;
  background-size: contain;
}

No arquivo home.component.html, como você já deve ter imaginado, tem um monte de tags HTML, textos, referências a classes CSS. Nada que nós backenders não tenhamos visto antes, certo?

<div class="row">
  <div class="col-md-3">
    <span class="hipster img-fluid rounded"></span>
  </div>
  <div class="col-md-9">
    <h1 class="display-4">
      <span jhiTranslate="home.title">Bem vindo, Java Hipster!</span> 
      (Minha Aplicacao Monolitica)
    </h1>
    <p class="lead" jhiTranslate="home.subtitle">
      Esta é a página principal
    </p>  
...

Com exceção de coisinhas como esse @if (....) no trecho a seguir. Mas que, muito provavelmente, você já viu algo parecido em soluções que usavam templates como ASP, JSP etc … é só uma lógica de exibição de um trecho de HTML ou outro que faz referência a uma variável/atributo.

<div>
      @if (account() !== null) {
        <div class="alert alert-success">
          @if (account()) {
            <span id="home-logged-message" jhiTranslate="home.logged.message" [translateValues]="{ username: account()!.login }"
              >Você está logado como &quot;{{ account()!.login }}&quot;.</span
            >
          }
        </div>
      } @else {
        <div class="alert alert-warning">
          <span jhiTranslate="global.messages.info.authenticated.prefix">Se deseja </span>
          <a class="alert-link" (click)="login()" jhiTranslate="global.messages.info.authenticated.link">entrar</a
          ><span jhiTranslate="global.messages.info.authenticated.suffix"
            >, utilize as seguintes contas padrões:<br />- Administrador (usuário=&quot;admin&quot; and senha=&quot;admin&quot;) <br />-
            Usuário (usuário=&quot;user&quot; e senha=&quot;user&quot;).</span
          >
        </div>
        <div class="alert alert-warning">
          <span jhiTranslate="global.messages.info.register.noaccount">Não possui uma conta ainda?</span>&nbsp;
          <a class="alert-link" routerLink="/account/register" jhiTranslate="global.messages.info.register.link">Crie uma nova conta</a>
        </div>
      }

E adivinhe onde está essa variável … exatamente! Está na classe Typescript declarada no arquivo home.component.ts resumida a seguir:

@Component({
  standalone: true,
  selector: 'jhi-home',
  templateUrl: './home.component.html',
  styleUrl: './home.component.scss',
  imports: [SharedModule, RouterModule],
})
export default class HomeComponent implements OnInit, OnDestroy {

  account = signal<Account | null>(null);
  ...

  login(): void {
    this.router.navigate(['/login']);
  }
  ...
}

Perceba que a classe possui uma anotação @Component onde dois dos atributos que a anotação recebe são exatamente o path relativo dos arquivos HTML e SCSS. Outro atributo que cabe chamarmos atenção é o selector. Esse atributo define qual será a tag desse componente HomeComponent que o JHipster criou pra nós. Isso significa que poderíamos utilizar este componente dentro de outro componente utilizando a tag jhi-home como neste exemplo hipotético:

<div>
  <jhi-home></jhi-home>
</div>

Você vai encontrar no mesmo diretório o arquivo home.component.spec.ts. Por ora, basta saber que se trata dos testes unitários do componente.

Um último ponto para fecharmos a explicação sobre componentes Angular: um componente não precisa necessariamente ter o arquivo de estilos (CSS ou SCSS). Veja, por exemplo, o componente app/login da nossa aplicação:

@Component({
  selector: 'jhi-login',
  standalone: true,
  imports: [SharedModule, FormsModule, ReactiveFormsModule, RouterModule],
  templateUrl: './login.component.html',
})
export default class LoginComponent implements OnInit, AfterViewInit {
  @ViewChild('username', { static: false })
  username!: ElementRef;
  ...

Além de não ter um arquivo de estilos no diretório login, perceba que na anotação @Component o atributo styleUrl também não é setado. Mas olhando o seu template, o arquivo HTML, é possível notar referências a classes de estilo. Entretanto, essas classes vêm da pacote Bootstrap ou de algum dos arquivos da pasta webapp/content/scss.

<div class="d-flex justify-content-center">
   <div class="col-lg-6 col-md-8 col-sm-10">
     <h1 jhiTranslate="login.title" data-cy="loginTitle">Autenticação</h1>
     @if (authenticationError()) {
       <div class="alert alert-danger" jhiTranslate="login.messages.error.authentication" data-cy="loginError">
         <strong>Erro de autenticação!</strong> Por favor verifique suas credenciais e tente novamente.
       </div>
     }
     <form class="form" role="form" (ngSubmit)="login()" [formGroup]="loginForm">
  ...

Serviço

Aqui está um conceito que não vai deixar nenhum Dev backend desconfortável. Afinal, um Serviço é tão somente uma classe Typescript que fornece funcionalidades específicas para serem reutilizadas por distintas partes da aplicação. Não tem HTML, não tem CSS … é tão somente: CÓ-DI-GO!

Veja, por exemplo, o serviço app/core/auth/state-storage.service.ts que, basicamente, encapsula funcionalidades de ler, escrever e apagar dados na sessionStorage do navegador.

@Injectable({ providedIn: 'root' })
export class StateStorageService {
  private previousUrlKey = 'previousUrl';
  private authenticationKey = 'jhi-authenticationToken';
  private localeKey = 'locale';

  storeUrl(url: string): void {
    sessionStorage.setItem(this.previousUrlKey, JSON.stringify(url));
  }

  getUrl(): string | null {
    const previousUrl = sessionStorage.getItem(this.previousUrlKey);
    return previousUrl ? (JSON.parse(previousUrl) as string | null) : previousUrl;
  }

  clearUrl(): void {
    sessionStorage.removeItem(this.previousUrlKey);
  }

Sabe outro tipo de funcionalidade que também fica a cargo de Serviços? Requisições HTTP a APIs! Veja abaixo um trecho do serviço app/entities/produto/service/produto.service.ts:

@Injectable({ providedIn: 'root' })
export class ProdutoService { 

  protected http = inject(HttpClient);
  protected applicationConfigService = inject(ApplicationConfigService);

  protected resourceUrl = this.applicationConfigService.getEndpointFor('api/produtos');

  create(produto: NewProduto): Observable<EntityResponseType> {
    return this.http.post<IProduto>(this.resourceUrl, produto, { observe: 'response' });
  }

  ...
  find(id: number): Observable<EntityResponseType> {
    return this.http.get<IProduto>(`${this.resourceUrl}/${id}`, { observe: 'response' });
  }

  ...

Apenas para ficar mais claro, selecionei um método do componente app/entities/produto/update/produto-update.component.ts que mostra o método create do nosso ProdutoService sendo utilizado:

@Component({
  standalone: true,
  selector: 'jhi-produto-update',
  templateUrl: './produto-update.component.html',
  imports: [SharedModule, FormsModule, ReactiveFormsModule],
})
export class ProdutoUpdateComponent implements OnInit {

  protected produtoService = inject(ProdutoService);

  ...
  save(): void {
    this.isSaving = true;
    const produto = this.produtoFormService.getProduto(this.editForm);
    if (produto.id !== null) {
      this.subscribeToSaveResponse(this.produtoService.update(produto));
    } else {
      this.subscribeToSaveResponse(this.produtoService.create(produto));
    }
  }
...

Interceptador

Mais um treco que não vai assustar nenhum Dev do back, afinal, é só código também. Um interceptador tem o papel de interceptar e modificar requisições HTTP, tem função semelhante a dos filters da API Servlet do Java.

Com um interceptor, você pode por exemplo, inserir um cabeçalho Authorization em todas as requisições destinadas aos endpoints do backend. Se você abrir o interceptador app/core/interceptor/auth-interceptor.ts, vai constatar que é exatamente isso que ele está fazendo na implementação do método intercept:

@Injectable()
export class AuthInterceptor implements HttpInterceptor {
  private stateStorageService = inject(StateStorageService);
  private applicationConfigService = inject(ApplicationConfigService);

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const serverApiUrl = this.applicationConfigService.getEndpointFor('');
    if (!request.url || (request.url.startsWith('http') && !(serverApiUrl && request.url.startsWith(serverApiUrl)))) {
      return next.handle(request);
    }

    const token: string | null = this.stateStorageService.getAuthenticationToken();
    if (token) {
      request = request.clone({
        setHeaders: {
          Authorization: `Bearer ${token}`,
        },
      });
    }
    return next.handle(request);
  }
}

Rota

Uma rota define como o Angular responderá a diferentes URLs. Em outras palavras, uma rota define qual componente Angular será apresentado para um caminho de URL específico. Simples assim!

const routes: Routes = [
  {
    path: '',
    component: HomeComponent,
  },
  {
    path: 'login',
    component: LoginComponent,
  },
];

No exemplo acima, quando o usuário digitar no navegador http://localhost:4200/, o componente exibido pelo Angular será o HomeComponent. Já quando ele digitar ou for redirecionado para http://localhost:4200/login, é o LoginComponent que será exibido na interface do usuário.

Além de declarar as rotas da aplicação, elas precisam ser registradas para que a aplicação tenha o comportamento esperado.

As rotas que coloquei acima como exemplo estão declaradas da forma mais simples possível. Uma rota pode ser bem mais complexa que isso, ela pode por exemplo:

definir dados a serem enviados para o componente especificado na rota;
carregar outro conjunto de rotas dinamicamente;
implementar lógica a ser executada antes do carregamento do componente da rota. Por exemplo, para validar se o usuário tem as roles de acesso necessárias;
implementar lógica a ser executada antes de sair do componente da rota. Por exemplo, para pedir uma confirmação do usuário caso ele esteja abandonando um formulário no meio de uma edição sem salvar os dados.

Enfim … uma rota nos dá muitas possibilidades, mas acho que para a nano introdução do Angular à turma do backend que pretendíamos, podemos parar por aqui antes de causarmos uma repulsa indesejada rs

Mas se você chegou até aqui e ficou interessado em se aprofundar mais no assunto, o que não falta é gente gabaritada por aí ensinando Angular, até mesmo de graça. E, na boa? Aprender nunca é demais. Ainda que você não tenha intenção de (re)direcionar a sua carreira para o frontend, o conhecimento sobre o framework vai agregar muito na sua interação com os colegas responsáveis por esse nicho nos seus projetos.

Duas fontes que me ajudaram a entender melhor esse mundo (sim, apenas entender, eu não fui convertido rsrs) foram: o canal da Loiane Groner no YouTube e a Formação Angular na Alura. Sem falar, claro, nos próprios canais oficiais do Angular: o blog e o canal no YouTube.

JHipster 8 - Analisando o código da nossa primeira aplicação monolítica - Parte 2/3

Meu Código Ágil — Tue, 07 May 2024 00:23:13 +0000

Dando continuidade à nossa análise do código-fonte da aplicação monolítica que criamos utilizando o JHipster, vamos agora explorar o código Java do nosso backend. É importante lembrar que o código do backend é baseado no framework Spring Boot. No caso do JHipster 8, no Spring Boot 3.2.3 mais especificamente.

Conforme mencionado no primeiro post desta sequência voltada para a análise do código do nosso monolito, o volume de código gerado é bastante extenso, o que torna inviável abordar todos os detalhes sem se tornar cansativo. Portanto, selecionei criteriosamente os pacotes e classes que julgo mais importantes neste estágio em que nos encontramos nesta jornada de apresentação do JHipster 8.

Java

MinhaAplicacaoMonoliticaApp.java

Conforme definido durante os prompts do JHipster CLI ao construirmos nossa aplicação, o pacote base das classes da aplicação é br.com.meucodigoagil.minhapp, assim, nosso código fonte Java estará localizado no diretório src/main/java/br/com/meucodigoagil/minhapp e é exatamente aí que estará a classe principal da nossa aplicação: MinhaAplicacaoMonoliticaApp.

Como uma aplicação Spring Boot, é pela sua classe principal que a aplicação é inicializada. Esta classe deve ser anotada com @SpringBootApplication.

@SpringBootApplication
@EnableConfigurationProperties({ LiquibaseProperties.class, ApplicationProperties.class })
public class MinhaAplicacaoMonoliticaApp {
  ...
}

Como uma classe principal, podemos notar que ela também conta com um método estático main que cria uma instância de SpringApplication passando a própria classe como parâmetro, executa a instância criada e imprime no console aquela mensagem que vimos ao inicializar a nossa aplicação informando, entre outros, host e porta.

public static void main(String[] args) {
    SpringApplication app = new SpringApplication(MinhaAplicacaoMonoliticaApp.class);
    DefaultProfileUtil.addDefaultProfile(app);
    Environment env = app.run(args).getEnvironment();
    logApplicationStartup(env);
}

br.com.meucodigoagil.minhapp.config.*

Dentro do pacote br.com.meucodigoagil.minhapp.config, você poderá conferir um grande número de classes destinadas a configurar a nossa aplicação.

A classe CacheConfiguration habilita cache na nossa aplicação e configura o Ehcache conforme selecionamos durante os prompts do JHipster CLI.

@Configuration
@EnableCaching
public class CacheConfiguration {

    private GitProperties gitProperties;
    private BuildProperties buildProperties;
    private final javax.cache.configuration.Configuration<Object, Object> jcacheConfiguration;

    public CacheConfiguration(JHipsterProperties jHipsterProperties) {
        JHipsterProperties.Cache.Ehcache ehcache = jHipsterProperties.getCache().getEhcache();

        jcacheConfiguration = Eh107Configuration.fromEhcacheCacheConfiguration(
            CacheConfigurationBuilder.newCacheConfigurationBuilder(
                Object.class,
                Object.class,
                ResourcePoolsBuilder.heap(ehcache.getMaxEntries())
            )
                .withExpiry(ExpiryPolicyBuilder.timeToLiveExpiration(Duration.ofSeconds(ehcache.getTimeToLiveSeconds())))
                .build()
        );
    }

A classe DatabaseConfiguration possui um bean que configura servidor do banco de dados H2 (usado em tempo de desenvolvimento) para escutar em uma porta TCP.

Perceba no código a seguir que a anotação @Profile restringe a aplicação desta configuração apenas quando a aplicação está sendo executada sob o perfil de desenvolvimento.

@Bean(initMethod = "start", destroyMethod = "stop")
@Profile(JHipsterConstants.SPRING_PROFILE_DEVELOPMENT)
public Object h2TCPServer() throws SQLException {
    String port = getValidPortForH2();
    log.debug("H2 database is available on port {}", port);
    return H2ConfigurationHelper.createServer(port);
}

A classe SecurityConfiguration faz uma série de configurações relacionadas à segurança da aplicação, como a liberação ou a restrição de certos endpoints. Enquanto a SecurityJwtConfiguration cria beans relacionados à autenticação por JWT, incluindo codificador e decodificador do token.

@Configuration
public class SecurityJwtConfiguration {

    private final Logger log = LoggerFactory.getLogger(SecurityJwtConfiguration.class);

    @Value("${jhipster.security.authentication.jwt.base64-secret}")
    private String jwtKey;

    @Bean
    public JwtDecoder jwtDecoder(SecurityMetersService metersService) {
        NimbusJwtDecoder jwtDecoder = NimbusJwtDecoder.withSecretKey(getSecretKey()).macAlgorithm(JWT_ALGORITHM).build();
        return token -> {
            try {
                return jwtDecoder.decode(token);
            } catch (Exception e) {
                if (e.getMessage().contains("Invalid signature")) {
                    metersService.trackTokenInvalidSignature();
                } else if (e.getMessage().contains("Jwt expired at")) {
                    metersService.trackTokenExpired();
                } else if (
                    e.getMessage().contains("Invalid JWT serialization") ||
                    e.getMessage().contains("Malformed token") ||
                    e.getMessage().contains("Invalid unsecured/JWS/JWE")
                ) {
                    metersService.trackTokenMalformed();
                } else {
                    log.error("Unknown JWT error {}", e.getMessage());
                }
                throw e;
            }
        };
    }

    @Bean
    public JwtEncoder jwtEncoder() {
        return new NimbusJwtEncoder(new ImmutableSecret<>(getSecretKey()));
    }
    ...

br.com.meucodigoagil.minhapp.domain.*

No pacote br.com.meucodigoagil.minhapp.domain encontraremos nossas classes de domínio, ou seja, as entidades da nossa aplicação anotadas com @Entity . Além das entidades que fazem parte do domínio da nossa aplicação, como a nossa Produto, encontraremos entidades relacionadas a funcionalidades de segurança criadas automaticamente pelo JHipster, como User e Authority.

Ao analisarmos a classe Produto, podemos notar que o atributo nome possui a anotação com as regras de tamanho que solicitamos ao JHipster CLI.

@Entity
@Table(name = "produto")
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
@SuppressWarnings("common-java:DuplicatedBlocks")
public class Produto implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "sequenceGenerator")
    @SequenceGenerator(name = "sequenceGenerator")
    @Column(name = "id")
    private Long id;

    @NotNull
    @Size(min = 3, max = 100)
    @Column(name = "nome", length = 100, nullable = false, unique = true)
    private String nome;

    ...
}

br.com.meucodigoagil.minhapp.repository.*

Neste pacote temos as classes que farão o papel de repositório de dados, ou seja, que terão a responsabilidade de buscar os dados no banco de dados e que são anotadas com @Repository. Temos repositório para cada uma das classes de domínio. Perceba que se trata apenas de uma interface que, além de anotada, estende a interface JpaRepository do Spring, que proverá por baixo dos panos um conjunto de métodos básicos de acesso e manutenção de dados.

@Repository
public interface ProdutoRepository extends JpaRepository<Produto, Long> {}

br.com.meucodigoagil.minhapp.service.*

Neste pacote ficam as classes @Service que, no Spring, são responsáveis pela implementação de regras de negócio, bem como as classes DTO. Ao visualizar as classes deste pacote na nossa aplicação, você notará que se trata apenas do UserService, relacionada à entidade User padrão do JHipster e MailService, além de algumas classes Exception. Isso se deve ao fato de que durante o prompt do JHipster CLI nós escolhemos que as nossas classes @RestController chamariam as @Repository de forma direta. Lembra?

br.com.meucodigoagil.minhapp.web.*

Neste pacote, teremos a implementação de classes do tipo Filter e Controllers do nosso MVC. Falando em controllers, eles estão mais especificamente no pacote br.com.meucodigoagil.minhapp.web.rest.

Encontramos o controller que expõe endpoints da nossa entidade Produto e também outros controllers com endpoints voltados para mecanismos de autenticação e autorização da aplicação.

Conforme citado anteriormente, podemos ver no código que a ProdutoResource tem injetada uma instância de ProdutoRepository em seu construtor e que este será invocado, por exemplo, no método getAllProdutos().

@RestController
@RequestMapping("/api/produtos")
@Transactional
public class ProdutoResource {

    private final Logger log = LoggerFactory.getLogger(ProdutoResource.class);

    private static final String ENTITY_NAME = "produto";

    @Value("${jhipster.clientApp.name}")
    private String applicationName;

    private final ProdutoRepository produtoRepository;

    public ProdutoResource(ProdutoRepository produtoRepository) {
        this.produtoRepository = produtoRepository;
    }

    /**
     * {@code GET  /produtos} : get all the produtos.
     *
     * @return the {@link ResponseEntity} with status {@code 200 (OK)}
     * and the list of produtos in body.
     */
    @GetMapping("")
    public List<Produto> getAllProdutos() {
        log.debug("REST request to get all Produtos");
        return produtoRepository.findAll();
    }
}

Resources

Além dos arquivos Java, também fazem parte do backend os arquivos de configuração, que ficam sob o diretório src/main/resources. Passemos pelos principais pontos.

config/application*.yml

Na raiz do diretório src/main/resources/config, temos um conjunto de arquivos YML para configuração da nossa aplicação. O arquivo application.yml, detêm as configurações aplicáveis a qualquer que seja o profile sob o qual a aplicação está em execução, seja desenvolvimento ou produção.

Já os arquivos com algum sufixo, são aplicados de acordo com o profile sob o qual a aplicação está em execução. Assim, o arquivo application-dev.yml armazenará valores de configuração especificamente para quando a aplicação está executando sob o perfil dev. Note que sob a chave spring.datasource encontramos uma configuração do banco de dados H2:

spring:
  ...
  datasource:
    type: com.zaxxer.hikari.HikariDataSource
    url: jdbc:h2:file:./target/h2db/db/minhaAplicacaoMonolitica;DB_CLOSE_DELAY=-1
    username: minhaAplicacaoMonolitica
    password:
    hikari:
      poolName: Hikari
      auto-commit: false
  h2:
    console:
      # disable spring boot built-in h2-console since we start it manually with correct configuration
      enabled: false

Por outro lado, o application-prod.yml será utilizado quando a aplicação estiver sob o profile prod. Se verificarmos a mesma chave spring.datasource, encontraremos a configuração para uma base PostgreSQL conforme nós escolhemos em um dos prompts do JHipster CLI:

spring:
  ...
  datasource:
    type: com.zaxxer.hikari.HikariDataSource
    url: jdbc:postgresql://localhost:5432/minhaAplicacaoMonolitica
    username: minhaAplicacaoMonolitica
    password:
    hikari:
      poolName: Hikari
      auto-commit: false

config/liquibase/

Sob o diretório src/resources/config/liquibase, temos os changelogs do Liquibase, a ferramenta utilizada pelas aplicações geradas pelo JHipster para o gerenciamento de mudanças no esquema do banco de dados.

No subdiretório changelog, temos os arquivos com os conjunto de instruções para criação e modificação do esquema de banco de dados conforme podemos ver a seguir a criação da tabela Produto:

<changeSet id="20240324155937-1" author="jhipster">
    <createTable tableName="produto">
        <column name="id" type="bigint">
            <constraints primaryKey="true" nullable="false"/>
        </column>
        <column name="nome" type="varchar(100)">
            <constraints nullable="false" unique="true" uniqueConstraintName="ux_produto__nome" />
        </column>
        <column name="tipo" type="varchar(255)">
            <constraints nullable="false" />
        </column>
        <!-- jhipster-needle-liquibase-add-column - JHipster will add columns here -->
    </createTable>
</changeSet>

Já na raiz, temos no arquivo master.xml, além de declarar algumas propriedades que podem ser utilizadas dentro dos changelogs, também faz referência aos próprios changelogs que serão executados:

<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-latest.xsd">
    <property name="now" value="now()" dbms="h2"/>
    ...

    <include file="config/liquibase/changelog/00000000000000_initial_schema.xml" relativeToChangelogFile="false"/>
    <include file="config/liquibase/changelog/20240324155937_added_entity_Produto.xml" relativeToChangelogFile="false"/>
</databaseChangeLog>

config/i18n/

Sob este diretório encontramos arquivos de propriedades com mensagens nos idiomas que selecionamos para a aplicação. A seguir, mostramos parcialmente os arquivos com mensagens em português e em inglês:

 # Reset email
email.reset.title=A Senha da aplicação minhaAplicacaoMonolitica foi redifinida
email.reset.greeting=Caro {0}
email.reset.text1=Foi solicitado a redefinição de senha da sua conta minhaAplicacaoMonolitica. Por favor clique na url abaixo para alterá-la:
email.reset.text2=Atenciosamente,

 # Reset email
# Reset email
email.reset.title=minhaAplicacaoMonolitica password reset
email.reset.greeting=Dear {0}
email.reset.text1=For your minhaAplicacaoMonolitica account a password reset was requested, please click on the URL below to reset it:
email.reset.text2=Regards,

Os textos contidos nas chaves desses arquivos serão lidos com auxílio do Spring Boot para retornar textos de acordo com o idioma do usuário final. A seguir um exemplo de como isso poderia ser realizado considerando que os arquivos de mensagens tivessem uma mensagem sob a chave error.message:

public class ApenasExemplo{

  private final MessageSource messageSource;

  public ApenasExemplo(MessageSource messageSource){
    this.messageSource = messageSource;
  }

  public void facaAlgo(User user){
    Locale locale = Locale.forLanguageTag(user.getLangKey());
    throw new RuntimeException(
      messageSource.getMessage("error.message", null, locale)
    );
  }
}

Conclusão

Finalizamos aqui a análise do código backend gerado pelo JHipster. Passamos pelas principais classes Java da aplicação, classes do domínio, classes de configuração, classes de acesso a dados, controllers, e também pelos arquivos de configuração do nosso backend.

Na próxima publicação, vamos nos aprofundar no código-fonte do nosso frontend Angular. Até lá, explore mais o código do nosso backend e mande suas dúvidas nos comentários ;)

JHipster 8 - Analisando o código da nossa primeira aplicação monolítica - Parte 1/3

Meu Código Ágil — Sun, 28 Apr 2024 23:26:06 +0000

No último post, nós passamos por um tutorial que nos levou a criar a nossa primeira aplicação, uma aplicação monolítica muito simples com apenas uma entidade cujo propósito era apenas apresentar a vocês o JHipster.

Percorremos passo a passo a construção desta aplicação e, por fim, mostrei para vocês como executá-la e também os prints das telas. Se você não está entendendo nada desses dois primeiros parágrafos, certamente você não conferiu ainda o post onde mostro passo a passo como utilizar o JHipster para gerar uma aplicação com mínimo esforço. Confere lá e depois volte aqui que eu prometo que tudo vai fazer mais sentido: JHipster 8 — Criando uma aplicação monolítica.

Pois bem … naquele post nós criamos a aplicação utilizando JHipster CLI, colocamos ela pra rodar, visualizamos as telas, interagimos, mas … ficou faltando algo bem importante para nós DEVs: abrir o capô dessa aplicação e verificar o que afinal o JHipster produziu. Sim, faltou olhar o código fonte que foi produzido pra nós. É isso que vamos fazer aqui!

Números

Vamos começar por uma análise quantitativa do código fonte gerado e vamos considerar dois momentos distintos: o primeiro quando geramos a base da nossa aplicação, sem entidades. E o segundo quando criamos a entidade Produto na aplicação.

Aplicação monolítica base

Na criação da aplicação base (sem entidades), foram gerados 532 arquivos distribuídos em 158 diretórios e subdiretórios.

Dividindo-se por extensão dos arquivos, as maiores quantidades de arquivos gerados foram:

.ts: 217
.java: 109
.html: 50
.json: 45

E os diretórios com maior número de arquivos gerados, somando-se os arquivos em seus subdiretórios, são:

<diretório da aplicação>/src/main/webapp: 308
<diretório da aplicação>/src/main/java: 70
<diretório da aplicação>/src/test/java: 39
<diretório da aplicação>/: 27

Aplicação monolítica final

Agora o quantitativo refere-se à versão final da aplicação monolítica que criamos, ou seja, após a inclusão da entidade Produto. Agora, a aplicação totaliza 571 arquivos distribuídos em 169 diretórios e subdiretórios.

A divisão por extensão dos arquivos foi ajustada para:

.ts: 236
.java: 118
.html: 54
.json: 50

E os diretórios com maior número de arquivos gerados, somando-se os arquivos em seus subdiretórios, são:

<diretório da aplicação>/src/main/webapp: 334
<diretório da aplicação>/src/main/java: 75
<diretório da aplicação>/src/test/java: 43
<diretório da aplicação>/: 27

A primeira conclusão a qual podemos chegar é que o volume de código e configuração gerado é bastante significativo. Fazer tudo isso na mão levaria bem mais tempo do que aquele que gastamos respondendo aos prompts do JHipster :)

Estrutura e Organização

A fim de melhor nos localizarmos quando formos analisar o código, é importante começarmos pela estrutura e organização dos arquivos na estrutura de diretórios da aplicação.

Começando pelo diretório raiz da aplicação, veremos que ele possui uma quantidade grande arquivos. Em sua grande maioria, arquivos de configuração das próprias ferramentas de desenvolvimento. Por exemplo: pom.xml, .gitignore, .prettierrc, jest.config.js, cypress.config.ts, tsconfig.json, .eslintrc.json e por aí vai.

Em relação aos subdiretórios da raiz, entendo que, ao menos nesta nossa primeira análise, vale a pena focarmos apenas no diretório onde estão os fontes da nossa aplicação: o diretório ./src/no qual damos um “zoom in” abaixo.

├─ src
   ├── main
   │   ├── docker
   │   ├── java
   │   ├── resources
   │   │   ├── config
   │   │   ├── i18n
   │   │   └── templates
   │   └── webapp
   │       ├── WEB-INF
   │       ├── app
   │       ├── content
   │       ├── i18n
   │       └── swagger-ui
   └── test
       ├── java
       ├── javascript
       │   └── cypress
       └── resources
           ├── META-INF
           ├── config
           ├── i18n
           └── templates

Podemos ver que o diretório src se divide em main e test:

main: abaixo deste diretório estão os arquivos fontes que se relacionam com a aplicação em si. Podemos perceber que ele se subdivide em:

docker: onde encontramos alguns arquivos YML a serem utilizados pelo Docker Compose para subir diferentes serviços relacionados à aplicação, por exemplo, uma instância do banco PostgreSQL.
java: onde está o código fonte Java da nossa aplicação em uma estrutura que inicia com o nome do pacote Java que demos na criação da aplicação: br/com/meucodigoagil/minhapp.
resources: que contém os arquivos de recursos tais como arquivos YAML de configuração da aplicação, os arquivos de mensagem de internacionalização (um pra cada idioma selecionado durante os prompts), configuração da biblioteca de logging Logback etc.
webapp: aqui está o código fonte do nosso frontend Angular com todos os seus arquivos Typescript, HTML, CSS, imagens, entre outros.

test: abaixo deste diretório está o código que não faz parte da aplicação em si mas que apoiará o processo de garantia e controle da qualidade. Assim como o diretório “main”, ele também está subdivido para melhor organização:

java: aqui se encontram os testes automatizados, unitários e de integração, do nosso backend.
javacript: aqui temos os nossos testes de frontend e2e utilizando o Cypress.
resources: assim como no diretório “main”, aqui temos os arquivos de YAML de configuração da aplicação, os arquivos de mensagem de internacionalização etc … mas que são aplicáveis apenas quando a aplicação está em execução durante os testes automatizados.

Arquivos de Configuração

Vamos começar a análise da nossa aplicação pelos seus principais arquivos de configuração:

pom.xml

Durante os prompts, escolhemos o Maven como a ferramenta de build do backend Java da nossa aplicação. Dentre outras características, uma aplicação Maven é organizada em estrutura padronizada de diretórios e conta com a presença de um ou mais arquivos de configuração pom.xml.

Entre outras coisas, este arquivo vai conter a lista de dependências da aplicação, plugins utilizados e suas configurações etc. Percebemos logo no início do arquivo a identificação da nossa aplicação.

<groupId>br.com.meucodigoagil.minhapp</groupId>
<artifactId>minha-aplicacao-monolitica</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>Minha Aplicacao Monolitica</name>
<description>Description for Minha Aplicacao Monolitica</description>

Na sequência, temos uma lista de propriedades com seus respectivos valores. Essa seção sozinha não alterada nada na aplicação, mas entenda essas propriedades como variáveis que serão utilizadas ao longo do pom.xml para configurar a aplicação como, por exemplo, na definição da versão de plugins, de dependências, de ferramentas de desenvolvimento e do próprio Java.

<properties>
    <maven.version>3.2.5</maven.version>
    <java.version>17</java.version>
    <node.version>v20.11.1</node.version>
    <npm.version>10.5.0</npm.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <maven.build.timestamp.format>yyyyMMddHHmmss</maven.build.timestamp.format>
    <maven.compiler.source>${java.version}</maven.compiler.source>
    <maven.compiler.target>${java.version}</maven.compiler.target>
    <start-class>br.com.meucodigoagil.minhapp.MinhaAplicacaoMonoliticaApp</start-class>
    <argLine>-Djava.security.egd=file:/dev/./urandom -Xmx1G</argLine>

A seguir, temos a seção <dependencyManagement> que serve para gerenciar as dependências transitivas do projeto. Ela não adiciona diretamente as dependências ao projeto, mas define as versões que devem ser usadas por todos os módulos ou subprojetos e, assim, evita repetição de versões de dependências em vários lugares e ajuda a manter a consistência.

Na <dependencyManagement>da nossa aplicação, temos declarada a dependência tech.jhipster:jhipster-dependencies versão 8.2.0. Essa dependência é chave em uma aplicação gerada com o JHipster. É nela que o JHipster estabelece, por exemplo, que o pacote Spring Boot utilizado na aplicação será a versão 3.2.3.

<properties>
    <jhipster-dependencies.version>8.2.0</jhipster-dependencies.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>tech.jhipster</groupId>
            <artifactId>jhipster-dependencies</artifactId>
            <version>${jhipster-dependencies.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Como podemos ver na seção seguinte, <dependencies>, temos mais uma grande quantidade de dependências onde boa parte não tem especificada a versão pois isso já está estabelecido pela jhipster-dependencies.

<dependencies>
    <dependency>
        <groupId>tech.jhipster</groupId>
        <artifactId>jhipster-framework</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    ...

Também temos a seção <build>, onde temos a definição do defaultGoaldo Maven como spring-boot:run, a declaração e configuração de diversos plugins do Maven, tais como, plugin de compilação, testes unitários e de integração, Sonar, Liquibase e muitos outros.

 <build>
    <defaultGoal>spring-boot:run</defaultGoal>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>${maven-surefire-plugin.version}</version>
          <configuration>
              <!-- Force alphabetical order to have a reproducible build -->
              <runOrder>alphabetical</runOrder>
              <excludes>
                  <exclude>**/*IT*</exclude>
                  <exclude>**/*IntTest*</exclude>
              </excludes>
              <systemPropertyVariables>
                  <java.util.logging.config.file>src/test/resources/logback.xml</java.util.logging.config.file>
              </systemPropertyVariables>
          </configuration>
        </plugin>
        ...

package.json

Quem já desenvolveu um simple “Hello World” em Node.js já conhece este arquivo. Ele contém a lista de dependências do frontend da nossa aplicação, tanto em tempo de produção quando de desenvolvimento.

Logo no início do arquivo encontramos a identificação da nossa aplicação.

{
  "name": "minha-aplicacao-monolitica",
  "version": "0.0.1-SNAPSHOT",
  "private": true,
  "description": "Description for Minha Aplicacao Monolitica",
  "license": "UNLICENSED",
  ...

Também encontraremos um conjunto de scripts que facilitam a vida do desenvolvedor. Para disparar os scripts, basta que o desenvolvedor execute o comando npm run <nome do script>.

"scripts": {
    "app:start": "./mvnw",
    "app:up": "docker compose -f src/main/docker/app.yml up --wait",
    "backend:build-cache": "./mvnw dependency:go-offline -ntp",
    "backend:debug": "./mvnw -Dspring-boot.run.jvmArguments=\"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000\"",
    "backend:doc:test": "./mvnw -ntp javadoc:javadoc --batch-mode",
    "backend:info": "./mvnw -ntp enforcer:display-info --batch-mode",
    "backend:nohttp:test": "./mvnw -ntp checkstyle:check --batch-mode",
    "backend:start": "./mvnw -Dskip.installnodenpm -Dskip.npm",
    "backend:unit:test": "./mvnw -ntp -Dskip.installnodenpm -Dskip.npm verify --batch-mode -Dlogging.level.ROOT=OFF -Dlogging.level.tech.jhipster=OFF -Dlogging.level.br.com.meucodigoagil.minhapp=OFF -Dlogging.level.org.springframework=OFF -Dlogging.level.org.springframework.web=OFF -Dlogging.level.org.springframework.security=OFF",
    "build": "npm run webapp:prod --",
    ...
    "webapp:build": "npm run clean-www && npm run webapp:build:dev",
    "webapp:build:dev": "ng build --configuration development",
    "webapp:build:prod": "ng build --configuration production",
    "webapp:dev": "ng serve",
    "webapp:dev-ssl": "ng serve --ssl",
    "webapp:dev-verbose": "ng serve --verbose",
    "prewebapp:instrumenter": "npm run clean-www && npm run clean-coverage",
    "webapp:instrumenter": "ng build --configuration instrumenter",
    "webapp:prod": "npm run clean-www && npm run webapp:build:prod",
    "webapp:test": "npm run test --"
},
...

Por fim, temos as dependências onde podemos notar claramente que nosso frontend se baseia no Angular 17.3.0.

"dependencies": {
    "@angular/common": "17.3.0",
    "@angular/compiler": "17.3.0",
    "@angular/core": "17.3.0",
    "@angular/forms": "17.3.0",
    "@angular/localize": "17.3.0",
    "@angular/platform-browser": "17.3.0",
    "@angular/platform-browser-dynamic": "17.3.0",
    "@angular/router": "17.3.0",
    "@fortawesome/angular-fontawesome": "0.14.1",
    "@fortawesome/fontawesome-svg-core": "6.5.1",
    "@fortawesome/free-solid-svg-icons": "6.5.1",
    "@ng-bootstrap/ng-bootstrap": "16.0.0",
    ...

angular.json

Neste arquivo encontramos configurações do framework Angular, como a especificação do diretório raiz dos arquivos fonte Angular, o diretório onde estão armazenados assets (imagens, arquivos de estilo etc), configurações de build etc.

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "version": 1,
  "newProjectRoot": "projects",
  "projects": {
    "minha-aplicacao-monolitica": {
      "projectType": "application",
      "schematics": {...},
      "root": "",
      "sourceRoot": "src/main/webapp",
      "prefix": "jhi",
      "architect": {
        "build": {
          "builder": "@angular-builders/custom-webpack:browser",
          "options": {...},
            "outputPath": "target/classes/static/",
            "index": "src/main/webapp/index.html",
            "main": "src/main/webapp/main.ts",
            "polyfills": ["zone.js"],
            "tsConfig": "tsconfig.app.json",
            "inlineStyleLanguage": "scss",
            "assets": [
              "src/main/webapp/content",
              "src/main/webapp/favicon.ico",
              "src/main/webapp/manifest.webapp",
              "src/main/webapp/robots.txt"
            ],
            ...

Conclusão

Vamos encerrando aqui a primeira parte da nossa análise do código da aplicação monolítica gerada pelo JHipster. Fizemos uma análise quantitativa dos arquivos gerados, exploramos a estrutura de diretórios e organização dos arquivos da aplicação e, por fim, mergulhamos nos principais arquivos de configuração da aplicação localizados no diretório raiz.

Mas não acabou por aqui! Na próxima postagem, vamos nos aprofundar no código-fonte Java do backend da nossa aplicação. Fique ligado!

Enquanto isso, faça você mesmo um mergulho solo nos elementos que exploramos neste post e mande suas dúvidas nos comentários ;)

JHipster 8 - Criando uma aplicação monolítica

Meu Código Ágil — Thu, 11 Apr 2024 15:33:00 +0000

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.

Agile: sem as ferramentas certas, é só mais uma forma desorganizada de produzir software

Meu Código Ágil — Wed, 27 Mar 2024 12:10:58 +0000

Olá, Dev/Agilista! Começo pedindo que não dê muita bola para o título desse post, ele é mais uma provocação do que uma verdade em sua totalidade :)

Sabemos que as metodologias e práticas ágeis, especialmente quando bem aplicadas, trazem contribuições significativas para os projetos e as organizações como um todo. Principalmente, quando comparamos com as alternativas mais burocráticas, seus predecessores. Quando temos um time maduro, que foi além das técnicas e das cerimônias, e incorporou a mentalidade ágil, essa diferença é absolutamente gritante. Na verdade, podemos dizer que é incomparável.

As metodologias ágeis estão conosco há vários anos, a publicação do famoso Manifesto Ágil, realizada em 2001, já ultrapassou suas duas décadas. Ao longo deste tempo, é quase impossível que durante sua carreira você não tenha atuado em ao menos um projeto onde se tenha adotado (ou tentado adotar) alguma metodologia ágil.

Da mesma forma, baseado na minha própria vivência, acredito que seja também improvável que em ao menos uma dessas experiências as coisas não tenham saído como esperado. Mesmo observando de forma bastante disciplinada todos os ritos e cerimônias, elas não garantem o sucesso de um projeto de desenvolvimento. Como já citamos anteriormente e voltamos a repetir, as metodologias ágeis entregam seu valor máximo não com a mera adoção de técnicas e cerimônias, mas quando a mentalidade do time é convertida para uma cultura ágil.

Contudo, meu ponto é que isso não cobre tudo. Existe uma questão fundamental em projetos de software que não pode ser superada apenas com técnicas, processos ágeis ou mentalidade: a técnica de produzir código de programação, código com qualidade. E já que estamos falando de agilidade, de aproveitar as janelas do mercado, temos que admitir que essa produção de software com qualidade não pode demorar o tempo que Michelangelo levou para pintar a abóboda da Capela Sistina.

Ainda que o time siga de forma disciplinada o beabá do SCRUM ou qualquer adaptação mais elaborada, abrace e se adapte às mudanças, faça entregas contínuas e frequentes, que o Dono do Produto esteja presente, especifique e priorize bem seu backlog, se o time de desenvolvimento não for capaz de codificar rapidamente e, claro, sem bugs que impeçam a publicação do software em ambiente produtivo, haverá uma lacuna importante que frustará as ambições agilistas e, em última instância, da direção e dos clientes da organização.

Talvez por isso as plataformas No-Code e Low-Code tenham ganhado holofotes nos últimos anos. Elas oferecem um ambiente onde o time pode produzir telas com lógica de negócio incorporada de forma rápida, em um ambiente controlado onde, supostamente, não haverá grandes riscos técnicos. Não há dúvidas que essas ferramentas estão entregando valor e contribuindo para os projetos avançarem, mas elas não são balas de prata (nenhuma é, certo?). Ao mesmo tempo que este ambiente controlado mitiga riscos técnicos, pois as peças deste “Lego” já estão definidas, ele também pode limitar ou impedir soluções mais criativas. E não vamos nem entrar em questões como vendor lock-in.

Antes de seguir, vou enfatizar: é indiscutível que essas plataformas No-Code e Low-Code têm contribuído significativamente para o avanço de inúmeros projetos ao redor do mundo e seu sucesso não é em vão, têm entregado valor, o software tem chegado em produção e os objetivos de negócio têm sido alcançados.

Entretanto, em muitos projetos essa estratégia não será a mais adequada. Nós precisaremos do bom e velho “High Code”, e precisaremos produzir rápido para aproveitar as janelas de oportunidade. Sabidamente, não bastará simplesmente produzir volumes monstruosos de código em espaço de tempo reduzido, é essencial que esse código produzido tenha qualidade. Do contrário, isso levará a débitos técnicos, retrabalho, impacto no tempo de entrega, perda de oportunidades de mercado, prejuízos …

A proposta deste post é introduzir uma série de outros posts onde iremos explorar uma ferramenta já experimentada no mercado que se propõe a automatizar a produção de software com qualidade, software com conceitos modernos, seguindo as melhores práticas de mercado, construído sobre os melhores e mais difundidos frameworks, bibliotecas e ferramentas de mercado: o JHipster.

Temos a ousada pretensão de ajudar tornar realidade os sonhos e promessas dos agilistas :)

Aqui está a lista de links para a série de posts desta jornada que pretendemos incrementar ao longo do tempo:

Introdução ao JHipster

JHipster 8 - Criando uma aplicação monolítica

JHipster 8 - Analisando o código da nossa primeira aplicação monolítica - Parte 1/3

JHipster 8 - Analisando o código da nossa primeira aplicação monolítica - Parte 2/3

Introdução ao JHipster

Meu Código Ágil — Thu, 14 Mar 2024 19:03:11 +0000

Olá, dev! Se você está começando sua jornada no mundo do desenvolvimento de software ou se, mesmo com anos de experiência na produção de software, procura uma ferramenta que possa impulsionar sua produtividade e expandir seu conhecimento em tecnologias mais modernas, você precisa conhecer o JHipster.

O que é JHipster?

O JHipster é um gerador de código de alto nível que combina uma lista extensa de ferramentas e plataformas de desenvolvimento de ponta. Ele é construído sobre uma outra ferramenta de geração decódigo, o Yeoman. As aplicações geradas pelo JHipster têm seu backend baseado no framework Spring e, para seu frontend, o desenvolvedor pode escolher entre os frameworks Angular ou Vue ou a biblioteca React. Com o JHipster, você pode criar um projeto web Java completo, com uma interface amigável e reponsiva, API REST documentada, cobertura de testes abrangente, segurança básica e integração com banco de dados relacionais ou NoSQL e sistemas de messageria como Kafka ou Pulsar.

Por que usar JHipster?

Aqui estão algumas razões pelas quais o JHipster pode ser a ferramenta ideal para você:

Produtividade: com apenas alguns comandos, você pode gerar uma aplicação web ou microserviço totalmente operacional. As aplicações geradas estão configuradas com as ferramentas de desenvolvimento mais apropriadas no ciclo de vida do desenvolvimento, tais como Maven, Gradle, npm, Liquibase etc.

Tecnologias modernas: utilização de tecnologias modernas que são demandadas no mercado atual. Aplicações conteinerizadas, com recursos de cache, pooling de conexões para otimização de desempenho, gerenciamento de log, monitoramento da aplicação em tempo de execução e suporte aos principais provedores de nuvem.

Robustez e desempenho: aplicações robustas, de alto desempenho e escaláveis, capazes de suportar grande número de usuários concorrentes .No frontend, fragmentos das páginas são atualizados de forma dinâmica fazendo com que os usuários da aplicação não precisem esperar pela carga completa de páginas. O backend gerado se baseia nas tecnologias mais recentes de cache e acesso a dados, tendo segurança e desempenho como foco.

Personalização: escolha entre uma variedade de opções para personalizar sua aplicação durante a geração do projeto. O desenvolvedor pode escolher, por exemplo, entre uma aplicação monolítica ou um conjunto de microserviços; qual a biblioteca de cache a ser utilizada pela aplicação e até mesmo se a aplicação suportará internacionalização e quais idiomas.

Boas Práticas: o código gerado segue as melhores práticas da indústria, adota padrões como IoC¹, AOP² e abstrações para facilitar a codificação, além de ser bem comentado.

Comunidade: Uma comunidade ativa e uma ampla documentação estão disponíveis para ajudá-lo a resolver problemas e expandir suas habilidades.

Setup da estação de desenvolvimento

Antes de começar a utilizar o JHipster para desenvolver sua próxima aplicação, você precisará fazer o setup do ambiente de desenvolvimento instalando pré-requisitos para o funcionamento do JHipster:

Java³
Node.js⁴
Git

Instaladas estas ferramentas de desenvolvimento, você deverá instalar o JHipster de forma global, o que pode ser feito via linha de comando utilizando o gerenciador de pacotes NPM:

npm install -g generator-jhipster

Primeiros Passos com JHipster

Uma vez que as dependências e o próprio JHipster estão devidamente instalados, criar um novo projeto é um processo guiado por um assistente de linha de comando que levará o desenvolvedor através de várias opções para configurar sua aplicação conforme ilustrado na imagem a seguir.

Dentre várias opções, o desenvolvedor poderá escolher entre criar uma aplicação monolítica ou um conjunto de microserviços, dependendo das necessidades do seu projeto.

Um tutorial detalhado para a geração de uma aplicação utilizando o JHipster 8 será publicado em um próximo post neste mesmo canal.

Conclusão

O JHipster é uma excelente escolha para o desenvolvedor que queira se familiarizar com as tecnologias usadas em aplicações corporativas modernas. Ele não só ajuda a acelerar o processo de desenvolvimento, mas também serve como uma ferramenta de aprendizado valiosa.

Experimente o JHipster hoje mesmo e dê um grande passo na sua carreira de desenvolvedor! Siga-me e seja notificado sempre que tiver conteúdo novo por aqui 😉

Inversion of Control: princípio de desenvolvimento de software onde o fluxo de controle é invertido. Em vez de um programa ditar o que as classes ou objetos devem fazer, o framework ou container é quem decide. Isso ajuda a criar sistemas mais modulares, extensíveis e fáceis de manter.
Aspect-Oriented Programming: técnica de programação que visa melhorar a modularidade do código separando preocupações transversais.
Para utilizar o JHipster 8, última versão do JHipster na data da publicação deste post, você precisará instalar o Java v17 ou mais recente, um pré-requisito do Spring Boot 3.2.
Para utilizar o JHipster 8, você precisará instalar o Node.js v18 ou mais recente