The application that is generated will not contain any frontend code. Again, the invoice service is a Spring Boot-based application. The security features are configured in SecurityConfiguration.java.

It ignores all the H2 Database-related requests:

    public void configure(WebSecurity web) {
        web.ignoring()
            .antMatchers("/h2-console/**");
    }

Since the services are independent, they can be deployed and run on another server with a different IP address. This requires us to disable Cross-Site Request Forgery (CSRF) by default. 

We will also use the STATELESS session policy in session management. This is the strictest session policy available. This will not allow our application to generate a session, so our requests have to have the (time-bound) tokens attached to each and every request. This enhances the security of our services. Their stateless constraint is another advantage of using REST APIs.

All the API-related requests and Swagger resources should be allowed once the request has been authorized (based on the JWT token):

public void configure(HttpSecurity http) throws Exception {
        // @formatter:off
        http
            .csrf()
            .disable()
            .exceptionHandling()
            .authenticationEntryPoint(problemSupport)
            .accessDeniedHandler(problemSupport)
        .and()
            .headers()
            .contentSecurityPolicy(...)
        .and()
            .referrerPolicy(...)
        .and()
            .featurePolicy(...)
        .and()
            .frameOptions()
            .deny()
        .and()
            .sessionManagement()
            .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
        .and()
            .authorizeRequests()
            .antMatchers("/api/authenticate").permitAll()
            .antMatchers("/api/**").authenticated()
            .antMatchers("/management/health").permitAll()
            .antMatchers("/management/info").permitAll()
            .antMatchers("/management/prometheus").permitAll()
            .antMatchers("/management/**").hasAuthority
              (AuthoritiesConstants.ADMIN)
        .and()
            .apply(securityConfigurerAdapter());
        // @formatter:on
    }

On the resource side, we have a new bootstrap.yml file that overrides the application.yml files. We have also defined the registry-related information and some Spring properties here.

Our current microservice application uses the JHipster registry as the registry service in order to register and deregister their existence with a heartbeat signal. We need to provide the password of our registry service so that the application can connect to the registry service:

jhipster:
    registry:
        password: admin

Also, the name of the Spring Boot service and the default Spring Cloud Config parameters are specified in the bootstrap.yml file. We have also added the URI that we have to connect in order to fetch the configuration of the registry service:

spring:
    application:
        name: invoice
        ...
    cloud:
        config:
            # if not in "prod" profile, do not force to use Spring 
              Cloud Config
            fail-fast: false
            uri: http://admin:${jhipster.registry.password}
              @localhost:8761/config
            # name of the config server's property
              source (file.yml) that we want to use
            name: invoice
            ...

The bootstrap.yml file is used in the development process, while, for production, there is a bootstrap-prod.yml file. Similar to the gateway, the rest of the service-related configurations are done in the application-*.yml files. 

The Eureka configuration is exactly the same as it was in the gateway application. All the generated applications will have a similar Eureka configuration:

eureka:
  client:
    enabled: true
    healthcheck:
      enabled: true
    fetch-registry: true
    register-with-eureka: true
    instance-info-replication-interval-seconds: 10
    registry-fetch-interval-seconds: 10
  instance:
    appname: invoice
    instanceId: invoice:${spring.application.instance-
      id:${random.value}}
    lease-renewal-interval-in-seconds: 5
    lease-expiration-duration-in-seconds: 10
    status-page-url-path: ${management.endpoints.web.base-path}/info
    health-check-url-path: ${management.endpoints.web.base-path}/health
    metadata-map:
      zone: primary # This is needed for the load balancer
      profile: ${spring.profiles.active}
      version: #project.version#
      git-version: ${git.commit.id.describe:}
      git-commit: ${git.commit.id.abbrev:}
      git-branch: ${git.branch:}

The database and JPA configurations are present in the application-[dev|prod].yml files:

spring:
  profiles:
    active: dev
    ...
  datasource:
    type: com.zaxxer.hikari.HikariDataSource
    url: jdbc:h2:file:./build/h2db/db/invoice;DB_CLOSE_DELAY=-1
    username: invoice
    password:
    hikari:
      poolName: Hikari
      auto-commit: false
  ...
  jpa:
    database-platform: io.github.jhipster.domain.util.FixedH2Dialect
    database: H2
    show-sql: true
    properties:
      ...
  liquibase:
    # Remove 'faker' if you do not want the sample data to be loaded 
       automatically
    contexts: dev, faker

The rest of the configurations remain similar to what was generated in the gateway application, and they can be tweaked or customized based on your requirements.

Let's run all the tests to ensure we haven't broken anything from the cherry-picking we have done.

Navigate to the invoice application folder and run ./gradlew test integrationTest; it should pass.

Now, we can boot up the application alongside the gateway application and registry service if required. Since the application tries to connect to the registry service first, if there is no registry service available at the specified location, then the application will not know where to connect and whom to respond to, and hence will fail.

Before we spin up the applications, let's look at the notification service with NoSQL as the backend database.