Guidance on persistent storage within a universal resolver driver?

[vdods]

Hi all,

I'm creating a driver for did:webplus, which is designed to take advantage of local storage to expedite repeated DID resolutions to make many common operations operate in constant time and avoid a network request to the VDR. Ideally the storage is persistent so that if the service is restarted, then it still has all the cached data, and doesn't need to re-incur the overhead of a "cold resolve".

Is that possible in the existing universal resolver architecture? I think this would involve spinning up a sidekick Docker container (e.g. postgres server) with an attached, persistent volume.

Assuming it's not possible to persist data, I would just be using an in-memory data store, but that would really restrict the usefulness of the driver -- it wouldn't benefit from long-term archival of DID docs, and so it would mostly be useful for demo/dev purposes and not production contexts.

I am curious though: how long is a driver's container is expected to live? I think what I'm really asking is if there is some mechanism where the universal resolver service (to which the individual drivers are connected) will spin down a driver if it's not used for some amount of time (or any other reason).

Thanks in advance for help!

[peacekeeper]

@vdods I think it's not possible to do any of this in our public DIF-hosted instance of the Universal Resolver at https://dev.uniresolver.io/, since this is only meant for testing and demo purposes anyway.

Maybe you can make this configurable in your driver via environment variables, etc.? So if someone deploys their own instance of the Universal Resolver with your driver, they could configure it to use an external database, persistent volume, etc. as you describe.