Clojurians Log v2

I've talked about benefits quite a bit in my monorepo blog post series on https://corfield.org but to summarize: • Incremental testing is a big benefit (with poly test) • The flat components approach provides a consistent structure -- helps you find code more easily, helps you focus on naming and cohesion • The separation of interface from implementation lets you have your "API" in alphabetical order, with docstrings for users of the code; with implementations in "natural" Clojure order and docstrings for developers/maintainers • I think the separation of build/artifact (`projects`) from applications (`bases`) is valuable in terms of organization We started with all our code in one big repo, building multiple applications, and had already run into problems organizing deps.edn files (see the early blog posts for more details on our journey prior to Polylith!)

Polylith isn't really valuable until you are building multiple applications out of a single repo. If you're only building one artifact, there's not as much benefit, since you'd have one bases entry, one projects entry, although you'd get the benefits from the components approach if you split your single app into multiple structured pieces.

Wow. Thanks, for the great response, @seancorfield gratitude When building multiple applications, are there any benefits to Polylith, compared to building One Big Jar with multiple entrypoints, other than keeping the built jar small by only including the necessary code?

"building One Big Jar with multiple entrypoints" -- that's kind of an unusual and specialized approach... At work, we build about two dozen artifacts (JARs) and deploy those across various servers. Our smallest JARs are about 20MB and our largest JARs are about 65MB I think. We have a couple of JARs that have multiple entrypoints but those are mostly batch job processes that run on a schedule, where we also typically run multiple "jobs" each hour, or quarter hour (or day), so those need "all" the related code. All our other apps just have the code they specifically need. Having individual JARs mean you can deploy just the pieces that actually changed -- something that Polylith can figure out for us (via "changed projects"). For example, I just made a small change to one file in a base, and CI ran just the tests for that base and built just that project JAR and deployed it. Nothing else changed and nothing else depended on that change.

I agree with Sean in every aspect. Polylith's mental model is especially good for large projects; its pattern (using interfaces, creating bricks etc) enforce you to design before execution.

I appreciate the engagement. I'm really trying to "get it", but don't see the value proposition (yet). Thanks regardless, though. I'll keep it in mind.

The benefits are clear, I'm just not sure if it outweighs those of a single deps project.