So, let’s say that I am building a community Dapp - as I see here on some of the existing Dapps after i joined, I am giving a Principal ID and a Canister ID - is that something that is necessary or just part of a being fancy? see attachment
2 Likes
It usually depends on the amount of users you have. If you can store all your users’ data in a few canisters, then a principal per user will suffice (which users get from their login method). If you have a ton of users with a decent chunk of data per user (for example OpenChat) then you will have to have a canister per user (or a group of a few users if you want to trade a solid amount of complexity for a reduction in canisters).
1 Like
So then, each canister will cost about 1 ICP , right? Because I’ll need to always give each of say my 1 million users one canister and those canisters need to be launched…how are these calculated?
Creating a canister costs 0.1T cycles, which is around 0.13 USD right now. Then you need maybe another 0.1T to get the canister going. Depending on where you convert, 1 ICP gives you up to ~14T cycles at the moment. Quite a few DEXes offer that rate right now
Does a tool exist for these calculations? As you’ve stated, currently, 1 ICP equates to approximately 14T. If the price for 1 ICP elevates to $300, would the equation of 1 ICP = 14T still hold? I’m in the process of designing a community comprising 10 million users, each with their own canister. This might be a complimentary service, like a social networking or dating platform, for instance. Considering the likelihood of users uploading a significant number of photos, is there a possibility of consolidating the canisters? If one user does not exhaust their resources, could these be utilized by another user, or is this something I need to resolve independently? I’m endeavoring to comprehend the potential possibilities.
The table of all cycles costs is here. I’m not aware of any estimation tools
No, if 1T cycles always costs 1 XDR at the current exchange rate. If 1 USD = 1.3 XDR and 1 ICP = 1300 USD then 1 ICP produces 1000T cycles
There is canDB, which is a NoSQL database that you could use. Otherwise if you don’t use an off-the-shelf solution you have to roll your own
Thanks for your feedback, a database looks like a viable solution. CanDB looks great, but I’m not seeing a Rust version.
@bblist Although 1 canister per user is a nice mental model and simplifies certain things, you may run into various issues if you application grows rapidly in popularity or usage. A few considerations to take into account:
- Spinning up a canister per user costs $$, and there are plenty of bot/spam users/principals on the IC. Also, you run the risk of burning through large amounts of cycles if your application becomes popular enough (good, but costly problem to have).
- CanDB makes it easier to manage multi-canister applications, but there still are trade offs involved when managing a multi-canister “microservices” application instead of a monolith. Higher level role based access control and any type of inter-canister call between services are more difficult problems to have, but on the flip-side a canister & principal id per user clearly embrace web3 data ownership principles.
- Subnets on the IC currently (as of this post) start to hit scalability limitations at around 80-100k canisters per subnet. This is being worked on by DFINITY, but has resulted in OpenChat moving ahead and pioneering a multi-subnet architecture. This architecture seems to work pretty well so far, but is far more complex than a single canister architecture.
- It’s much easier to start out with a single canister and then migrate to a multi-canister architecture once your application logic and state have grown and matured than visa-versa.
I hope this answers some of your questions and provides additional context. I’ve spoken with many developers using CanDB and before they start building, try to help them understand the tradeoffs of a single auto-scaling canister for all users, vs. 1000 users per canister, 10 users per canister, or 1 user per canister.
3 Likes
Didn’t this used to be 2T? When did this change?
Thanks much. But the question was, does it matter what programming language I’m using , I can still use CanDB with Rust or other?
Unfortunately, CanDB is only written in Motoko for the time being. - there are several stable memory libraries in Rust that I’d highly recommend using though!
It’s been 0.1T for creation at least since I joined in January 2022. Time flies…
But this is just canister creation - if you don’t add any extra cycles you can’t do anything with the canister. dfx originally (read: at the beginning of my tenure) used 4T cycles, so the canister would start with 3.9T cycles ready to use, but we changed that to 3T some time ago. Maybe one of your scripts does the same but with 2T?