This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-11-08
Channels
- # babashka (18)
- # beginners (35)
- # biff (15)
- # cider (24)
- # clj-commons (26)
- # clj-kondo (12)
- # clojure (18)
- # clojure-austin (1)
- # clojure-dev (2)
- # clojure-europe (15)
- # clojure-losangeles (1)
- # clojure-nl (1)
- # clojure-norway (88)
- # clojure-seattle (2)
- # clojure-spec (14)
- # clojure-uk (27)
- # clojuredesign-podcast (5)
- # clojurescript (25)
- # cursive (3)
- # datahike (26)
- # datalevin (13)
- # datomic (39)
- # etaoin (19)
- # events (1)
- # fulcro (12)
- # graphql (1)
- # hyperfiddle (40)
- # introduce-yourself (3)
- # joyride (8)
- # lsp (53)
- # missionary (7)
- # nyc (1)
- # off-topic (31)
- # overtone (10)
- # reitit (6)
- # shadow-cljs (9)
- # slack-help (9)
- # thejaloniki (1)
- # tools-deps (12)
I'm interested in using a datalog based client side persistent database for offline-first applications and came across Datahike. It wasn't clear to me the status of Datahike's ability to be used client-side, as the Github repo says Clojurescript support is still a work in progress, but the Datahike https://datahike.io/ says, "Adapts to different environments: Works natively in process on JVM environments and for major parts of the API on JS environments." If Datahike doesn't yet work for client-side, is there another recommended? I was also looking at https://www.cozodb.org/.
Let's say a Clojurescript application that might be run either as a website, mobile app, or Android app via Tauri.
Ya all the items I mentioned are really browser based persistence, as it's still web-based when running on desktop and mobile.
I mean the problem lies in browser-based persistence really. There is no reliant storage as I know
I think @U05095F2K gave it a lot of thoughts and still decided to go another direction
IndexedDB is not good. You would want to use OPFS. https://sqlite.org/wasm/doc/trunk/persistence.md#opfs It is the only viable solution for database-like level durability in the browser.
I would look at GraalVM native binary as an option. You can load that into Tauri as sidecar as a native executable.
Also I think Datascript has some persistence available now. If you do no require time travel and an immutable db that could be an option.
Yes, I provided the prototype for durability in DataScript that we are also using now and Nikita went from there, but he did not cover ClojureScript storage backends yet. I think the way to do it in DataScript is still to populate the database in memory at the beginning and then keep everything in memory and write it out from time to time.
I cannot recommend to use Datahike for that at the moment though. I would like to know how CozoDB handles durability on the client.
Oh so Datascript storage is only JVM atm?
@U04S13KL1R9 It would also be good to know what you exactly expect.
@U05095F2K Yes https://github.com/tonsky/datascript/blob/master/src/datascript/storage.cljs.
I was just looking for a db offering datalog like syntax and graph-like query abilities for a notes / planner application. These kinds of applications are frustrating if you can't use them offline, so was hoping to hear that either datascript or datahike offer a simple path to offline client-side persistence in the browser for local first applications that could be synced to a server db of the same type for long term. No I don't see time travel being needed on the client side, but would be nice server side.
Oh here, this showcases "upcoming support for Clojurescript". Is this support not ready yet? The "universal database" mentioned is what I'm hoping for - something you can use client side, sync to server when available, and benefit from graph abilities, but I'm trying to find out if Datahike is a good fit for this, or if the client-side work is no longer a focus or if something else has come along since this post. https://lambdaforge.io/2021/03/03/datahike-clojurescript.html
Datahike has been architected to allow it and it’s possible and proven to work. Though the work is a lot and requires funding to be completed. There has been interest in the past for this very use case but my personal observation is that the companies did not want to fund open source work that their competitors could benefit from.
Classic open source / capital problems is all it is.
Most work is either through consulting or in the spare time of developers when it delights them to noodle on a problem.
Man that's interesting and sad that a consideration of funding open source is that it could benefit competitors.. Definitely understandable that there is only so much time and funding. No pressure just wondering the current state. Wish I was in a position to sponsor personally.
Yea it’s a lot of work and difficult (not impossible) to land with a moving main branch in spare time. There is landing it in the main branch and then improving performance since you are now in JS and async.
If I did it again I would follow the storage options that SQLite uses in the browser and also use Missionary. A big part of why it took so long to do the clojurescript support was errors got swallowed by core async. Core async is also the primary suspect for the performance issues. Arguably Promesa could be faster but would make it harder to reason about and make future possible features like partial query evaluation / materialised views harder to implement.
Also to answer the question the current state is as it is in the same state as it was in the preview. Which is able to be played with but not usable in any meaningful way and also not compatible with Datahike current.