What elements of a Dapp's backend are usually stored in a decentralised location?

Question

I'm unclear as to what elements of a Dapp's backend code are actually decentralised.

The following link states that a Dapp's backend is stored entirely on the blockchain. However, if I was to create a Dapp web application, how much of what would usually be referred to in a web development sense as the "backend", actually be located on the blockchain?

For instance, if I was to develop a web app using Python, would the entire function of my Python code be replaced by a smart contract if I was developing a Dapp, or just the key elements of the business logic?

Answer 1

This following image helped me understand how decentralised applications fitted together. I'm typically a Java developer so I'm more familiar with writing middleware for some J2EE-server and hosting the application like that. I'm keeping this explanation somewhat very high-level.

I'm currently opting for the approach of:

• Replacing Java (backend code) with an Ethereum smart contract written in Solidity.
• My application would usually be coupled with a database for persistent storage. In order to reflect this with my new DApp, I'm opting for the usage of IPFS.
• IPFS stores the static content which is hosted throughout a network of nodes. e.g. images, front end code, data.
• Once we have the static content, i.e. HTML, JS, CSS we can then interact with our local Ethereum node. i.e. the blockchain (even more specifically, the smart contract that was deployed to the network via its contract address and the contracts 'abi'.)
• In the image we can see that there is an arrow pointing from Ethereum to IPFS. This is explained simply. We can store the hash of a file that was published to IPFS in the smart contract. With this reference we can retrieve it by using our IPFS node at any time.
• IPFS NODE ----> REQUESTS with content #
• IPFS NODE <---- RECEIVES corresponding content from network
• New shiny content file now included into the DApp for the user to play with!

I have a standard web application that allows users to upload their profiles. The extent of the Java code is reading in the data via endpoints and storing to a database. The application server would also server the static content to a user hitting a certain URL. The decentralised version of this simple application would be as follows:

• Solidity back end to accept user data in the form of a hash (replacing Java back end). Changing the applications "Global state"
• IPFS holding webpage, will serve it upon request.
• IPFS holding more data relating the hashes stored in the smart contract.

A lot of logic in the application has migrated to the front end code. Note, this is a fictional application and has only been used as an example.

Here's a great example of connecting IPFS with a Solidity contract and querying both through the JS console in your browser.

Thank you, I hope this helps!

Answer 2

If we consider DAPP= frontend+backend
then the Front end (not in the blockchain) will be the standard web frontend e.g javascript(web3js)+HTML the used technology needs to dispose of an RPC API who interacts with the ethereum client.
Backend = smartcontract (stored in the blockchain) e.g solidity contracts where you define your business logic (transactions,etc) and keep in mind the smart contract has its storage(located in the blockchain) where you can store your app data.
Except the smart contracts everything is outside the blockchain.