Configure an ApiHug App UI Module

What This Page Covers

This page explains the app-side configuration that connects an ApiHug application module to a generated Vue UI module.

Read this page when you already understand the basic Vue UI output and now need to:

• enable frontend generation from the app module
• point the app module at the real UI workspace
• understand how generated assets and SPA routing fit into runtime delivery

When To Use It

Use this setup when your project keeps backend runtime and frontend UI in separate modules, but you still want ApiHug to coordinate generation and packaging between them.

Steps

1. Enable Vue generation in the app module

In {app}/build.gradle, enable the frontend stub output:

hopeStub {
    enableFrontVue = true
}

2. Point the app module to the UI workspace

Create or update {app}/ui.json:

{
  "projectDir": "../good-app-ui"
}

This file tells the app module where the UI project lives relative to the backend module.

3. Understand the generation boundary

In the ApiHug workflow:

1. proto defines the contract
2. the app module consumes generated contract metadata
3. the UI module receives generated service, model, i18n, and page-support artifacts

The app module is therefore the bridge between contract output and frontend generation policy.

4. Run the stub flow

After enabling the app-side configuration, run the stub/build sequence from the app module:

./gradlew.bat {app}:clean stub build -x test -x stubTest

Typical generated output includes:

• i18n language bundles
• API service stubs
• request and response models
• form and table support types
• shared type declarations

Key Files

Router Notes

ApiHug's UI workflow assumes route generation happens in the UI module, not inside the backend runtime.

A typical router.json shape looks like this:

{
  "items": [
    {
      "moduleDir": "apps/web1"
    },
    {
      "moduleDir": "apps/web2"
    }
  ]
}

Use this when one UI repository contains multiple independently generated application entries.

Runtime Notes

At runtime, the backend module usually serves the built UI assets and forwards SPA routes to index.html.

Two parts matter:

1. a build hook that copies dist into the backend static resources directory
2. an SPA path filter that forwards non-API routes to the frontend entry file

Example resource copy hook:

tasks.register('copyUIResources', Copy) {
    dependsOn project(':good-app-ui').tasks.named('build')
    from project(':good-app-ui').layout.projectDirectory.dir('dist')
    into "${layout.buildDirectory.get()}/resources/main/static"
}

tasks.named('processResources') {
    dependsOn 'copyUIResources'
}

Example SPA forwarding rule:

SpaPathChecker DEFAULT =
      path ->
          !path.startsWith("/api")
              && !path.startsWith("/management")
              && !path.startsWith("/v3/api-docs")
              && !path.startsWith("/hope/meta")
              && !path.startsWith("/h2-console")
              && !path.contains(".")
              && path.matches("/(.*)");

This keeps API traffic on backend routes while normal browser navigation continues through the SPA entrypoint.

Result

After this configuration is in place, the app module becomes the stable handoff point between ApiHug contract generation and a real Vue UI workspace, instead of leaving frontend generation as an ad-hoc manual step.

Related Pages

1. UI Handbook
2. Organize a Vue UI Module
3. UI Tool Chain