search

claceio / clace

AppServer for containerized web app development and deployment
https://clace.io
Apache License 2.0
284 stars 6 forks source link

[feat] Declarative interface for Clace configuration #34

Open akclace opened 5 days ago

akclace commented 5 days ago

Currently, Clace apps are created using a CLI interface. An UI interface to manage Clace apps will be added later. For complex installations, a declarative interface is required. The intent is to avoid ClickOps/ShellOps.

The declarative interface should be readable, expressive, idempotent and git compatible (diffable text format). Modularity, reusability, support for variables and parameters are other criteria to consider. Interoperability with CLI and UI is another consideration.

akclace commented 5 days ago

The various config formats already in use in Clace are

  1. TOML files (for server config)
  2. JSON files (for lock file)
  3. Starlark config (for app definition)
  4. Go Template (for HTML templating)

The other options are YAML and a domain specific language (like HCL).

Clace has a CLI interface which can be considered a DSL. Using the CLI command as declarative interface will mean something like

  1. A way to export the current state, which generates a text file will the app create commands for all the apps. All options needs to be present in the output. The output should be sorted by app name and options also need to be sorted (for diffability)
  2. A way to import a state file. The create commands will figure out the diff which needs to be applied and do just that. If there no change required, the import is a no-op.
akclace commented 5 days ago

Further considerations for the CLI DSL option

  1. The text file could be a go template which resolves to the CLI DSL. That enables some modularization and parameter support. The downside is that a exported state file cannot be easily diffed with the template file
  2. Comment support would be good to have, but that also has the issue that a exported state file will not be diffable with commented state file. A complex option would be to figured out the comments and somehow retain them in the export output.
  3. The export should have the exact git version of the version each app is at. Import should maybe have a option to restore to exact version or stay on the latest version on the branch.
  4. The implication of combining CLI/UI based updates with export/import have to be considered.