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.

Reply to this note

Please Login to reply.

Discussion

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.

Wow didn’t realize perf was that bad.

I do the same thing. Write performance is the bottleneck though, read is slow but not unusable.

Looks like we all have the same problem. It's very good that we are exploring solutions independently. Creative solutions will emerge.

🤯 that’s insane. It’s actually faster to pull in everything and operate on huge arrays?!

Yes. O(n) in memory is faster than nlogn in disk for small data such as 100K events. That said how horrible IndexedDB is. Loading the whole table in indexed db is also faster than select 1 by index. My guess is that V8 team and other chrome component teams are at different levels. V8 is so fast that most computation heavy thing can happen in JS now.

nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpp4mhxue69uhkummn9ekx7mqpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcxuj6p8 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?

The smart client dumb relay setup with Nostr is great for encouraging decentralization. Which is why I think it’s great that we don’t extend that relay search interface too far.

That said, I believe we’re likely going to see a layer of caching services start to pop up to serve client devs but I’m not sure how I feel about that long term yet.