What is the recommended way to store media files in DApps?
There is no recommended way. Most DApps do not deal with media but with value, security and problems that require cryptographic proofs or authentication (who is who and who owns a certain private key). And yes, IPFS and Swarm are data storage options. IPFS is cutting edge right now, meaning not everything is perfect. It is growing, they have an awesome team (like super awesome), and now they have near-unlimited capital, so that bodes well for the future of IPFS and Filecoin. Media files are typically large compared to text and storing data is very expensive on the Ethereum blockchain (ranging from $0.09 - $0.90 per kB at current Ethereum prices). Not to mention the limitations and difficulty of working with media files (assuming you'll need to do something more than just store them)in Solidity.
What are the recommended ways to authenticate users in DApp?
This is one nice thing about DApps: only those who possess a private key and the passphrase of an account can authenticate as that account, so having users authenticate themselves is built into Ethereum. You mention uPort, which is early stage itself but has a nice team as well. uPort delivers your Ethereum public key (this goes back to the public/private key bit which is built into Ethereum). This address is a very unique user identifier. See the public_key bit in the following image from a recent uPort blog post:
What techonology stak[sic] is recommended for frontend (Mobile,Web)? Is there any need for backend or middleware for DApps?
There are a few parts of typical DApp tech stacks:
- Solidity smart contracts that are executed and stored in the blockchain
- A javascript web client that connects to
geth nodes (these are the clients' way of connecting to and interacting with the blockchain)
- The clients in #2 basically all run
web3. web3 is a Javascript library written by Ethereum itself. web3 is definitely something you'll need and want to get familiar with.
- Possibly IPFS for storage of data off-chain that is one or both of: too large to store on-chain or too difficult to work with with the current limitation of Ethereum Virtual Machine high-level languages.
Fourth Question: Is it possible to develop a system in a conventional way with centralized database (marai/mongo/casendra) communicating with backend but backend is also linked with blockchain for saving hashes of data for its proof of existence.
Short answer is yes, it is possible. How this problem is solved is of great interest to me working on http://Disten.se right now. We have built a tool that maps git hashes to IPFS hashes, for instance (to allow the state of a repo to be secured on chain). This is a way of storing (which is really what blockchains are good for) a pointer to the correct or true state of some content elsewhere. As you hinted at, the hash can actually encode the content itself (which is an amazing property of hash functions), and can be updated according to a set of rules written in your smart contract code.
Fifth Question: What are the good practices or recommended way to architect and develop huge blockchain based systems (Dapps) ?
This series of questions somewhat answers this question, so I hope you find the above valuable. Feel free to get in touch if you have any more questions I can help with.
