Fork me on GitHub
#biff
<
2022-01-16
>
Jacob O'Bryant21:01:56

I'm starting to/attempting to dedicate Fridays + bits of Saturdays as time allows to Biff. The main impediment has just been justifying spending time on Biff vs. spending more time on the business--however I think Biff is very much in the category of important-but-not-urgent, and I'd like to prioritize it. I've started rewriting the example/template project again, making changes to the Biff libs as I go. A few updates: • I've started using HTMX in the business, and I'm still convinced using it to replace clojurescript is the way to go. This would put Biff in the class of "server-side frameworks with something fancy for still having an interactive frontend", kind of like Phoenix Liveview. • I'm sticking with plain VPSes as the default/recommended deployment solution. Nice and boring. • Re: develop-in-prod: as mentioned previously, for my own projects I've been using a setup where whenever I write to a file, it gets rsynced to the server and then the server re-evals everything. So insta-deploy on write basically. It's awesome, but also slightly edgy and brittle sometimes. I think I've come up with a good compromise for Biff's template project: continue deploying by rsyncing/git pushing files + running with clj (instead of building a jar), but don't auto-deploy on write. Include a soft-deploy command which will git push + eval (so zero downtime and very fast, but won't work if you need to add a lib or change something that happens at startup), and a hard-deploy command which will do a full process restart. Instead of using XTDB's standalone topology as default in prod, have the setup script install postgres on the server and use it for tx-log & doc store. In local dev, include a mode where you can have your local code connect to the prod postgres instance over an ssh tunnel or something. • That also would make some ops tasks pretty convenient: if you're not using a managed postgres instance, you can use whatever the standard tools are for backing up postgres DBs. I'll include something for this in the template. Also it's very easy to populate a dev DB from prod--connect to the prod postgres instance then run some code locally to dump XT's transaction log to a file, then switch to local-only mode and ingest it. • I've decided to combine all the separate biff libs into one. If anyone wants to use part of it without pulling in the other deps, they can always copy+paste. realistically I doubt this will be common. I'll probably stick all the public fns under a com.biffweb namespace (trying to avoid using core), with biff as a recommended alias. I think there'll only be four other namespaces: com.biffweb.impl.{util,middleware,xtdb,extra} , where extra is kind of a dumping ground for helper fns that don't fit elsewhere but don't justify their own namespace. Normally I do a Biff release like every 8 months without any public updates in between. After this release I'd like to continue doing updates regularly. Part of this will be code of course, but I envision doing a lot of documentation/tutorials/example projects etc too. I'm planning to start a Biff newsletter which I'll use as the main channel for Biff announcements/happenings/goings-on, with links to & from this channel for discussion. Part of that would be "I just released/wrote X", but if anyone else releases any projects made with Biff/writes any Biff-related posts, I'll highlight those too. I also tend to have an abundance of project ideas and a non-abundance of time with which to build them, so I'll probably also write posts about my project ideas as suggestions for things to build with Biff. (Many of these will fall in the paradigm described in this post: https://jacobobryant.com/p/messy-future-social-media/) I'd like to help people get enough repeated exposure to Biff so that when they're ready to do a weekend project they think "hey maybe I'll give Biff a try." I also applied to Clojurists Together (their smallest grant, for experimental projects). In the past I haven't applied because I didn't really have any use for the money. However we're now doing a fair amount of paid acquisition in the business, so if I can get money for working on Biff, that'll make it easier for me to justify spending time on it. Hence I'll probably also emphasize github sponsors after next release, which up to this point I had enabled simply because "why not." (Speaking of which, I got a new sponsor a few days ago--normally I email people a thank-you note, but I couldn't find an address for this person, so if you're in here, thanks!)

❤️ 7
🔥 1
Steven Deobald16:01:47

Thanks for the update! Personally, I'm quite excited to see where this goes. 🙂

👌 1
Jacob O'Bryant21:01:48

oh, and one more significant-albeit-tentative plan: I'd like to write a guide/series of posts called "biff your next project one step at a time" or something, which starts you at hello world and then has you add all the other bits one at a time till you have a finished app. basically the/a standard method of learning Clojure web dev but with some more guidance. it'd have you write something yourself, then show you a version of the same thing that biff provides, repeat. or something like that.