Fork me on GitHub

Has anyone used polylith with a large number of projects/bricks. I have 40+ deployment artifacts with at least double the amount of bricks. Would polylith be able to handle this. Technically I see no reason why there would be a problem. Practically I think I will run out of screen width when doing a poly libs or poly info.


Yeah, apart from what you mentioned, there shouldn’t be any issues. We do not have that many projects (deployable artifacts) however we have more than 100 bricks at the moment.


@U2BDZ9JG3 how do you use those bricks if you don't have deployable artefacts?


In the doc there is a Q/A on protocols, in the response, the argument that you need a common first argument to dispatch on feels weak. You need to pass a context through the functional interface for any component that relies on some sort of state like a db connection for instance, otherwise, your component is stateful and the interface isn't purely functional? There's been a few conversations around protocols in this channel as well as state management libs/framework. I'm wondering how this Q/A could be updated to present better arguments, and maybe elaborate on the fact that protocols and polylith aren't mutually exclusive?

Question: Why use component interfaces instead of protocols as in Stuart Sierra's component?
Answer: The "problem" with a protocol is that you need a common first argument to dispatch on. With Polylith's purely "functional interface" approach, that's not needed: they are just regular functions. Another difference is that protocols live under the same source directory while component interfaces live in their own source directories together with their components and "come to life" only when they are put together into projects. This apporoach, combined with the monorepo idea, gives an extra level of flexibility compared to protocols.


the interface of a component is meant to be duplicated. its “static linking” like with C headers

(def thing impl/thing)
(def other impl/other


(def thing impl-2/thing)
(def other impl-2/other)


if you want the way an implementation is selected to just be “which brick/dep is on the classpath” then this does that. To do that with protocols as your interface to the component would require something like SPI


What you are saying is one of the more solid arguments that I have seen floating around in this slack, along the fact that protocols and polylith interface aren't mutually exclusive, since you can have an interface and use protocols in the implementation, for instance this is what @U04V70XH6 is doing using stuart.sierra.components with polylith. There is also people that are using protocols eg to use different loggers implementation, a choice that isn't project but context dependent. So what I'm saying is that since that FAQ is one of the places people will look for answers when trying to convince/learn more about polylith, it might be worth updating, replacing the first argument by something along the line of "its not one against the other, one can actually be used with the other" The fact that problem is in quotes and that purely is left out of the quotes when talking about polylith purely "function interface" approach may be intended to signal that it's not a deal-breaker for protocols and that polylith interfaces are not really made or pure functions. In practice it sounds like it's the stronger argument as it is placed first, and it's odd because as I mentioned if you want to keep components stateless you will pass a context as first argument anyway. The second argument feels more compelling although at this point I'm merely starting to understand its value, so I think it might benefit newcomers to develop it a bit more.


@U0DB715GU The FAQ is intended to specifically address the overall question of why Polylith uses functional interfaces for components rather than protocols since it's a question that nearly everyone seems to ask when they first look at Polylith. It's not addressing whether or not you might use protocols within components. If you have suggestions for wordsmithing the answer, you could open an issue on the Polylith repo for folks to look at and the documentation authors can decide whether and/or how to update the website (via GitBook).