Backend development, to many functioning websites and technologies, are crucial because this aspect handles quite a lot of technicalities under the wood. It ranges from handling the databases of users, security, performance, authorization and authentication. The list of functionalities that a Backend fraction of an app development unfolds more depending on the kind of technology integrated into the application. Nonetheless, there’s a need to lay emphasizes on database, security, and the paired, authorization and authentication.
Shifting the scene to the web3 ecosystem where most interaction with a decentralized application is with a smart contract. Smart contracts are different your understanding of backend development in web2. Every interaction, with a blockchain network, comes with a cost. Herein, I’ll explain how smart contracts are not the usual backend that must receive all of the details of the users of your software applications.
WHY GET ALL THE INFORMATION OF YOUR USERS?
For some beginners, writing smart contract is similar with writing backend codes that receives virtually all the information of the users of the application. Some are quick to hop in on the creation of projects that captures names, births and many other personal information. Sorry to make this known to you, smart contracts are too smart to be made smarter with those information.
Interaction with blockchain technology, despite the privacy it creates, make known to the general public who and who is interacting with a smart contract. You don't want to give way more details to block explorers. Aside from the revelation of the details of your users to the public, the way smart contract operates, the mechanisms expect that a smart contract is gas-optimized inclined. A good understanding of gas optimization will unearth the principles of creating an optimized dapps that doesn't scare users with high gas cost for interacting with your decentralized application.
In order to make this more clear, I will show some practical examples I have witnessed from some beginners.
pragma solidity 0.8.5;
contract Office {
struct OfficeWorkers {
string name;
address owner;
uint256 phoneNumber;
}
function doSomething() external view returns(bool) {}
}
The block of codes above includes a struct that receives a string, address and an unsigned integer. Pretty receptive, right?
This indeed details who calls the function and provides the information but the sad truth is, the smart contract ecosystem involves money which invariably makes the provision irrelevant. With the codes above, it certainly will skyrocket the cost of calling a function to add those information to the state machine storage. Do well to check it out.
From a critical review of the block of codes, there are more than just one flaw of your smart contract becoming a database. The variable packing within the struct is poor. Variable packing? This is how your variables are structured to take a place on storage. We will look into it in another content in the nearest future.
Being a sensitive technology, writing smart contracts expects caution and concentration to understand how state machine aids successful transaction. The knowledge will help you filter appropriately unnecessary data that must go to the blockchain and create efficient decentralized applications.
Top comments (0)