Ability to save the bank

[poop-creator]

If the room host disconnects it seems that the bank is deleted. Rather than it being linked solely to the room is it possible to save it to a file, and also to have the room's host change to another user if the current host disconnects so that the room and bank dont just poof.

I am not a programmer, but think this would be great :)

[clragon]

this would also be very useful to me, as I like to close the room and reopen it again later, when the session continues.
Long runs often take multiple days and we normally have to manually empty the bank each time.

[RiftingFlotsam]

Similarly, if a player drops from a room and rejoins they can lose access to items deposited before reconnecting.

Don't know how feasible this is but a more robust event logging and syncing system would be nice. (This scenario can cause issues with other events such as perks too.)

[steelstiletto]

I would like to second this idea. I'm trying to do long runs with friends, but we cannot safely store anything in the bank between sessions, as the lobby will inevitably need to be restarted before we resume again.

[stefnotch]

@soler91 I'd be interested in implementing this, basically all one would have to do is to serialize and deserialize the bank for a given lobby. (I'll also give upgrading the frontend to Vue 3 while I'm at it a shot.)

Any place in particular where I should add this, or if this might belong into the backend code? (which isn't on Github yet, I'd gladly help out with that if possible)

[stefnotch]

Okay, I've taken a long and close look at this.

tl;dr

If we want to go for the "put it into a JSON file" option, then I'd opt for lowdb.

If we want to put an actual, lightweight database behind it, then I think node-sqlite3 with kysely and writing a bit of code to support node-sqlite3 would be the best option.

Why?

So, I'd like something

• that can handle a few reasonably sized banks (100-1000 items)
• is very reliable (shouldn't corrupt data even when the app crashes)
• has Typescript support, and thus proper autocomplete (and stops you from doing obviously wrong things)

A JSON file seems like a too simplistic option, but maybe it's the easiest one?

• Doing it ourselves:
  • We have to use a library like https://github.com/fabiospampinato/atomically or https://github.com/typicode/steno for atomically writing files.
  • Database migrations when the saving format changes. I don't want players to randomly lose their banks.
  • We'll also have to deal with the Typescript stuff ourselves.
• lowdb: Might be a decent option, but doesn't have database migrations nor does it have support for maps
• sindresorhus/electron-store: isn't really designed to handle this much data

And if we want to check out the route of using a lightweight database, then...

• Indexeddb with Dexie: Would only work in the render thread out of the box, so we'd have to send a lot of objects over IPC
• sql.js: sqlite compiled to Javascript, needs a wrapper, proper filesystem support would be nice Allow hooking into the filesystem and providing a persistent backend (like absurd-sql) sql-js/sql.js#481
• node-sqlite3: native dependencies,
• better-sqlite3: native dependencies, no N-API support N-API Support WiseLibs/better-sqlite3#271
• level: key-value database, need a wrapper for it to be a properly usable database option
• LokiJS: No Typescript, mostly in-memory
• @seald-io/nedb: No Typescript
• NeDB: Unmaintained
• linvodb3: Unmaintained
• PouchDB and pouchdb-node: Community maintained Typescript, not sure

And about those wrappers I talked about

• kysely: no sql.js support, no sqlite3 support but that can be implemented
• Knex: Not really Typescript-y, no sql.js support
• trilogy: outdated dependencies
• typeorm: decorators aren't cool
• objection: no sql.js support, maintenance is slow
• sequelize: no sql.js support, fully blown ORM
• mikro-orm: no sql.js support, fully blown ORM
• rxdb: No decent underlying database

[stefnotch]

Apparently there's yet another trade-off that needs to be made:

The database options work asynchronously. This means that

• we either make sure every message gets executed in order and waits for the previous one to finish
• or we don't write code that is subject to race conditions (the typical approach when writing backends, but it's near impossible to actually guarantee this)
• or we have the saving/loading as a separate thing, maybe running on a timer

[stefnotch]

And then there's the very alternative option of just dropping Electron, switching to Tauri and using a Rust-y database like bonsaidb, sled, sanakirja, rusqlite, ... with maybe an ORM like diesel.
Or a more NoSQL database like https://github.com/TheNeikos/rustbreak , https://github.com/pipedown/noise , https://github.com/tikv/tikv , https://github.com/zitsen/unqlite.rs , ...