This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # asami (3)
- # aws (2)
- # babashka (8)
- # beginners (60)
- # biff (3)
- # calva (45)
- # clj-http (3)
- # clj-kondo (19)
- # clojure (50)
- # clojure-europe (23)
- # clojure-nl (8)
- # clojure-spec (4)
- # clojure-uk (3)
- # clojurescript (32)
- # conjure (3)
- # datomic (7)
- # events (2)
- # fulcro (24)
- # graalvm (3)
- # inf-clojure (3)
- # jackdaw (1)
- # lsp (3)
- # malli (8)
- # missionary (14)
- # off-topic (1)
- # polylith (3)
- # portal (11)
- # rewrite-clj (63)
- # shadow-cljs (21)
- # spacemacs (7)
- # tools-build (6)
- # xtdb (4)
oh no, now that Slack's given us free history, everyone will see I still haven't made another release like I projected
I have written a fair amount of the relevant code and am happily using it in my startup. It's on the
dev branch, not that I recommend anyone else use that. "Biff release" is currently item #30 on my todo, out of 31. Few updates on the previous points:
• Still haven't actually used htmx, but still am planning to
• I'll probably leave some of the develop-in-prod stuff (namely, rsync-local-files-to-the-server-and-eval-on-every-write) out of the template because it is a tad brittle, but I'll put it under the Recipes section. I am going to make other changes to the template to facilitate that, though. For example, instead of building a JAR, I'll just have the server use
clj directly (which means you can easily add new files to the production app without needing to rebuild the jar or even restart the process).
biff.xt namespace is done
• Reitit stuff is basically done, though I don't think I've updated the template project accordingly
New bullet points:
• I'm going to add some config options for specifying if the app should be a web server, a worker, or both. So in dev and early-stage prod you can do both, then when needed easily switch prod to use separate web server(s) and worker(s), while still having a single build artifact. (I'm in the middle of doing this with my startup).
• Might be nice to add some convenience code for backing up a standalone XT tx log/doc store to s3 or something to facilitate running in production without paying for managed postgres. I'll probably also add a helper config option to
use-xt for using s3 for the doc store.
• Part of me wants to ditch the whole "biff is split up into 10 separate tiny libraries" thing and just have a single lib, since it adds complexity to managing the code base and the whole thing is only a few thousand lines of code anyway. but... it still would be nice to let people exclude biff's dependencies if they don't need them. :man-shrugging: need to think more about this. (Would it break certain builds/be bad in some other way if we used
requiring-resolve a lot instead of requiring things via
(ns ... like usual? so then you can add exclude dependencies and it'll only break if you try to call a function that needs one of the excluded deps)
• I'd like to play around with google cloud run, which I've heard lots of good things about on HN, and see how the experience/cost compares to plain VPSes on digitalocean
• I'll move the docs from http://biff.findka.com to http://biffweb.com since I'm no longer using the Findka brand, which was an umbrella for several different projects I built while I tried to figure out something that would actually work as a business. (I've settled on http://thesample.ai now).
Speaking of the business, it's doing fairly well (~$1k/month). I wrote https://thesample.ai/blog/10k-subscriptions/ recently. If I can bring that up a level or two further, Biff should have plenty of development/resources behind it indefinitely. In the short term, Biff releases will continue to be few and far between while I focus on growing the startup.
(Didn't get into YC, but we did get the "you were in the top 10% of applications we rejected, definitely try again next time lol" email)
Thanks for the update, Jacob. It's great to get caught up on what you've been working on.