My project is a DAO with Canister Upgrade ability (SNS alike).
Currently it works well with backend WASMs, but I dont know how to make this upgradable for Frontend, I saw built Frontend has 2 WASMs, one is frontend.wasm.gz and one is assetstorage.wasm.gz
Or at least, is this not recommended or not neccessary?
public type Commitment = {
args : [Nat8];
wasmCommitment : {
checksum : Text;
chunks : Tree<Nat8, [Nat8]>;
var bytes : [Nat8]
}
};
Well, this looks reasonable to me. Does it work or do you have trouble getting it work? For canisters that a Motoko actor installs we have a simplified workflow, but I guess your two canisters are outside of this scope. So you have to go via the subnet’s management canister as you illustrate above. I suggest to thoroughly test these procedures in the local testnet to avoid disturbances in production.
One suggestion, though. As soon as dfx 0.25.1 is released (now in beta.1), you can add cycles to the install_code call this way:
Thank you, as I provided, it works perfectly with Motoko because there is only one WASM file, but I dont know how to upgrade Frontend Canister (because I saw 2 WASM files after building Frontend Canister, frontend.wasm.gs and assetstorage.wasm.gz), what should I do in this case?
And I also want to listen to advices if this procedure (Frontend canister upgrading programmatically) is not recommended or not necessary for a DAO app.
Maybe you have a look into your dfx configuration (i.e. dfx.json and canister_ids.json) to see how those binaries are associated to which canisters on the IC. Normally frontend canisters are deployed via dfx, but for DAOs you want to put all under the control of a central canister. You probably need a system of proposals where those 2 Wasm files get included and then they must be upgraded via the management canister in turn (serially or maybe in parallel). But you should get the opinion of more DAO-savvy folks first. I am just a Motoko dev.