A base is the entry point to a project from the outside. You can include business logic in the base or use it as a pass-through interface for one or more components. A REST API and its endpoints could be entry points. A process initiated from a base to poll from a queue could also be an entry point. We have two separate worker projects at work in addition to our REST API project. The base for REST API is simple; it pulls routes from several components, initiates a handler, and exposes it to the outside. The bases for workers are even more straightforward; they each call a function from a component that starts polling from their respective queues. It looks something like this:

(ns top-ns.foo-worker-base.core
  (:require [top-ns.foo.interface :as foo]))

(foo/listen!)

(ns top-ns.bar-worker-base.core
  (:require [top-ns.bar.interface :as bar]
            [top-ns.baz.interface :as baz]))

;; This worker listens to two queues maybe :)
(bar/listen!)
(baz/listen!)

(ns top-ns.staging-base.core
  (:require [top-ns.rest-api-base.core]
            [top-ns.foo-worker-base.core]
            [top-ns.bar-worker-base.core]))

Ah I think I follow, thanks. My first instinct was to create foo-worker, bar-worker, baz-worker projects which which then start with a generic worker base but each would pass in their own specific worker component. So instead of foo-worker-base and bar-worker-base it'd be just worker-base but it would be given foo, bar components respectively.

by deps you mean tools.deps, or the clojure cli suite?

or something else?

Tools.deps

Though a lot of that functionality is made easy to access through the cli right?

that's my experience yes

Afaik the main purpose of tools.deps and the cli is to start from a dep list and arrive at a classpath or a process with that classpath

polylith is in a different space altogether

To me polylith is a set of conventions, practices and related tooling that helps managing multiple deployables from a single source tree, promoting code reuse between those deployables

the tooling uses tools.deps among other libs

and it mainly uses tools.deps for what that offers: creating classpaths

@U0DJ4T5U1 have you read my series of blog posts about our monorepo at work and how we migrated to Polylith? That talks about some of the problems we ran into early on and how Polylith solved several problems for us...

This is the first article (pre-Polylith): https://corfield.org/blog/2021/02/23/deps-edn-monorepo/

@U04V70XH6 I tried reading them a long while ago.

TL;DR: Incremental testing and building, swappable implementations of components; improved focus on naming of reusable code; discoverability of code...

I would be happy to have just one of those elaborated upon. What is getting in the way of incremental testing and what is polylith that it's generically solving that issue?

I'm going to watch your talk next on my walk btw. So i can come back in an hour.;)

Polylith calculates what components need to be tested based on what code has changed since your last commit, or stable tag, or whatever you want.

(so it only tests what needs to be tested in CI, for example, and we only build the artifacts that Polylith tells us have changed... which saves us a lot of time and uploading since we have over 20 projects in our monorepo)

Thanks that gives me some idea. For context, our backed is in one repo, and currently builds into several deployable services each with their own git branch. The setup makes it too easy to forget to update some shared dependency. And for git conflicts to be handed to a dev who doesn't understand them. So I'm looking to break things down and build them back up again.

My first step is trying to get any namespaces that aren't specific to a deployable target into a library via a deps.edn then just import it via local/root

in our case we had a biiig pile of code that was hard to reason about. Using polylith we started splitting it into smaller independent components and bases that have less code and are easier to reason with. It also allows us to evolve legacy code by adding a new base / project in the same repo that we can build from scratch and pull in components as it grows. This wasy we can keep the legacy code as is and add a replacement until we can switch them over. This is doable without polylith but it's not as direct and natural.

Yeah, a good monorepo setup can remove a lot of friction from moving code around, encouraging cleanup efforts