Hey Joseph, hopefully I can help solve a few of the issues you’ve mentioned above.
Motoko has a different approach to stable data, which is to store it using the stable keyword that automatically persists the data during canister upgrades without having to do the serialization yourself.
There are numerous stable data structures in Motoko, including just to name a few
- Hash Map & Set
- BTrees
- Vector (i.e. array/buffer)
- Linked List
- Merkle Patricia Trie
If you’re referring to using actual stable memory directly, I agree the current APIs for directly accessing and manipulating stable memory in Motoko are difficult. Luckily, the Motoko team has been working on Enhanced Orthogonal Persistence, meaning that state will persist indefinitely and across upgrades without needing to use stable memory APIs.
Enhanced Orthogonal Persistence is close to completion, and when wasm64 support is released for canisters, this means that by just using the stable keyword, Motoko developers will be able to store 400+ GB memory in the canister heap (increased performance), and stable keyword will allow for instant upgrades of 400+ GB of heap-based variables.
Are you referring to an asset canister, or NFTs?
@ferMartz built Nitro, a decentralized file store using Motoko and CanDB. CanDB dynamically spins up auto-scaling canister partitions on demand, and I believe all the assets are stored as Blob type in the data store.
I’d be interested in learning more about the different roadblocks you ran into in using Motoko. Chances are you’re definitely not the only one!