The ABC of a great DApp Architecture
So you’ve got your first smart contract developed — you’ve tested it locally and you’re happy with it. Now comes the big step — pushing it out into the wide world. But you have to ensure that you have your ABCs of architecting it right first…
A: The Smart Contract Infrastructure
In the days before the blockchain developing a distributed App involved a lot of knowledge — it’s something we’re used to doing here at PlanetCrypto.app (And still do). It’s heavy lifting work… managing servers, scaling them up and down as the load demands.
What’s really refreshing about the blockchain is that it handles all of that for you… once your smart contract(s) are deployed they run ‘automagically’ on the global computer that is the blockchain! You don’t need to worry about instance types, whether your servers are up, whether someone in datacenter A has an issue with the fibre etc. It’s all handled. Magically… well almost.
What you do have to worry about is the gas price. And that is where efficiency in coding and contract design really matters. But that’s another blog topic!
Another major headache with smart contracts is that once deployed and engaged with users there is no going back, there is no altering the contract! If you’ve made a mistake you have to fully re-deploy a new version of the smart contract and move all of your users to the new contract — losing any data stored in the old contract!
One useful tip here is to try and separate as much functionality as you can into separate contracts. E.g. put your business logic into one Smart Contract, your Data Model into another and then a main Controller contract should be another contract which will run the whole DApp.
The main Controller will then call methods from the Business Logic and Data Model contract. If you need to upgrade the Business Logic you can then easily do so without losing all of your data! (The Controller would have methods & properties within it allowing it to change the address of the referenced Business Logic & Data Model contracts)
Don’t over do this though… calling out to other contracts does have a gas cost so you do have to weigh up the benefits. As an example, at PlanetCrypto.app we moved our main business logic into a separate contract because we know that we’ll be adding some new game features in the future — that way we are future proofing the main Token contract. The main token contract simply calls the business logic contract as required — but we can change the location of those calls to a new contract when we’re ready with the new game features.
But the smart contract is only one part of your infrastructure…
B) Your User Interface
Yes an end-user could interact with your contract directly if they wished to. It’s a bit clunky without a UI, but it’s possible. So we want a full User Interface.
And for that today we are talking about a HTML page. Specifically we will be using a HTML page along with the web3js javascript library which allows us to interact with the blockchain.
So far you’ve got:
A) Smart Contract Layer
[Blockchain global computer]
[runs your smart contract(s)]
B) User Interface Layer
[ui+web3js]
C) Your Transaction Interface
What’s important here is that we haven’t yet introduced any way to perform any transactions with the blockchain — all we can do is ready data from it.
Many people overlook the fact that you can actually use the web3js library with all browsers and even without a Ethereum Wallet if you just want READ-ONLY access to the blockchain. This is a really neat trick that can be used to populate your UI with data before a user unlocks their wallet or even if they are using a browser without a wallet installed. You don’t always need or want to ask the user to unlock their wallet to give them a glimpse of your DApp!
So the 3rd core element of our Infrastructure layers is the users Ethereum Wallet… this is often included as part of the browser (E.g. Brave, Coinbase Wallet, Trust etc) but is actually a separate layer and should be treated as such.
Your UI should work without a Wallet and work with the Wallet locked too! If you assume it’s not there and use a read-only instance of web3js you can show some DApp data to the user — hopefully enticing them into your game or app!
We use this as a feature to allow quick loading of our game data in PlanetCrypto.app for example — allowing the game map to be quickly populated even if the user hasn’t unlocked their wallet or even if they have no Ethereum enabled browser they can still browse all of the in-game items!
Thinking of these core layers in this way makes it easier to separate functionality, improve design and speed up development. You can easily separate individual tasks of development and then unit tests those items too.
Always think flexible — especially when your designing your smart contract… once it’s deployed to the blockchain that’s it — if you haven’t separated out your logic and you have data stored within the contract it is set in stone!
About Future Concepts & PlanetCrypto.app
Future Concepts is the development team behind PlanetCrypto.app and many other Ethereum projects. Having been in the development space for over 20 years they have now moved into Blockchain consultancy and development including the development and launch of their own projects.
PlanetCrypto.app is a Collectible Strategy Game for Ethereum — allowing you to own any part of the entire planet! It turns the entire map into collectible plots of 20²m that can be added to ERC721 compliant cards… which can then be used within the game to earn ETH or traded. It is quickly gaining traction with several thousands of square meters of land already sold!
The game is available now on the mainnet at: https://planetcrypto.app
