Nothing official, although I did hack one together once, so maybe you can do something similar: https://github.com/crux-labs/crux-console/blob/master/src/crux_ui_lib/async_http_client.cljc

Are you writing Lambdas in cljs or something?

It would be good to go direct from cljs to the db, without having an extra layer in between.

You mean from cljs running in a browser? It was certainly nice to be able to do that for that original console prototype, but I'm not sure I can think of other scenarios where exposing your DB directly like that would be a good idea 🙂 what did you have in mind?

Essentially it's just for better compatibility with DataScript tests, since we don't actually support multiple DB input sources you can also safely ignore it

One option that might work is to JSON-ify the Datalog syntax, and then use some kind of visual JSON editor, e,g. http://mb21.github.io/JSONedit/ (found via https://stackoverflow.com/questions/998832/gui-based-or-web-based-json-editor-that-works-like-property-explorer) The main challenge with that is in comprehensively representing non-JSON types like symbols, sets and keywords, but you can use a lightweight nesting abstractions like {"$set": [{"$keyword":"foo"}, {"$string":"bar"}] (in thinking about this before it seems better to treat JSON strings as symbols, and then be explicit about $string to save on string escaping chaos). Or you could use Transit-JSON-Verbose 🙂

@U3X7174KS have you had any other interesting responses or related finds yet?

@U899JBRPF hyperfiddle was mentioned. I'm probably looking for something lighter, though.

Cool, that's interesting to know. Is this for Metabase-like use-cases? Which Datalog backend do you ideally want it for? I built something kind of similar for DataScript once, but never released it - composing queries in a web-based modal text outliner

I have an idea that I can't really get rid of. If we manage to use databases like Datascript client side in a proper way, a lot of frontend complexity would disappear. Datalog queries are a really good way to view data. But it's not something anyone could "just write. If we aim for easiest possible, we could support a subset of Datalog in a really nice to use UI. "only allow happy paths". I suppose there are a few different "easy subsets of Datalog" that it's possible to support.

Good point about metabase. Metabase or Kibana seems like "high complexity buy-ins" to this idea.

Right yeah, I think declarative UI's backed directly by a Datalog database (client/server distinction is somewhat irrelevant) is definitely a great path. Being able to represent and transform a Datalog query as a UI-expressible data structure with Datalog would be a very neat bootstrapping step. Somewhat tangential, but have you seen https://github.com/den1k/root ? I feel like this idea is important also

Nope, I'll take a look :thumbsup:

This is exciting 👀

Thanks for the reference 🙏

@U3X7174KS maybe also check out the fulcro-inspect project it is text based and works on eql, not exactly datalog. But it does have query completion and is somewhat user friendly and might be close in scope? https://github.com/fulcrologic/fulcro-inspect

https://youtu.be/yyVKf2U8YVg?t=2043 shows an example.

@U09MR0T5Y thats a very good point. I watched the video way back, but didn't make the connection then. Thank you!