Water Blower's avatar
Water Blower 2 years ago
IndexedDB is slow as hell. Chrome implemented IndexedDB on top of LevelDB and Firefox on top of SQLite. Almost all fast-enough web clients cache events in JS memory instead of query from IndexedDB on every read. This is also why I intentionally do not implement storage layer for nostr.ts. Browser is not designed for local-first, client driven applications. If you implement NostrDB on top of IndexedDB, you effectively implemented it on top of SQLite/LevelDB which is exactly what you planned to avoid at the first place.
↑ Parent

Replies (6)

JeffG 's avatar
JeffG _@jeffg.fyi 2 years ago
Thoughts on using redis or Postgres instead? Obviously you have the network overhead but feels like it could actually be much simpler given 2 decades of web apps being built like that.
2 replies ↓
Water Blower's avatar
Water Blower 2 years ago
At least in Blowater, my current solution is to treat IndexedDB as a huge string store. I don't query from it at all. I just load all events to memory on init and do manual map/filter/reduce on a huge event array. The performance is 100X better than querying from IndexedDB, even for 100K+ events.
2 replies ↓
Water Blower's avatar
Water Blower 2 years ago
I am exploring Tauri, it's like a better Electron. The native process is Rust instead of NodeJS. Maybe we can have 80% of the features in Browser and the user can choose to download a native app for the rest 20%. But this approach basically says goodbye to PWA mobile. Mobile is just too different. An attempt to cross-platform mobile is very hard.
1 replies ↓
Water Blower's avatar
Water Blower 2 years ago
@JeffG If this web client is SSR, when it makes a lot of sense. But it doesn't make sense for pure client driven SPAs or native apps. Effectively it becomes a different relay interface. So why not extend the query interface of relays?
1 replies ↓
↑