I was working on a project recently and was trying to build a smart contract to be deployed from the client side. The idea was to allow people to upload ride requests (and any kind of purchase requests really) as smart-contracts on an Ethereum network. Anyone could bid on it and the owner can then pick who he wants to make the purchase from. The transactions happens in ethers and weis and everyone is required to make deposits as guarantees to get involved. There are a bunch of ways you could do this. You could trust everyone using your service and lend them credit yourself. You could hold the guarantees on behalf of the participants yourself. You could get banks involved. The difference between all of these is who is acting as the escrow. I wanted to use Solidity contracts on Ethereum. There are 3 ways I could do this. I could run a front end which communicates with a backend that I maintain. The backend would communicate with the blockchain and communicate the transaction information back to the client. This would involve building a user account management system — which I eventually did end up building — and a node server to talk to the blockchain. This would have made the UX for the user easier as well. I could try to integrate a 3rd party wallet provider like coinbase or something. This would have also kept the UX simple and also allowed transactions in other currencies as well. In both these scenarios I would have to run a backend. I was curious to make it fully decentralized. To do this I thought to deploy and interact with the blockchain from the front end in my app. I could do that by writing and testing a smart-contract. Once I was certain of its correctness I would compile it and host it online. The app can then fetch this contract and deploy/use it. Ideally I would like to compile on the front end as well, but that might be tasking the front end with an unnecessary overhead. The current approach is good for now. I will not go into the UI and other services that was a part of the app. The communication with the blockchain would be same irrespective of other parts of the app. _contracts - Contracts for O-LAP_github.com O-LAP/contracts This is the contract written in Solidity. It is a very simple bidding contract. I did some very basic testing. _Edit description_remix.ethereum.org Remix - Solidity IDE Then I used to compile the contract to get the contract ABI and bytecode. I hard-coded these two into my app, but ideally I would like to host them online and only store the link to that on the app. remix _After the online remix solidity compiler recently changed design, I can't figure out where I can find the contract's…_ethereum.stackexchange.com Where to find contract ABI in new version of online remix solidity compiler? This link might be useful to extract the ABI and bytecode for your contracts. The app deployed a new contract when someone created a new purchase request and read values from deployed contract to show the information and called different methods to bid, reward and claim rewards from the contract. I assumed the client would have installed to manage their wallet. MetaMask This gist shows shows how I am deploying a contract on user request. One situation I faced was I was trying to deploy a contract and immediately call a method on it. So the user would click the button, which would open the deploy contract request from MetaMask and few seconds (few minutes on mainnet) later call a method on the contract to initialize it with relevant information. That should ideally be done in one click for the user. This is how I was calling methods on contract once I have the deployed contract address. This is how I was reading values from a deployed contract once I have the address. I am still running into one CORS issue that I need to resolve. But here are my thoughts about this. Pros: Decentralized I don’t run any backend.* App can stay always up to date. Cons UX is stinted. Expecting users to have MetaMask. Bugs in deployed contract are not fixable. I do need to run backend servers for other parts of the app. It looks like a worthwhile approach. The problems listed in cons are something that is resolvable or kind of problems we already live with. Article by Amit Nambiar for O-lap
