How to handle access to wallet.rs Stronghold database in a serverless web app

Question

Excited by the upcoming release of Chrysalis I wanted to start a little web app project using the wallet.rs library. Without going into too many details, users on the site will be able to generate an Iota address to deposit their tokens and have the ability to withdraw them. I'm, using Next.js for the web app, and deploying on Vercel, which will automatically create my API routes as serverless functions.

I'm stumped on how to proceed with the integration of the Node.js wallet.rs library into my web app. The issue is the wallet.rs library creates a Stronghold database that can only be accessed locally on the machine. This doesn't work in a serverless environment because there will be many machines/instances being spun up. How can they talk to a singular, locally stored Stronghold database?

I was thinking of storing the Stronghold database onto a storage service like AWS S3, however many serverless functions downloading the database file onto their own machine, performing their own actions, and overwriting the database back into the S3 wouldn't work too well. It would overwrite the data the other machines had written. Doesn't seem too efficient either.

Is there something I'm missing on a simple way to have a serverless application integrate the wallet.rs Node.js library?

Answer 1

This is an interesting question. Stronghold requires that each user has its own snapshot. In other words, each wallet.rs instance will have its own associated snapshot file. For reference, the snapshot is where all of the secret key data is stored and each snapshot will have its own password.

I am not sure how you can do this with a serverless environment outside of spinning up a small file system layer or having each user store their own snapshot locally. If it comes down to it though, you could try to swap out the sqlite/stronghold backend for something like DynamoDB but that would be a fairly complex process.

I would also be careful with storing the user's passwords in such a service. If you have both the password and the snapshot then you also control the user's seed.