How feasable would it be to make native_db kv store agnostic?

[C4Phoenix]

Would it be possible to make native_db 'front end' depend on a KV database trait so that it would be possible to change the storage engine. This would then make it 'easy' to use together with projects like Iroh or implement a wrapper for IndexedDB to support databases in browsers. I think this could really increase adoption of this wonderful project if it can be dropped on top of a kv abstraction.
A complication that I can already think of is if there are external updates to the same db and how to sync those. Or how to make sure they don't happen if it cannot be supported etc.

[vincent-herlemont]

@C4Phoenix Actually, that would be possible. I have already looked into the possibility of doing that, but it would require a major refactor!

Note: Regarding IndexedDB, there is an issue with the fact that Native DB is not asynchronous, and therefore we would need to study how this could be implemented. Related issue: #65.

I am not opposed to opening an issue for this; however, it is not in a short-term project.

[C4Phoenix]

I thought it would be very intensive as well having looked at the code a little-bit. But if it is done in two steps it might not be as painful. We can first program against multiple traits no matter what these look like, just to make points for injecting a different implmentation. Then see how that looks and what changes can be made to make it more ergonomic for accommodating other Databases.

trying to sketch how an interface would look like in an ideal world. Maybe something like this

pub struct Key(Vec<u8>)
pub struct Value(Vec<u8>)

pub struct KeyValue{
    key: Key,
    value: Value
}

enum KvStoreSetError {
    InternalError(..),
    KeyToLarge,
    ValueToLarge,
    ...
}

enum KvStoreGetError {
    InternalError(..),
    KeyNotFound,
    ...
}

enum KvStoreDeleteError {
    InternalError(..),
    KeyNotFound,
    ...
}

trait KvStore {
    fn set(&self, Vec<KeyValue>) -> Vec<Result<(), KvStoreSetError>>;
    fn get(&self, Vec<Key>) -> Vec<Result<KeyValue, KvStoreGetError>>;
    fn delete(&self, Vec<Key>) -> Vec<Result<KeyValue, KvStoreDeleteError>>;
    fn request_commit(&self) -> Result<(), KvStoreCommitError>;
    fn iter(&self) -> Iterator<Item=KeyValue>;
    fn iter_range(&self, ..) -> Iterator<Item=KeyValue>;
}

trait AsyncKvStoreService {
    // can be used for the frontend to route updates to the watch channels
    async fn get_update_channel(&self) -> MpscReader<Update>;
    // blocking call to start the service and makes possible to be more platform agnostic
    async fn run_service(&self) -> Result<(), KvStoreStartError>;
}

I think havy use of communication channels and services are needed on both the frontend and KvStore implementation side. If it were ever too look like this. But I dont think it is a requirement to be async in order to implement indexeddb.

If the KV store has commit and or snapshots that can all be abstracted away in the implementation and/or we leave a handle for the user so they can still do those things manually.

Just to be clear this is a illustrative of a way we can implement a trait, not necessarily the way it should be done. I'd like to hear your thoughts about it.