Hi. You can search for “Mount” in this channel to see answers from @U2BDZ9JG3, e.g. https://clojurians.slack.com/archives/C013B7MQHJQ/p1645781971003439?thread_ts=1645779670.809589&cid=C013B7MQHJQ thread.

> We have states in several components that fetch configuration from AWS Systems manager when they get initialised But doesn't that couple the component with a specific config? I would expect to pass the config via the interface, probably missing something here.

Each component implementation has their own configuration needs and the other components does not need to know those implementation details. The components uses others via their interfaces, which are simple functions. However, internally that component might use configurations, external services, etc. to provide the functionality specified in the interface. The thing I like about mount is the fact that it resolves different states based on the namespace loading order, which goes well with Polylith. You can just require another interface and if that interface implements a mount state under the hood, it will be initialised anyway.

Thanks for the clarification @U2BDZ9JG3. I do like mount for its simplicity, but it doesn't feel like a good fit for Polylith to me. One of the main selling points is re-usability via components, but I don't see how I can pass config to a defstate via interface so for example creating a generic Datomic component seems not doable with mount?

I guess I could put all the defstate instructions in a base which delegate to component functions to create the db connection etc. :thinking_face:

I mean, I do not see anything in mount that contradicts with Polylith. I’ve been using mount for couple years, together with Polylith, mostly in a Datomic Cloud environment. As I mentioned an another thread, I haven’t worked with other state management libraries, so it’s hard for me to compare or say this one is the best or worst. We use AWS Systems Manager to store all the configuration for different environments. Each component fetch their respective configuration from there (determined via a sub path named same as the interface name) and initialise their state. We never expose the states defined via defstate to outside of the component implementation. If something from the state needs to be accessed from the outside, we expose a function in the components interface in order to provide that functionality. This way, other components does not know how each component that has a state defines and initializes their state. In our local development project, we have utility functions which allows us to switch between different environments without restarting our REPL. It basically stops the mount state, changes the AWS secrets to connect a different environment, starts the mount state again. We also have a special version of this setup for the tests, where instead of fetching config from AWS Systems Manager, it fetches from a local edn file.