This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-08
Channels
- # announcements (7)
- # babashka (44)
- # beginners (162)
- # cider (22)
- # clara (11)
- # clj-kondo (14)
- # cljsrn (8)
- # clojure (91)
- # clojure-dev (24)
- # clojure-europe (6)
- # clojure-france (4)
- # clojure-italy (11)
- # clojure-nl (4)
- # clojure-spec (11)
- # clojure-uk (14)
- # clojurescript (92)
- # community-development (1)
- # core-logic (1)
- # cryogen (1)
- # cursive (6)
- # data-science (3)
- # datahike (3)
- # datomic (32)
- # degree9 (3)
- # dirac (3)
- # emacs (9)
- # eql (1)
- # events (1)
- # find-my-lib (1)
- # fulcro (67)
- # graphql (13)
- # helix (9)
- # jobs (1)
- # jobs-discuss (92)
- # leiningen (31)
- # malli (8)
- # meander (3)
- # news-and-articles (1)
- # off-topic (46)
- # pathom (2)
- # practicalli (1)
- # re-frame (52)
- # reitit (12)
- # shadow-cljs (40)
- # spacemacs (10)
- # sql (4)
- # xtdb (8)
Hi 👋 Firstly I don't think if this will make much sense but I'm going to ask anyway. Can Crux work outside of Clojure world? with things like NodeJS, Elixir or Rust.. Crux seems to a good solution overall which can be more fruitful if it's not limited within everything Clojure. Cross ecosystem support will bring in more adoption and hence more stability/production grade quality.
Hey, yes you can use the REST api to talk to it from anything that can support an HTTP client: https://opencrux.com/docs#restapi
Hey @UJMU98QDC building out interop and support for other languages + ecosystems is absolutely the intention. In the short-term we're already working on SQL and regular JSON APIs. Over the longer term we would like to offer GraphQL and native HTTP clients for various languages. What language/platform are you hoping to use currently?
Thinking loud here: could we bring code to crux, e.g. for in-db authorization or transaction processing? Using SCI or an embedded JS interpreter. :thinking_face:
@U054UD60U embedding a sandboxed interpreter is definitely interesting for tx processing, and we've discussed it a bit in the transaction function issue (which we only closed yesterday!): https://github.com/juxt/crux/issues/121#issuecomment-520563824 JS would probably be the better strategic choice if we do go down that route, but there are no firm plans on what to do with transaction functions next (asides from releasing them for the world to see 🙂) In-db authorization is already on our roadmap but I think we will strongly prefer to keep things declarative, so any kind of Turing-complete interpreter is unlikely.