1. For authorization, its okay to use one badge for multiple components. You can think of authorization as a login to a service/platform you have in real life. Unless you have another whole service, just use one badge!
2. When creating protected methods, its also okay to use admin rights for components to store. This gives the flexibility that the component is able to call other component methods as well as an admin user (should you want to ofc)
3. A pattern I've been creating is you can relate an NFT to another NFT by storing the Non Fungible ID. For example, I have a unique NFT Contractor identity and I've picked up Work NFT, The Work NFT gets updated with the assigned contractor being the Contractor NFT ID
5. Testing #scrypto wasnt too bad an experience as I initially thought. The tricky parts were being able to understand how you can query the SubstateStore. It was tricky but you can use examples from resim to see how you can query specific resources/components/vaults
6. Try to keep in mind frontend requirements when you'd like to represent data. Its important to make your component eligible to be queried easily. This influences what you should store for users in a vault or what resources should be soulbound
1. Non Fungible and Fungible resources are known first hand by the engine and #scrypto. This is HUGE. You dont need to design behaviors of mint, burn, transfer. They are NOT contracts. These are RESOURCES. This is TRUE native asset first #smartcontract
2. Authorization is built in as a concept and comes in 2 forms. These are simply Fungible/Non Fungible resources. These resources can be used as a form of authorization. In #scrypto, we call them a Proof. Why do we need them? Direct mapping of address => some data is UNSAFE