Contract structure for storing user application

Question

I have a Nodejs application in which users fill up multiple forms and that data is saved to the centralized DB i.e MongoDB. Admin can review the user data and can push the user data to Blockchain to maintain the integrity of data so that any third party can view the data in future and verify its integrity.

Now, as data is large it can't be stored directly to the blockchain. So, I am converting the data first to pdf and then creating the hash of pdf using Keccack 256 algorithm and storing the hash to the contract. And in return, I get a transaction Id which I can later use for retrieving the data from the blockchain.

Please suggest If I am on right track or there is a better approach for this.

Note:- If a user updates his application, Admin will again push the user data to the blockchain.

This is the contract code I am using:

pragma solidity ^0.4.17;
contract AddUserApplication {
    string public userdata;
    function addUserData(string data) public {
        userdata = data;
    }
}

// Code for retreiving the data from Block:

    const viewTransaction = async () => {
    let viewData = await web3.eth.getTransaction('0xd819b09a906232a37b6ad102a7616eed6af9d968718b23878e023ccf7f967f8');
    console.log('viewdata: ',viewData.input);
    const decodedData = abiDecoder.decodeMethod(viewData.input);
    console.log('decodedData',decodedData);
}

Answer 1

So, I am converting the data first to pdf and then creating the hash of pdf using Keccack 256 algorithm and storing the hash to the contract

Why not just take the mongodb document output (JSON) and hash that instead? Introducing PDF in between seems unnecessary, and PDF conversions tend to be fairly flaky between convertors. It would be pretty easy to end up with different PDFs for the same data, and thus different hashes.

And in return, I get a transaction Id which I can later use for retrieving the data from the blockchain.

The transaction ID on its own has little to do with being able to retrieve the data. It will simply help you determine if you were successfully able to include it in the chain. Moreover, you will never be able to retrieve the original data from the chain if all you are committing is a hash of the data.

Your contract also only supports one single string. A better idea would be to have a uint -> bytes32 mapping, and commit a hash for a userid, which you can then read later using the user ID.