Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requesting clarification on the following: Dynamic canister creation, automatic Candid generation, inter canister calls #23

Closed
saikatdas0790 opened this issue Sep 3, 2022 · 6 comments

Comments

@saikatdas0790
Copy link
Contributor

It would be really helpful if you could document how to do the following with ic-kit:

  • dynamic canister creation
  • automatic Candid generation
  • inter canister calls

as comments in the examples provided and provide any guidance on how to set it up from scratch on a new project.

I was using ic-kit 0.4.8 before. It included calls to the management canister as documented here for the dynamic creations of canisters but that seems to have been removed in v0.5 onwards.

And I had been using the cargo test mechanism of automatic Candid generation as used in some other Psychedelic projects like this

For inter canister calls, I tried the mechanism outlined here but it's not type safe so it breaks compilation with Cargo. I created a post for it here

I feel ic-kit 0.5 would probably solve all of the above but I'm unable to make it work atm.

I see some of the examples have pending todos and I imagine you'll be fleshing them out in more details.

In case you already plan to cover the above, please ignore this issue :)

@qti3e
Copy link
Contributor

qti3e commented Sep 3, 2022

Hey!

v0.5 is still alpha, we're pushing for it to be stable very soon, hopefully, this week. For the inter-canister calls, you can currently see the example in fib and multi-counter both demoing the use of the new CallBuilder

For automatic candid generation notice this in the fib example:

#[derive(KitCanister)]
#[candid_path("candid.did")]
pub struct FibCanister;

running cargo test now automatically writes the candid to the provided path.

As for importing canisters and dynamic creation, the new version is taking a different approach which is what's currently pending, the factory-counter example should demo this once it is possible.

@qti3e
Copy link
Contributor

qti3e commented Sep 3, 2022

see this #24 for the wip dynamic canister creation.

@saikatdas0790
Copy link
Contributor Author

@qti3e Thank you for the clarification. Eagerly awaiting the release :)

2 quick questions I had while going through the example code:

  • Any particular reason why there's a main.rs files for all the canister packages? Do you build a binary? What does it do?
  • The Dfinity prescribed mechanism of inter-canister calls just needs you to import the canister name and it detects the details (I imagine from the dfx.json and canister_ids.json files). The CallBuilder mechanism requires us to pass the canister_id as a Principal and the method name to be called as a String kinda how the ic_cdk does it as a System API call. I apologize if my Rust understanding is limited but I was wondering if there's a way to import the canister struct definition in a type safe way into another canister and have it expose its methods available in a type safe way. This would be the the most ergonomic and delightful developer experience possible and would make ic-kit a compelling reason for other projects as well as opposed to the ic_cdk. I imagine this is possible theoretically since the type information is available over Candid but not sure how feasible this is practically.

Thank you for the inputs nonetheless :)

@qti3e
Copy link
Contributor

qti3e commented Sep 3, 2022

believe me, we're also eagerly awaiting the release internally xD

  1. the main.rs file is used for building the canister as a wasm, but we're considering allowing a CLI over the canister implementation, and later allowing cargo run to spin up a debugger replica, but i think if you do crate-type = ["cdylib", "lib"] you should be able to both import the library and build it at the same time. So there is a chance we may end up removing those main.rs files and have one bin/src/{cli.rs, replica.rs}
  2. for type-safe canister interface import we're also thinking of auto-generating a trait for the canister, the design of it is still pending, but once we merge the dynamic canister ability, we can move to that.

But one of our main goals is being able to import the canister, that is:

  1. import the canister along its dependencies for testing.
  2. import the canister for dynamic creation (factory design pattern)
  3. Import the interface of the canister to do type-safe interaction.

@saikatdas0790
Copy link
Contributor Author

saikatdas0790 commented Sep 3, 2022

@qti3e
One final question. For dynamically created canisters, how do you prescribe handling migrations, especially if there's a schema change? Will ic-kit have any guidelines/features around it?

@qti3e
Copy link
Contributor

qti3e commented Sep 3, 2022

The upgrade and schema migration should happen on each canister level, we will only provide the installation helpers in the dynamic canister context.

But ic-kit-stable is probably what you would be interested in, it will contain stable data structures implemented. and as far as schema migration goes it's always advised to:

  1. never remove/rename a field at the application data model layer.
  2. always only append new optional fields in the model layer and provide a default value.

This will greatly reduce your cost of migration and more importantly will save you from headaches since you can still restore/decode data stored in a previous version and access it.

And as far as mass migration goes, we currently don't have something on the roadmap, but if it turns out to be a need for some project internally we may consider creating an option (Cap future migration might involve a mass migration, but I honestly don't know and wish it doesn't!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants