이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 9. User interface changes
Apicurio Registry 3.x introduces a significant architectural change to the user interface. You deploy the UI as a separate container, providing more deployment flexibility but requiring additional configuration considerations during migration.
Separate UI container
In Apicurio Registry 2.6, the UI is built into the main apicurio-registry container as a single monolithic application. Apicurio Registry 3.x separates the UI into its own container:
Registry 2.x architecture:
Registry 3.x architecture:
Implications for migration:
- Two containers to deploy and manage instead of one
- Additional networking configuration required
- More flexible deployment options
- Independent scaling of UI and API components
Choosing deployment options
You have flexibility in how you deploy the UI container in relation to the API container. Choose one of the following options.
Option 1: Separate subdomains
Deploy UI and API to separate subdomains:
Benefits: * Clean separation of concerns * Independent DNS configuration * Easier to scale components independently
Option 2: Co-located with reverse proxy
Use a reverse proxy (nginx, HAProxy) to serve both UI and API from the same domain:
Benefits: * Single domain for users * Simpler certificate management * Avoids CORS complexity
Application container configuration (primary)
Configure most UI settings through the application (API) container, not the UI container. The application serves UI configuration to the frontend.
Available UI properties (configured on application container):
| Property | Description | Default |
|---|---|---|
|
| Context path of the UI |
|
|
| Navigation prefix for all UI paths |
|
|
| URL of the documentation component |
|
|
| URL of the editors component (Designer) |
|
|
| OAuth2/OIDC redirect URI |
|
|
| OAuth2/OIDC client ID for UI |
|
|
| OAuth2/OIDC logout URL |
|
|
| OAuth2/OIDC scope |
|
|
| Enable read-only mode for UI |
|
|
| Show breadcrumbs in UI |
|
|
| Show Settings tab in UI |
|
Example application container configuration:
UI container configuration (overrides)
The UI container has its own environment variables that override the application configuration, but you typically do not need these.
Common UI container environment variables:
| Environment Variable | Description |
|---|---|
|
|
Required: URL to the backend API (for example, |
|
| Override for UI context path |
|
| Override for navigation prefix path |
|
| Override for documentation URL |
|
| Override for editors (Designer) URL |
|
| Override for OAuth2/OIDC auth server URL |
|
| Override for OAuth2/OIDC client ID |
|
|
Override for read-only mode ( |
The only required UI container property is REGISTRY_API_URL. Configure all other UI settings on the application container using apicurio.ui.* properties.
Using Designer functionality
Apicurio Registry 3.1.0 introduces integrated Designer functionality, replacing the standalone Apicurio Studio project.
What is Designer?
Designer provides visual editing capabilities for OpenAPI and AsyncAPI specifications directly within the Apicurio Registry UI. This functionality previously existed as a separate project (Apicurio Studio) but is now fully integrated into Apicurio Registry.
Key features:
- Visual editor for OpenAPI 3.x specifications
- Visual editor for AsyncAPI specifications
- Draft artifact version state for work-in-progress designs
- Direct integration with Apicurio Registry storage
- No separate deployment required
Enabling Designer
Designer functionality requires enabling content mutability for artifact versions:
# Enable Designer functionality apicurio.rest.mutability.artifact-version-content.enabled=true
# Enable Designer functionality
apicurio.rest.mutability.artifact-version-content.enabled=true
When enabled, users with the developer or admin role can:
- Create draft versions of artifacts
- Edit draft content using the visual editor
- Save changes iteratively
- Finalize drafts to create immutable versions