Best practices for a high traffic dapp launch
Summary
Starting the project
Choosing a programming language
Motoko
Rust
Writing the dapp
Getting help
There are few resources where developers get help while building a dapp:
- Developer forum
- Developer Discord
Testing the dapp
Stress testing
The IC does not have a testnet. Instead developers are encouraged to use the mainnet for test purposes. Before developers deploy the production ready dapp to mainnet and enable access to it to the world, they should first deploy test versions to mainnet. They should then stress it by emulating the anticipated load on it and see how well the dapp and the platform in general fares. If the desired performance is not achieved, developers are encouraged to get help by using the links provided above. Often times, the desired performance can be achieved by performing minor tweaks to the dapps.
Deploying the dapp
Launching the dapp to the world
Monitoring the dapp
Lessons from past launches
Motoko version
Motoko is a language being actively developed so it is recommended to use the latest version of Motoko to get maximal stability and performance.
Inter-canister calls[1]
The Internet Computer system provides inter-canister communication that follows the actor model: Inter-canister 'calls' are implemented via two asynchronous 'messages', one to initiate the call, and one to return the response. Canisters process messages atomically (and roll back upon certain error conditions), but not complete calls. This makes programming with inter-canister calls error-prone. Possible common sources for bugs, vulnerabilities or simply unexpected behavior are:
- Reading global state before issuing an inter-canister call, and assuming it to still hold when the call comes back.
- Changing global state before issuing an inter-canister call, changing it again in the response handler, but assuming nothing else changes the state in between (reentrancy).
- Changing global state before issuing an inter-canister call, and not handling failures correctly, e.g. when the code handling the callback rolls backs.
If you find such a pattern in your code, you should analyze if a malicious party can trigger them, and assess the severity that effect. These issues apply to all canisters and are not Motoko-specific.
Rollbacks[1]
Even in the absence of inter-canister calls the behavior of rollbacks can be surprising. In particular, rejecting (i.e. throw) does 'not' rollback state changes done before, while trapping (e.g. Debug.trap, assert…, out of cycle conditions) does.
Therefore, one should check all public update call entry points for unwanted state changes or unwanted rollbacks. In particular, look for methods (or rather, messages, i.e. the code between commit points) where a state change is followed by a throw).
This issues apply to all canisters, and are not Motoko-specific, although other CDKs may not turn exceptions into rejects (which don’t roll back).