Dynamic Candid arguments

[nmattia]

Say I have two canisters: A and B. Most likely there will be a dependency between the two, i.e. A may depend on B at runtime. This is the case if e.g. A is an asset canister making calls to B (which could be a motoko canister). In general, canister A has no way of knowing the canister ID of canister B; it does however need to know the canister ID of canister B to make API (IC) calls.

This is currently worked around by looking up canister IDs at build time and injecting them in the webpack config. This is not optimal, see #2014 for more details.

Instead I'd like to suggest passing the canister ID of canister B as an init argument to canister A.

The naive approach would be to always pass the canister IDs as arguments. This may cause problems in existing projects, and this would restrict what arguments canister developers could use when using dfx. Instead, this could be turned on and off in dfx.json:

{
  "canisters": {
    "frontend": {
      "type": "custom",
      "candid": "frontend.did",
      "wasm": "frontend.wasm",
      "build": "build_frontend.sh",
      "canister_id_args": true
    },
    "backend": {
      "type": "custom",
      "candid": "backend",
      "wasm": "backend",
      "build": "build_backend.sh"
    }
  }
}

Here, all canisters setting canister_id_args to true would get the following candid record as init argument:

record { frontend = "fgte5-ciaaa-aaaad-aaatq-cai", backend = "ec6lp-3iaaa-aaaad-aaavq-cai" }

Going yet a little further, we could even go as far as allowing developers to specify init arguments for canisters, as well as supporting basic templating:

{
  "canisters": {
    "frontend": {
      "type": "custom",
      "candid": "frontend.did",
      "wasm": "frontend.wasm",
      "build": "build_frontend.sh",
      "arguments": {
        "is_production": "${{ env.PRODUCTION == '1' }}",
        "canister_ids": "${{ dfx.canister_ids }}",
      }
    },
    "backend": {
      "type": "custom",
      "candid": "backend",
      "wasm": "backend",
      "build": "build_backend.sh",
      "arguments": {
        "serious_business": "${{ dfx.network == 'ic' }}"
      }
    }
  }
}

Here the templating syntax is borrowed from the GitHub Actions Expressions. Strings are used to write expressions, although in certain cases (dfx.canister_ids) they may expand to objects (records). In this example two namespaces are used, dfx and env, where dfx could hold project-related values and env could be used to look up environment variables.

This would resolve the following issues, as well as allowing developers to have more complex setups:

• dfx deploy should be able to take arguments per canister #1692 (kind of)
• Use ports to route to canisters when using dfx start #2012
• Don't incite developers to bake the canister ID in the frontend #2014

[roman-kashitsyn]

I'm not sure it's a good idea to implement this. This adds a lot of complexity. For example,

record { frontend = "fgte5-ciaaa-aaaad-aaatq-cai", backend = "ec6lp-3iaaa-aaaad-aaavq-cai" }

will require dynamically generating a Candid type in DFX, which I'm not sure how to do.
And that is not even the most worrisome part: we add a whole new expression evaluation language to the DFX config file.

Furthermore, I'm not sure why this cannot be implemented with a simple bash script, something like

dfx canister create backend
dfx canister create frontend

BACKEND_ID=$(dfx canister id backend)
FRONTEND_ID=$(dfx canister id frontend)
if [[ $PRODUCTION == "1" ]]; then
  BACKEND_ARGS=...
  FRONTEND_ARGS=...
else
  BACKEND_ARGS=...
  FRONTEND_ARGS=...
fi

dfx deploy backend --argument $BACKEND_ARGS
dfx deploy frontend --argument $FRONTEND_ARGS