typingmonkey

The use case is to build a RxDB plugin that backups the users data into the prequel api.

Is there a way to get a stream of changes out of prequel (via websocket)? That would make it possible to live-sync between the customer's devices.

EventReduce - An algorithm to optimize database queries that run multiple times

https://github.com/pubkey/event-reduce

Using SQLite in the browser is great until you have users that open your app in more then one browser tab.

Zuckerberg will stop developing the metaverse.

To not fix other peoples bugs on my github repos.

Mark Rober also gets support from the LA police while they do not care about normal peoples theft.

That would only confirm that the new lichess version is faster, but not that scala3 is faster then scala2.

Isnt that what twitter has already done in the last years?

Fair point. From my experience people often think ipfs works equal to sth like a shared drive or filecoin, so I had to point that out.

You cannot "put stuff" on ipfs. Either you seed it or someone else does. If noone seeds it, it is gone. I bet most of it will be offline in 3 months.

See also the Event-Reduce algorithm which is a more lightweigt version of the similar principle. https://github.com/pubkey/event-reduce

In germany it is called the holy-johannes-grasp.

Satoshi Nakamoto used 2 spaces after a period.

> reimplement IndexedDB using FoundationDB. IndexedDB is also a key value..

I did sth pretty similar last month: https://rxdb.info/rx-storage-foundationdb.html

It supports indexes, mongoDB queries etc. to store and query JSON documents via RxDB on top of FoundationDB.

I mostly listen to raindrops on a tent [1]

[1] https://mynoise.net/NoiseMachines/campingRainNoiseGenerator....

Originally it was 3200 eth, but the price has risen too much.

Ok now I understand.

You can come to the RxDB discord for a chat if you want. I am really interessted in using WebAssembly for browser side storage.

I look forward to the day where someone reimplements IndexedDB via Webassembly, with the exact same API, so that we have a faster IndexedDB which uses the old one as storage layer :)

Thank you for these links, I will inspect that.

As far as I know, accessing IndexedDB from WebAssembly only works by passing the data through the JavaScript layer (correct me if I am wrong). So from how I think WebAssembly works, it is likely not any faster then directly doing that in JavaScript. I mean, the storage layer does not have to do any heavy computations, so tunneling the data would be more expensive then what you get from plain js.

When you store the data into an IndexedDB based key-value store, how does the querying work? Do you still use IndexedDBs secondary indexes when a query only matches a range of documents, or does the K-V store has any method to support querying a subset of the data without fetching the whole database state?

There are 2 things called "file system api" in the browser. One is the "File System Access API" to store files on a users OS. This cannot be used to store data of a database.[1]

The other one is the "real" filesytem api, which is not supported by most browsers. [2]

[1] https://developer.mozilla.org/en-US/docs/Web/API/File_System...

[2] https://caniuse.com/filesystem

I am developing a web/JavaScript database for several years now [1]. What I do not understand is, how graph based databases, (like surrealDB or gundb) plan to have great performance when they run in the browser. The thing is that you are always limited to store your data inside of the browsers IndexedDB. So as soon as you do not work with the same document-based model similar to the IndexedDB API, you will have big troubles when it comes to performance. For example how can you store and query graph based data in IndexedDB without heavily overfetching either on read or on writes? IndexedDB is already way too slow.

[1] https://github.com/pubkey/rxdb

Sounds like the feature set of RxDB [1].

[1] https://github.com/pubkey/rxdb

The posting refers to "f/x". So yes this is illegal in germany.

As I understood, they will directly begin to dismantel the plants. So there is no way back.

Like telegram did with the translate api, there is also a way to have an unlimited api for search results. You have to find one of the old mobile pages of google.

I can totally relate to that. When designing the RxDB GraphQL replication [1] protocol, it made things so much easier when the main data runs via normal request-response http. Only the long-polling is switched out for WebSockets so that the client can know when data on the server has changed. This makes it realy easy to implement the server side components when having a non-streaming database.

[1] https://rxdb.info/replication-graphql.html

Whenever I research the performance problem of a JavaScript library, I stumble over many deep clones even when it is not necessary most of the time. People are just not aware how CPU expensive a deep clone in JavaScript is, even more on big objects.

For example when you run a Node.JS profiling on the PouchDB test suite, most CPU cycles are spend in running the clone() function.

Having an updated performance comparison of structuredClone() would be great.

I analyzed [1] that problem and tried to reproduce data loss with LokiJS, which also has everything in memory and only partially writes to disc. It is very hard to reproduce a loss. You can call the saveDatabase() when the window 'unload' event fires and also after each write when the database is idle again. This works quite reliable.

The only way to lose data is when I shutdown power directly after a write.

It is also to mention that having everything in memory will not support multi-tab usage.

[1] https://rxdb.info/slow-indexeddb.html

LocalForage is similar slow as IndexedDB

https://pubkey.github.io/client-side-databases/database-comp...

Is it possible to also expose a websocket that emits changes?