We have a website which is developed on Boostrap+Nodejs+Mongodb framwork with couple of AWS services.
We want to see the possibility of moving to Solana blockchain. Reference example, How brave browser is leveraging blockchain for its business model.
Any suggestions on suggested migration path for classic websites to blockchain.
Hi Rajsol
Hope you are doing well
As I am experienced Blockchain Developer and I can help you to migrate the website.
You can reach out me at james@techsolvo.com
Looking forward to discuss with you
Thanks & Regards
I’d that it depends a lot on what your app does, and has a lot to do with re-modeling the way you think about solving the problem, because now, instead of having a “normal” database, you have to work with transactions on the block chain that have to finish execution in a small amount of time and you only have so many different ways of querying data on the chain.
It’s probably best to discuss specific use-cases as the solution really depends on what you’re trying to do.
Our website is a Job portal.
Where a recruiter will be Making a job post and Candidates will register & apply for the jobs. And Multiple other actions.
That should work relatively simply on Solana, then.
The biggest obstacle to developing on Solana right now is that some things are not well documented. I wrote an ultra-small and incomplete meeting scheduling app ( which is actually quite similar to a job portal app from a functionality perspective ) on GitHub, but I had to figure a lot of it out myself by looking at existing Solana programs. Once you get past the initial learning curve, though, it’s not super complicated.
Here’s a rundown on some of the core aspects of how your app would work if it was built on Solana.
Firstly, all your business logic would be implemented as a Solana Program, which Solana’s name for what Ethereum calls a smart contract. Your program would be deployed to the Solana Mainnet Beta.
Your web app would probably be a single page application that would communicate to your Solana program by sending Transactions to it using the JSON RPC API.
For your app you probably will want to run your own RPC Server, which will guarantee the availability and bandwidth for you to communicate to the Solana network, instead of using the public RPC endpoint that everybody else uses for casual accounting, etc.
For data storage, all data has to be stored in a Solana Account. Do not let the name confuse you, accounts in Solana are not typical database accounts or anything. They are much more like files. These accounts would roughly correspond to documents in a MongoDB database, for instance, and they are stored directly on the blockchain.
If you want to store data such as images or larger amounts of text, instead of using accounts, you will probably want to use something like IPFS. Every file on IPFS has a unique name, that is actually the file’s checksum. This means you can upload the file to IPFS, and then store only the file’s name on the blockchain. You will need to run one or more IPFS storage nodes to store this data yourself.
Both sending transactions and saving data by creating accounts will cost your users small amounts of SOL in transaction fees. Thus, your users will have to have a Solana wallet, with a small amount of SOL at least, in the wallet, in order to interact with your app.
If a recruiter wants to create a job posting, they will use your app to send a transaction to your Solana program, that will instruct it to create a new job posting account. This will be stored on the blockchain.
Freelancers will then be able to use your app to submit a different transaction that will allow them to apply for the job. This will involve creating another account that will store the freelancers application for the job.
This pattern continues similarly as the recruiter can then submit another transaction to modify his job posting and select a freelancer who applied as the hired candidate.
Every interaction with the system is done through submitting transactions.
Finally, if you want to do full text search on posted jobs or freelancer profiles, etc. You will probably want to use an off-chain search index, that you can setup to be automatically updated every time a job posting is updated by subscribing to changes to your on-chain accounts using the JSON RPC API and websockets.
Anyway, that’s the breakdown! 
If you don’t have any experience in the space, you probably want to get somebody who knows it or is confident in learning new things, because it is a very different environment than traditional app development.
If you are looking to hire help, I don’t know @james or his work personally, but he says he has lots of experience. I’m also looking for work, and while I’m relatively new to Solana and blockchain, I’ve learned very quickly and you can see my profile and activity here on the forum on my GitHub profile to get more of an idea of what I’ve done. I’m also available for hiring on CryptoTask.
If this post helped you I’d really appreciate a tip, no matter how small, in whatever Solana or SPL tokens you prefer. It will help me spend time helping people on this forum and learning more about crypto. My wallet address is 9ftYTyetEXtLtDkhfRF8bCWGfKZqiYmx2HDZDTogZh6A . Thanks!
thats awesome. Thank you for that indepth explanation. Now, I could see a light on how things works in solana eco system.
A quick check,
When a company is posting a job, then should have solana wallet connected with their browser and then post it so that they sol is charched for that action.
Does it same for Job seeker/Freelancer also, when creating the profile, when applying for job and Modifying the profile etc. for every action done on platform Sol is charged?
can we work out something like, only organization actions can be charged with sol and for Freelancers its not considered. Just like Brave browser does.
Yes.
Yes.
These fees are usually very small I believe, fractions of a cent I believe for submitting transactions, but I haven’t check the exact value for storing the small amounts of account data you would need.
I think it would be possible for you, as the company running the website, to elect to pay the transaction and storage fees, but I’ve never specifically seen anybody do it before, so this is just my own idea based on how I understand it works.
I think it could work like this:
Solana allows setting which account will be the fee payer for a transaction, but that fee payer has to sign the transaction, to grant the transaction the right to spend its money.
To use this concept in your app, you would have to run an API on one of your own servers that would allow freelancers to submit transactions, so that your API could sign the transaction with your company’s wallet, allowing that freelancer to set you as the fee payer for that transaction.
So when a freelancer tried to apply for a job, your webapp would:
I haven’t tested this personally, but I think it would work, and it wouldn’t be very difficult to test out if you wanted to make sure it would work. And you can always ask about the strategy to make sure that other Solana developers think it makes sense on the Solana Discord or somewhere similar.
got it. Thank you so much for this.
It gave us enough info for brainstorm about our approach.
Hey, just had another idea of a technology that might be useful to you @Rajsol. Maybe look into deno:
And Deno Deploy:
Deno deploy is a serverless platform for JavaScript, TypeScript, and WASM, and it could work well for some of those pieces that can’t run on the blockchain such as the signing API for paying transaction fees.
Hi @saicharanpogul and welcome to the forum! 
In Solana, each Account has to pay rent, or it’s data will be deleted, so that the data contained can no longer accessed by smart contracts on the chain.
Typically, though, Solana applications will just make sure that they deposit 2 years of rent into each account that they store data in, to make that account rent exempt. Rent exempt accounts will not be charged rent and will therefore be permanently stored on the chain ( unless you withdraw the rent from the account, which will allow the account to be deleted ).
In summary, this means that you just have to pay a certain amount of SOL for every byte of data you store directly on the Solana chain.
Let me know if that doesn’t answer your question!
Thanks @zicklag. So, say as a program developer if I make sure each user account(s) are enough funded to be rent exempted forever, does that mean the user can make free transactions forever?
No, rent is separate from transaction fees, which are paid every time you submit a transaction to the chain.
Users may still have to pay up to $.01 worth of SOL for every transaction they make, unless you use the strategy I mentioned above for having somebody other than your user pay for transaction fees:
Also, just to make sure it’s clear, Accounts in Solana are similar to files that store data. If your user needed to create some data to be stored on the chain, such as the number of likes something has or some other piece of data, then that user has to deposit SOL from their wallet to that Account that stores the data.
If you wanted this to be free for the user, so that they didn’t have to pay the fee, you would have to use the setup I described above to have somebody other than your user pay the fees.
Yeah thats what I wasn’t sure about, just needed know is that how rent exemption worked. But its makes sense now. Yeah having someone else to pay for transaction fee would be a better user experience but obviously it comes at a cost of decentralization and however fees is way cheaper. Can you show or provide me with some reference for a simple example of how to keep accounts rent exempted so that they don’t get deleted, with both vanilla Rust and Anchor, that would really help me! Thanks @zicklag.
Check out this section of my little demo Solana program:
When we call the system instruction to create the account, we use the rent.get_minimum_balance function to get the amount of lamports that must be stored in the account to store the number of bytes that it takes to store, in this case, an account that stores data for a scheduled time slot.
This will be similar in Anchor, and it could also be done client side, instead of in a smart contract. The web3.js Solana API has helper functions for calculating how much rent is required to make any amount of bytes rent-exempt.
Just make sure you transfer that number of lamports to any newly created accounts and you’ll be good to go.