In the part 1 of the series, we had set up SDKs and tools needed for development of our DApps-like Rest API. The second part introduces a sample contract conforms with ERC-20 standard, which will be used by our web api to interact with blockchain.
The overall architecture of our project would look like below.
The advantage of adding a back-end layer is that your front end Dapps is decoupled from the smart contract.
Most demonstrations of Dapps omit the API layer, the web app directly interacts with the blockchain and handles all calls to smart contract via web3js or similar frameworks. Being structured this way the Dapps is tightly coupled with the contract underneath and might end up in a spaghetti architecture where front end and back end code get messed up. Remember we have evolved from the dark age of internet ? Right, for modularity, maintainability etc… we need to separate back end from front end.
What if your client base is inhomogeneous ? What if your law firm have many versions of a legal contract and also many different contracts to maintain ? Are you sure you want to release a new website to serve every new contract ? If a smart contract is considered as a client service, you might want to spin up or tear down new services without impacting normal function of your business. That is where microservice architecture comes in handy. Each microservice serves a smart contract and can be totally independent of others.
With Asp.Net Core and Nethereum, the above system could be easily set up.
- 1. Create .NET solution
- 1.1/ Create Solution
- 1.2/ Create Asp.net Core web api project
- 1.3/ Move smart contract folder into your solution
- 1.4/ Create classlib projects to refactor your code
- 2. Install Nuget packages
- 3. Project Web Api
- 3.1/ Add references:
- 3.2/ Configure dependency injections in Startup class
- 3.3/ Configure Authentication service
- 3.4/ Contract Controller
- 3.5/ People Controller:
- 3.6/ Account Service:
- 4. Using Nethereum to interact with smart contract
- 5. Test APIs
- 6. Hosting