This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-15
Channels
- # admin-announcements (1)
- # announcements (11)
- # asami (6)
- # aws (26)
- # babashka (17)
- # beginners (119)
- # bristol-clojurians (7)
- # chlorine-clover (2)
- # cider (3)
- # circleci (1)
- # clj-kondo (10)
- # clojure (127)
- # clojure-australia (3)
- # clojure-dusseldorf (5)
- # clojure-europe (135)
- # clojure-france (5)
- # clojure-nl (8)
- # clojure-uk (6)
- # clojurescript (103)
- # clojurewerkz (1)
- # css (2)
- # cursive (5)
- # datalog (5)
- # datomic (36)
- # emacs (3)
- # events (2)
- # figwheel-main (3)
- # fulcro (1)
- # graalvm (3)
- # helix (31)
- # jobs-discuss (4)
- # leiningen (1)
- # london-clojurians (1)
- # malli (17)
- # off-topic (2)
- # parinfer (10)
- # portal (1)
- # re-frame (48)
- # reitit (2)
- # reveal (12)
- # shadow-cljs (3)
- # sql (3)
- # tools-deps (4)
- # vim (4)
- # xtdb (22)
hello juxt folks, is the crux-site repository not public or am I missing something else? Trying to build the documentation site locally, but the GitHub repository http://github.com/juxt/crux-site seems to either be private, or the submodule in .gitmodules
is pointing to the wrong repository
Hi, yep it's private, so trying to build the docs locally won't be possible. Are you trying to add a new page or just update an existing adoc?
no, wanted to add in some unsolicited styling changes, namely implement the media query prefers-color-scheme: dark
so I can read the crux docs at night as well as during the day š
(the media query would look at the users prefered setting for dark/light mode and serve a darker page if the user prefers it, otherwise it'll be just as the site is currently)
ah - good idea, and a generous thought! I'm a big fan of dark modes too š I'll have a chat with the team and see if there's some way to make such a collaboration possible
@UEJ5FMR6K hey, sorry to keep you waiting. If you still want to hack on a dark mode I just pushed this: https://github.com/crux-labs/crux-site-mock (hopefully it's enough! Also we can give you access to the crux-site repo as/when you want to create a PR)
Hey everyone, whatās the general feeling about backend datastores? Weāre running on GCE, managed Kafka and not expecting (stupid-large) scale. What would be your ādefaultā choice for backend store in terms of index, doc store, and log?
Hey š there's definitely a lot of options available if you're prepared to look at the entire GCP landscape. For instance, I think Pub/Sub Lite could make pretty decent low-cost Kafka alternative for Crux. Firestore might also be a good choice for a tx-log if you can tolerate slightly higher transaction latencies. I expect Firestore or Cloud Storage (objects) would work well for a doc-store. For the index-store I think Rocks on Persistent Disk is a reasonable combination. As it happens I was reading last night about how good the latency for Persistent Disk is: https://medium.com/google-cloud/persistent-disks-and-replication-9b9412fd9565
Cloud SQL is probably the easiest thing to get going with though, to avoid writing new doc-store or tx-log modules in the first instance (which isn't hard, but could take a few days)
TIL Pub/Sub Lite retention is unlimited, unlike Pub/Sub. But itās a zonal service, no replication across zones.
It's rather confusing to call it "Lite" when the (implicitly) full-fat version doesn't support unlimited retention
A few notes from when I last thought about Crux on GCP (these are thought experiments, Iāve not attempted to build anything yet): ā¢ Firestore has 2 modes ā āDatastoreā mode is the one intended for server-side access (and has much higher write throughput) ā¢ ānativeā firestore is for if you want to sync it down to a browser or mobile client. has write-throughput limitations. https://cloud.google.com/datastore/docs/firestore-or-datastore. ā¢ Firestore is available with multi-region replication ā I thought that was cool (but you do pay for the increased cost, and latency) https://cloud.google.com/datastore/docs/locations. Itās my understanding thatās strongly consistent replication. ā¢ Cloud Spanner of course also does multi-region replication, but still has a decently-high entry-level cost (I think of it as a price floor) (and maybe has other complexities related to how writes work, but those may have since been resolved ā thereās now some sort of google-created JDBC driver!). ā¢ Cloud Bigtable entry-level cost dropped earlier this year (IIRC). but itās an eventually-consistent datastoreā¦
(final note: my thought experiment started with the assumption that using GCPās native, managed datastore services is a good idea!)
(okay, one more: Unlike S3, GCS is globally strongly consistent for many operations https://cloud.google.com/storage/docs/consistency)
One nice property of firestore is the support for realtime subscriptions.
I wonder if one could use a shared redis instance for the kv store. :thinking_face:
> I wonder if one could use a shared redis instance for the kv store Yep it can definitely work: https://github.com/crux-labs/crux-redis š My measurements showed it as only ~2-3x slower than RocksDB, despite the network hop, but it's a pretty expensive way to store data and there's a hard upper limit of 2^32 keys per zset (which equates to <1B triples) I discussed Redis at some length in the recent showcase https://twitter.com/juxtpro/status/1314612039390842880
I see.
Iām still exploring how crux can be uses in a serverless case. So far my understanding is that you basically need nodes running continously to take advantage of locally stored KV.