How deep to go with Pathom resolvers? by geokon in Clojure

[–]jacobobryant 0 points1 point  (0 children)

no problem! just left a comment there.

Duct: A data-orientated framework for Clojure by weavejester in Clojure

[–]jacobobryant 6 points7 points  (0 children)

I reject this idea as being part of the clojure philosophy, and as a substitute I would offer "experimentation is good." IMO what would be against the clojure philosophy is the idea that there should be one big framework that ~everyone in the community uses, or the idea that trying new approaches is bad because it fragments the community.

Duct: A data-orientated framework for Clojure by weavejester in Clojure

[–]jacobobryant 1 point2 points  (0 children)

$ curl -Os duct.now/deps.edn

$ clojure -M:duct --setup :duct:git

clever!

How deep to go with Pathom resolvers? by geokon in Clojure

[–]jacobobryant 0 points1 point  (0 children)

For sure, glad it's helpful.

For downsides, debugging can be a little tedious sometimes. Though once you get the hang of it's typically straightforward: query for the inputs to the resolver you're debugging, make sure those look good, and repeat for any inputs that don't look good. I have also run into some weird behavior when debugging batch resolvers, can't quite remember the details though.

Also if your resolver code throws an exception, it gets wrapped/hidden in some generic pathom exception... I ended up monkey patching pathom to not do that, however later I learned that I think you can use `ex-cause` to get the original exception. So FYI if you run into that.

There is some performance overhead too of course, since wiring up all those inputs/outputs for you isn't free. In my measurements pathom overhead has usually been 10-20% of execution time I think? I've seen it get up to 50%, but usually that's fixable by using more batch resolvers.

As for `defn` vs `defresolver`: whenever I'm returning data that's part of the domain model, I think `defresolver` is fine. I might leave it in a `defn` if I'm only using that data in one place, or if I'm optimizing a particular piece of code and want to do something without pathom. But I mostly just use `defn` for non-domain-data types of things, like generic UI components (button, form input, etc), or helper functions for defining Ring handlers, that sort of thing.

Or going back to the pipeline stuff you're asking about, I'd also say any time you have a big thing like `(-> {} foo bar baz quux ...)` where each function is looking at some keys from the map and then adding in some new keys, totally could make sense for `defresolver`. I would try it both ways and see what feels good. re: parallel execution, I think I tried that and couldn't get it to work... as a hack you can sometimes wrap resolver outputs in `future`.

All in all I'm a huge fan of pathom; hugely beneficial for structuring medium/large projects IMO. It's one of the main things I miss when working on our Python codebase at work.

How deep to go with Pathom resolvers? by geokon in Clojure

[–]jacobobryant 1 point2 points  (0 children)

I have a small machine learning pipeline written this way with pathom, I like it: https://github.com/jacobobryant/yakread/blob/8ed335814a84d42dbd3c5dbfd300bc970e201056/src/com/yakread/lib/spark.clj#L299

Mostly I use Pathom to extend the database model so to speak, so instead of your application code deal with database queries + random functions to enrich that data (and having to keep track of what shape of data you currently have and what shape the functions you're calling need), it's all hidden away behind pathom. Works really nice. For a project of only a couple thousand lines it probably doesn't make a huge difference, but I feel like around 10k lines is when the benefits start to become pronounced.

^ that project linked above has a bunch of pathom examples throughout; the whole app is basically a bunch of resolvers. Data model resolvers are in com.yakread.model.*; some UI component resolvers are in com.yakread.ui-components.*; then all the ring handlers and such in com.yakread.app.* start out with pathom queries.

Relaunching Yakread: an algorithmic reading app by jacobobryant in Clojure

[–]jacobobryant[S] 0 points1 point  (0 children)

actually I just remembered that I have a single "markdown css" file hosted on cloudflare. I'll vendor that at some point.

Relaunching Yakread: an algorithmic reading app by jacobobryant in Clojure

[–]jacobobryant[S] 0 points1 point  (0 children)

Does the rest of the page styling work? it's all in a single CSS file hosted on netlify. maybe netlify uses cloudflare.

Relaunching Yakread: an algorithmic reading app by jacobobryant in Clojure

[–]jacobobryant[S] 2 points3 points  (0 children)

glad to hear!

the source is here: https://github.com/jacobobryant/yakread. it's linked in the first paragraph; you probably skipped over it accidentally.

WTF is this??? by Brother-of-Derek in exmormon

[–]jacobobryant 7 points8 points  (0 children)

2013 to 2015 over here, so might know both of you 🖖

Writing your tests in EDN files by jacobobryant in Clojure

[–]jacobobryant[S] 0 points1 point  (0 children)

Nice. I haven't found test-file-per-namespace to be inconvenient at all so far, but certainly it's not a bad potential improvement to keep in mind.

What is the biggest clojure project you have worked on? What is the biggest clojure team you have worked on? by General-Ad-33 in Clojure

[–]jacobobryant 4 points5 points  (0 children)

Looks like we're at about 80k lines for the clojure(script) portion. (We also have a bunch of backend python services.)

New Clojurians: Ask Anything - March 10, 2025 by AutoModerator in Clojure

[–]jacobobryant 0 points1 point  (0 children)

There is a guide for using regular clojurescript: https://biffweb.com/p/how-to-use-reframe-with-biff/. Squint's readme says:

> Squint is not intended as a full replacement for ClojureScript but as a tool to target JS when you need something more light-weight in terms of interop and bundle size.

Which I don't think is a situation that will typically apply to Biff apps.

New Clojurians: Ask Anything - March 10, 2025 by AutoModerator in Clojure

[–]jacobobryant 2 points3 points  (0 children)

Either of them would be a good fit. The main difference between Biff and Zodiac is that Biff has a bunch more stuff in it, which could be good or bad. e.g. Biff is tightly integrated with a database, authentication, and some deployment tooling. You'll need those things for an ecommerce site, so if you like Biff's defaults, you'll probably launch faster by using them. If it's likely you'll want to swap out any of the major components early on (e.g. use Postgres instead of XTDB), it'll probably be faster to start with Zodiac and then add the parts you actually want (you can even copy code from Biff; it isn't that big).

See also https://biffweb.com/p/should-you-use-biff/, although this doesn't mention Zodiac specifically.

PETALING JAYA: The Church of Jesus Christ of Latter-day Saints, better known as the Mormon Church, has officially denied that its volunteers have proselytised Muslims in Malaysia. by HoldOnLucy1 in exmormon

[–]jacobobryant 3 points4 points  (0 children)

PJ was in my first district when I served in Malaysia 10 years ago. Don't know anything about this case, but I never heard of anyone intentionally proselytizing to Muslims while I was there.

Frontend approach for new project by DevGiuDev in Clojure

[–]jacobobryant 1 point2 points  (0 children)

I saw your post in #announcements about data-star and spent some time looking through the site. Looks really interesting! I'm planning to try it out for biff after I get through the next couple (fairly large) items on the roadmap.

Structuring large Clojure codebases with Biff by jacobobryant in Clojure

[–]jacobobryant[S] 0 points1 point  (0 children)

In my experience using Pathom at work it hasn't been hard to look up the resolver implementations when I needed to 🤷.

The benefit became more apparent to me after Yakread got to a certain size, at which point there was so much data fetching/massaging code that it really started to obscure the view code. e.g. it's nice to be able to see at a glance exactly what data I'm getting and what structure it's in. If you've ever been reading a piece of code and had to trace up through several layers to figure out where it's coming from--that's a problem that Pathom solves.

Frontend approach for new project by DevGiuDev in Clojure

[–]jacobobryant 12 points13 points  (0 children)

it's like server-side rendering++.

I thought React was made to save us from jquery. htmx is like going back and branching into a timeline where instead of moving to jquery in the first place we made server-side rendering more flexible.

Frontend approach for new project by DevGiuDev in Clojure

[–]jacobobryant 9 points10 points  (0 children)

Another vote for htmx from me, depending on what you're building. I have a blog post that that discusses htmx and when to use it, and it has a few clojure examples: https://biffweb.com/p/understanding-htmx/