Fork me on GitHub

👋 curious, would you find it sensible to use Crux in something like a one-man saas? Or can be the amount of moving parts be overwhelming without a dedicated devops person? (or equivalent experience, which I don't exactly have anyway) the jdbc fallback (vs. kafka, rocksdb) sounds interesting in that regard - one can accept the tradeoff of limited scalability for fewer moving parts, right? Something like postgresql or even h2 sounds easier to manage.


Hi 🙂 have you seen or Biff already? @U7YNGKDHA has been cooking up a one-man SaaS stack on top of Crux for a while now (using crux-jdbc Postgres + Rocks) - I'm not qualified to comment directly on whether it's sensible..but I'm a big fan!


Thanks! Didn't know of those, will have to check them out :)

Steven Deobald14:02:42

@U45T93RA6 As another "one-man SaaS" consumer of Crux myself, I'd be curious what your specific devops concerns are. When you say "moving parts", are you thinking about geographic distribution, backups, failover, or something else?


Two lines of things may concern me: - Crux itself surely is a distributed system (just like Datomic is) which can plausibly involve a greater degree of necessary monitoring, tuning, fire-fighting, etc (that's not an assessment of Crux, which I have barely studied) - The Kafka and Rocksdb also are distributed systems on their own. Generally as an hypothetical one-man-saas I wouldn't want to manage a k8s cluster of hot tech - it's always harder than promised :) I guess that my orignal question boils down to "can I have crux-in-a-box for small apps without excessive complexity or work"


I kind of answered to my own question (as I expressed my views on e.g. k8s management) but I'd appreciate insights specific to Crux


> can I have crux-in-a-box for small apps without excessive complexity or work I think so 🙂 running a single Crux node that uses Rocks for the indexes and say, Postgres, for the tx-log + doc-store is very easy to reason about. Asides from the asynchronous nature of submitting/awaiting, there is no meaningfully distributed system to speak of (unless you cluster Postgres!)

❤️ 6

Or you could use something like Confluent Cloud and not worry about the Kafka part?

👀 3
Steven Deobald20:02:47

@U45T93RA6 This feels like yet again more reason for me to finish the "2 minute startup" how-to. My current project doesn't do anything fancy at all — I have a RocksDB instance for each one of the stores, and thus far it's been working fine. Granted, the data in my case is slow-moving (garden variety django/rails todo-list-scale service) but I do like the phrase crux-in-a-box since that captures the idea nicely.

🚀 3

thank you all! really useful to learn about Crux' offering.

Luis Santos13:02:00

I've been thinking a lot about crux and how it works and I actually think that it is perfectly fine for 1 man startups. Please forgive my gross analogy but, from my point of view, crux is a bit like a stateless application. You can just nuke it and rebuild it from the master state without much effort. You can easily deploy it on AWS with Aurora or DynamoDB as a backend store and not(...ish) worry about the operational aspects of a database. From a operational point of view is no different from operating and monitoring an API. I'm probably oversimplifying but I don't think it is by much.

🙂 6
Jacob O'Bryant17:02:04

yeah, IMO Crux + managed postgres is absolutely fantastic for this use case. it's so nice. very little ops overhead. I'm happy to chat more/answer any questions if you want; I've been using it for findka since last may.

Aleksander Rendtslev16:02:45

Are there any good examples of how to do testing with crux?

Steven Deobald16:02:09

Testing like acceptance tests, integration tests, and e2e tests which are testing with Crux in the flow? Or unit tests which avoid hitting Crux?

Steven Deobald16:02:34

Also, are you wondering more about environmental setup? Or how to write the tests themselves? Or both?

Aleksander Rendtslev16:02:46

Tests that do hit crux. I just want some simple tests to verify that my queries return what I expect them to. So I seed the DB with some data, and query against it.

Aleksander Rendtslev16:02:39

I’ve created a test-db with the inmemory db that seems to do the trick. That’s probably fine. I just couldn’t find any examples of it


^ that's essentially how we do things throughout much of the tests in the repo. These are particularly clear examples (without the indirection of various test fixture namespaces):

Aleksander Rendtslev17:02:37

Neat! Would be nice with that in a quick example. The one thing I was missing was the with-open function. Makes a lot of sense to use that

Steven Deobald20:02:46

@U01DH13SK8E Out of curiosity, if the answer to your question had been in the documentation, where would you expect/hope to find it? We'll be adding a cluster of How-To Guides to the docs soon... would that be the best home for it, in your opinion? (I'd like to make sure we cover this case.)

Aleksander Rendtslev23:02:42

That would probably be the perfect place. A simple Testing topic would be what I’d be looking for. How do I test with Crux? What do you recommend I test? What do you recommend I don’t test?

🙏 3
Steven Deobald23:02:14

Cool beans. We'll make sure that gets included as we're iterating on the How-Tos. Thanks!

Aleksander Rendtslev00:02:46

Thank you for being so responsive in here! It constantly reinforces my confidence in working with your solutions

😊 3