Fork me on GitHub
Norman Kabir13:03:07

I'm trying to improve my understanding of the cardinality between base and project. I read the discussions above but was not able to crystalize it into a heuristic: Library: external third-party dependencies via deps.edn Component: domain and support logic; may depend on other components and libraries. Base: Exposes an api via a main function or network socket (cli main or server main). May depend on other components and libraries. Does not depend on other bases. Executed from within REPL. Project: Depends on a (single?) base. Packages a base into an uberjar. The uberjar may be deployed onto file system, lambda, k8s, etc. Contains no domain code. May contain packaging code/scripts? Now consider a command-line utility like built with 1. Would the Git subcommands be separate bases? 2. Or would the entire Git application be a base? 3. Or is it simply an implementation detail? Also, is there a public git repository for the documentation where we could issue pull requests with suggestions and edits?

Braden Shepherdson13:03:08

by "like git" I take it you mean a collection of many separate binaries, rather than a single binary? from first principles, each such command would be implemented by a base paired with a project. using git as an example, all the logic for actually working with repositories, commits, refs and the rest would live in a bunch of components. the base for each command would simply convert between the CLI interface and calls to those components.

Norman Kabir13:03:17

So a project would then package together the collection of bases? 1 project, many bases? Sorry--missed the first part about the paring one base to one project. Is it still possible to replicate the git command/subcommand structure within Polylith? Or would that be done outside the workspace?

Braden Shepherdson13:03:26

no, a project is generally a single base and several components. a project packages up a base (and its dependencies) for deployment.

Braden Shepherdson13:03:17

certainly it's possible. why can't you have a dozen base+project pairs?

Norman Kabir13:03:45

Each project produces its own uberjar, correct? So, for example, three subcommands would generate three uberjars. How are these three uberjars combined to replicate the command/subcommand structure?

Braden Shepherdson14:03:11

the central command (`git`) calls each of them, through the shell.

Norman Kabir14:03:42

Got it! Thank you for the clarification!

Braden Shepherdson14:03:21

if you want them "combined" into a single jar, then we're not really talking about git's style. rather we're talking about a single binary with lots of different subcommands. that would be one project, one base, that's pretty thin and just calls through to a bunch of components that do the real work.

Braden Shepherdson14:03:36

(the power of polylith comes from being able to have both of those approaches coexist, and share 98% of their code in the form of the components.)

👍 2

While it might not make a practical difference, the idea is that base does not depend on components; it depends on interfaces. It is the project that then decides that which components are included to implement those interfaces


So you can start from a project, where the functionality of a component is implemented by a local function call, but then introduce an alternative deployment (a new project), where the same base is used without modifications, but the component is switched to one that actually does remote calls to an external service. The reasons for doing that can be anything; dev/test vs production, monolith vs microservice or lambda, testing a new version

Norman Kabir16:03:10

There are intriguing parallels between Polylith and

🧠 1

That’s interesting! I’ve been doing Zettelkasten for almost a year now (I’m up to 2500 notes), and Furkan’s startup is building a 🙂

Norman Kabir16:03:23

I have joined the waitlist! A flat namespace of atomic {components|notes} with {dependencies|references}. The {app|article|book} emerges as the end result of the flat namespace rather than an initial goal. Both are elegant bottom-up approaches. Another tool that I've incorporated into this workflow (actually asked @U2BDZ9JG3 to enable PDF generation for the Polylith Gitbook so I could import the PDF) is (No personal affiliation).


I actually never thought about it in that way! Let me know if you are willing to try Scrintal.

Norman Kabir12:03:46

@U2BDZ9JG3 I would love to try Scrintal! I signed up for the waiting list using <mailto:[email protected]|[email protected]>


Awesome! I’ll DM you further information!