Detailed motivation and design rationale for PR #124.
Hey maintainers, I’ve been using the values builder and noticed that the current architecture makes it really hard to cover more than the most basic use cases. I’ve documented the main problems below and have a working replacement.
Summary
The current implementation builds the values.yaml output by hard-coding string interpolation directly inside a single React component (app/page.js). This approach severely limits the range of supported Helm chart values, provides no input validation, and creates a brittle architecture that cannot keep pace with the official Camunda Helm chart. It makes the tool unsuitable for anything beyond the simplest demo deployments and blocks community contributions.
Problem Description
1. Extremely limited configuration coverage
The generator only surfaces a tiny fraction of the Helm chart’s options – primarily component enablement flags, ingress hosts, and a few URLs. Entire categories of essential configuration are entirely missing, including:
- Advanced Zeebe / Orchestration Cluster tuning
- External Elasticsearch / OpenSearch connections (with authentication and TLS)
- Authentication providers and identity integrations (e.g., OIDC, Keycloak)
- Proper secret management (inline secrets, existing secret references)
- Environment variables for any component
- External databases for Identity and Web Modeler
- Document stores (AWS, GCP, in-memory)
- Cloud-specific features (AWS IRSA, OpenShift security context adaptation)
Moreover, there is no connection between the UI fields and the official Camunda Helm chart schema. The generated paths are typed out manually, making them prone to drift and incompatibility with chart updates.
2. Fragile and error-prone YAML generation
YAML is assembled by concatenating raw strings inside JSX conditional blocks. This approach:
- Requires manual indentation management, which is notoriously fragile
- Cannot cleanly represent deeply nested structures
- Mixes UI logic with output formatting
- Produces invalid YAML when inputs are missing or incomplete
- Contains known typos (e.g., partitionCound instead of partitionCount)
No YAML serialization library (like js-yaml) or structured data model is used.
3. No validation or user feedback
The tool performs no validation of user inputs whatsoever:
- Required fields are not enforced – users can generate broken output without warning
- There is no error messaging when configuration is inconsistent
- The output is never checked against the expected Helm chart structure
Users are left with an unreliable and error-prone experience.
4. Poor separation of concerns and maintainability
All logic – UI rendering, state management, YAML string building – is tightly coupled inside a single monolithic component. This means:
- Adding a single new field requires editing a large, complex template
- There is no abstraction layer for mapping inputs to Helm value paths
- Keeping the tool in sync with upstream chart releases is entirely manual and high-effort
- The risk of regressions when extending functionality is very high
5. Scalability bottleneck
The current design cannot scale to cover the full breadth of the Camunda Platform Helm chart. Because every new configuration option must be manually coded into the template, covering even a fraction of the >1000 available values is impractical. This fundamentally limits the tool’s usefulness for production deployments.
Impact
- High probability of generating invalid or outdated configurations
- Cannot be relied upon for anything beyond local demos
- Discourages community contributions due to the fragile codebase
- Increases maintenance burden for maintainers needing to support chart updates
- Fails to meet the needs of users deploying Camunda 8 in real clusters
Suggested Improvements
Short-term (tactical fixes)
- Add input validation for required fields before displaying output
- Fix obvious typos (e.g., partitionCound → partitionCount)
- Display user-facing error messages when configuration is incomplete
Medium-term (architectural refactor)
- Replace string templating with a structured JavaScript object that represents the final Helm values
- Use a YAML serialization library (js-yaml) to generate the output
- Extract the YAML generation into a dedicated transformation module, separate from the UI
Long-term (schema-driven, future-proof design)
- Parse the official Helm chart’s values.yaml to build a schema of all available fields, their types, and documentation
- Drive the UI form dynamically from this schema and a declarative configuration file
- Strictly separate concerns: UI rendering, configuration model, Helm-path transformation
- Support loading and editing existing values.yaml files
- Include build-time validation to catch out-of-sync paths before deployment
Additional Notes
A TODO file already present in the repository acknowledges the need for validation, better tooltips, improved styling, and editing of existing values.yaml files. Addressing the issues outlined here would directly fulfil those goals and transform the project into a production-grade configuration tool for the Camunda Helm chart.
A complete, drop‑in replacement implementation that follows the long‑term design principles described above is already available in
PR #124. This issue serves as the detailed problem statement and design rationale for that pull request.
Detailed motivation and design rationale for PR #124.
Hey maintainers, I’ve been using the values builder and noticed that the current architecture makes it really hard to cover more than the most basic use cases. I’ve documented the main problems below and have a working replacement.
Summary
The current implementation builds the values.yaml output by hard-coding string interpolation directly inside a single React component (app/page.js). This approach severely limits the range of supported Helm chart values, provides no input validation, and creates a brittle architecture that cannot keep pace with the official Camunda Helm chart. It makes the tool unsuitable for anything beyond the simplest demo deployments and blocks community contributions.
Problem Description
1. Extremely limited configuration coverage
The generator only surfaces a tiny fraction of the Helm chart’s options – primarily component enablement flags, ingress hosts, and a few URLs. Entire categories of essential configuration are entirely missing, including:
Moreover, there is no connection between the UI fields and the official Camunda Helm chart schema. The generated paths are typed out manually, making them prone to drift and incompatibility with chart updates.
2. Fragile and error-prone YAML generation
YAML is assembled by concatenating raw strings inside JSX conditional blocks. This approach:
No YAML serialization library (like js-yaml) or structured data model is used.
3. No validation or user feedback
The tool performs no validation of user inputs whatsoever:
Users are left with an unreliable and error-prone experience.
4. Poor separation of concerns and maintainability
All logic – UI rendering, state management, YAML string building – is tightly coupled inside a single monolithic component. This means:
5. Scalability bottleneck
The current design cannot scale to cover the full breadth of the Camunda Platform Helm chart. Because every new configuration option must be manually coded into the template, covering even a fraction of the >1000 available values is impractical. This fundamentally limits the tool’s usefulness for production deployments.
Impact
Suggested Improvements
Short-term (tactical fixes)
Medium-term (architectural refactor)
Long-term (schema-driven, future-proof design)
Additional Notes
A TODO file already present in the repository acknowledges the need for validation, better tooltips, improved styling, and editing of existing values.yaml files. Addressing the issues outlined here would directly fulfil those goals and transform the project into a production-grade configuration tool for the Camunda Helm chart.
A complete, drop‑in replacement implementation that follows the long‑term design principles described above is already available in
PR #124. This issue serves as the detailed problem statement and design rationale for that pull request.