Configuration: apps and multi-app

Many "I clearly set it right, so why is it still hitting the wrong database" problems boil down to the App Code — or the current app — not pointing where you think it does. This page lays out the app selection rules so you can self-check.

Three concepts

App Code: every app on the platform has a unique identifier. Almost every CLI command that reads or writes data targets the "current App" by default.

Config files: the project root's .rabetbase.json prefers organizing apps with apps + defaultApp; the legacy top-level appcode is still read for compatibility. There can also be a global config under your user directory.

Current app: which App a command finally lands on is determined jointly by command-line arguments, the current working directory's config, and the global config.

Precedence: who wins

A simplified rule: what's on the command line > the currently selected app's config > top-level defaults in the file.

Common tools:

• Pin an App Code for one command: rabetbase ... --appcode <code>
• Temporarily switch apps in a multi-app setup: rabetbase ... --app <app name from config>
• Fix the default app for the current directory: rabetbase workspace use --app <name>

This lets you hard-code parameters in scripts, or maintain a single default in the local config file.

Single-app mode (most common)

The simplest legacy form is the top-level appcode:

{
  "appcode": "app-xxxx"
}

New writes, however, default to the canonical apps + defaultApp form. After that, commands without --appcode use the currently selected default app.

Multi-app mode (several Lovrabet apps in one repo)

When a project maintains both an "order app" and a "product app", use apps + defaultApp:

{
  "defaultApp": "order",
  "apps": {
    "order": {
      "appcode": "app-order-xxx",
      "apiDir": "./apps/order/src/api"
    },
    "product": {
      "appcode": "app-product-yyy"
    }
  },
  "cookie": "<可共享的登录态>",
  "format": "pretty"
}

The outer fields are shared defaults; each apps.<name> can override its own appcode, apiDir, cookie, and more.

Switch the default app (written back to the config file):

rabetbase workspace use --app product

See which apps exist and which is the default:

rabetbase app list

Discover apps your account can access on the platform:

rabetbase app list --remote

Plain rabetbase app only shows help for the app service; run rabetbase app list explicitly to view local apps.

Add an app:

rabetbase app add <name> --appcode <必填的AppCode>

You can also add --apiDir, --cookie, and more.

Remove an app:

rabetbase app remove <name>

Changing config via commands (no JSON editing)

Run inside a project directory, these change the project config; outside a project, write commands are rejected with a prompt to add --global or initialize a project first:

rabetbase config set appcode app-xxxx
rabetbase config get appcode
rabetbase config list

Notes:

• config set appcode app-xxxx in a single-app scenario is automatically written as apps + defaultApp
• If the project is already in multi-app config, use rabetbase app add / rabetbase workspace use --app <name> instead

Good for quick one-or-two-item changes; for complex structures, edit the file directly or trust version control.

Risk level (riskLevel)

You can set riskLevel in config: read | write | high-risk-write. It caps how dangerous the commands you can run are. For example, with read-only allowed, write commands are rejected.

Recap

• First confirm the App Code matches the task at hand.
• In multi-app setups, build the habit: rabetbase app list to see the default, or use --app / --appcode to be explicit.
• To see what apps exist on the platform, discover them with rabetbase app list --remote; the old entry rabetbase app remote is gone.
• To switch the default app for the current directory, use rabetbase workspace use --app <name>; the old entry rabetbase app use <name> is gone.