distributed-counters
absurd-sql
distributed-counters | absurd-sql | |
---|---|---|
1 | 24 | |
6 | 4,057 | |
- | - | |
10.0 | 2.5 | |
almost 11 years ago | 9 months ago | |
Erlang | JavaScript | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
distributed-counters
-
Downsides of Offline First
I was also a "true believer" in CRDTs for a long time, implementing my first ones in Erlang about 9 years ago[1], but my opinion of where they fit has changed significantly.
The one issue with CRDT that I find is rarely mentioned and often ignored is the case where you've deployed these data structures that include merge logic to a set of participating nodes that you can't necessarily update at will. Think phones that people don't update, or IOT/sensor devices like electric meters or other devices "in the wild".
When you include merge logic β really any code or rules that dictate what happens when the the data of 2 or more CRDTs are merged β and you have bugs in this code running on devices you can never update, this can be a huge mess. Sure you can implement simple counters easily (like the ones I linked to), and you can even use model checking to validate them. But what about complex tree logic like for edits made to a document? Conflict resolution logic? Distributed file system operations? These are already very complex and hard to get right without multiple versions involved and unfixable bugs causing mayhem.
Having to deal with these bugs in the context of a fleet of participants on a wide range of versions of the code, the combinatorial explosion of the number of possible interactions and effects of these differing versions and bugs taken together can really become impossible to manage.
I'd be interested to hear from folks who have experience with these kinds of issues and how they have dealt with them, especially if they are still convinced that CRDTs were the right choice.
[1] https://github.com/nicolasff/distributed-counters
absurd-sql
- Absurd-SQL: sqlite3 in ur indexeddb (hopefully a better back end soon)
- What If OpenDocument Used SQLite?
-
WASM SQL database recommendations wanted
Not really, but I'm aware of absurd-sql. Note that this requires IndexedDB and thus a browser environment.
-
Best local database that works on all platforms including web?
I don't need SQL capabilities, so I didn't look into those options (there's also absurd-sql, which ports sqlite to the browser on top of IndexedDB).
-
SQLite WASM in the Browser Backed by the Origin Private File System
Ironically I was just about to drop in absurd-sql [1] to a project, which uses indexeddb to back SQLite. This seems better.
[1] https://github.com/jlongster/absurd-sql
-
Irmin in the Browser (OCaml/MirageOS)
There is also absurd-sql that is sqlite3 in wasm using IndexDB as storage and itβs faster than IndexDB itself
[1]: https://github.com/jlongster/absurd-sql
-
Postgres WASM by Snaplet and Supabase
Offline data: running it in the browser for an offline cache, similar to sql.js or absurd-sql.
- WordPress WASM
-
Learn PWA
We are very close to having WASM SQLite with persistence in the web platform. Until now SQLite compiled to WASM was in memory and you had to write the whole database out as a binary array to save changes. There is absurd-sql (https://github.com/jlongster/absurd-sql), which builds a virtual file system on top of IndexedDB for sqlite, its incredible, but a bit of an ugly hack.
However, the new file-access apis (https://developer.mozilla.org/en-US/docs/Web/API/File_System...) that are landing in browsers will fix this. One of the things it does is enable very efficient block level read/write access to a privet sandboxed filesystem for the websites origin, perfect for persistent sqlite. There is more here: https://web.dev/file-system-access/#accessing-files-optimize...
- Learn Postgres at the Playground
What are some alternatives?
offix - GraphQL Offline Client and Server
lovefield - Lovefield is a relational database for web apps. Written in JavaScript, works cross-browser. Provides SQL-like APIs that are fast, safe, and easy to use.
shelf
crdt-example-app - A full implementation of CRDTs using hybrid logical clocks and a demo app that uses it
dolt - Dolt β Git for Data
realtime - Broadcast, Presence, and Postgres Changes via WebSockets
donutdb - Store and query a sqlite db directly backed by DynamoDB.
localForage - πΎ Offline storage, improved. Wraps IndexedDB, WebSQL, or localStorage using a simple but powerful API.
LevelDB - LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.
meteor-mysql - Reactive MySQL for Meteor
stolon - PostgreSQL cloud native High Availability and more.
yugabyte-db - YugabyteDB - the cloud native distributed SQL database for mission-critical applications.