This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
No, bases and components do not add each other as dependencies. They are added to the projects’ deps.edn.
Bases are the exception, they are allowed to access other bases, which you ned to be able to if you have more than one base in a project. But most of the time, one base is enough per project.
Yes, but you do not specify them in the deps.edn as dependencies. They are added to the projects’ deps.edn.
Yes, that's true.
The question was about if bases should reference components (or bases) in their deps.edn. The answer to that is no.
Why is this exactly? I'd naturally put something infrastructurey (like a shared http routing component) in the bases that need it. Adding to a project feels like a leaky abstraction
The base code refers to the component interface namespace, but which concrete component to use, that's a decision that is taken by the project.
it’s like how you would refer to library slf4j-api and not logback-classic or log4j2 , but in this case there’s no api jar , just impl jars
this really makes me wonder how (1) if it’s possible to define compile/link time interfaces analogous to slf4j-api and (2) other kinds of ‘link time’ abstractions
for example if you wrote the interface file once instead of just once per implementing component and found a way to link them up , (autogenerate function bodies)
Let's say you were creating an component interface to ring-handler, and you had two implementations, one that's dev-time-only, it does a reloading requires each time you handle an HTTP request, and another that's production-grade. That's two different components right? that's the intention of polylith?
Yes, it’s one of the concepts in Polylith. Each component has an interface and several components can implement the same interface. These components can then be included in different projects; e.g. one in development project, the other in the production.
There is a detailed explanation of this concept https://polylith.gitbook.io/poly/workflow/profile.
@U0J3J79FE I've blogged about swappable component implementations like this in my monorepo series on http://corfield.org -- e.g., our http-client interface is mostly implemented via an http-client-hato component, but we also have an httpkit-backed implementation for our legacy app that has to still run on JDK 8.