> On 7 Apr 2016, at 13:42, Jeroen van Dijk <jeroentjevand...@gmail.com> wrote:
>
>
> > The thing that this doc also advocates (and I am against) is manual
> > dependency management, your app start function must call start on its
> > dependencies. This not only hardcodes the dependency, but also requires the
> > user to think about the startup order of components on every usage.
>
> This “every usage” is roughly every time a new component is added (in my
> experience). Of the total number of components, around 80% is added at the
> very beginning and a few more during the lifetime of the app. Last time I had
> the ordering problem with one component I fixed it in the app start function
> and never touched it again. So I’m not sure if the user is required any
> special effort after the very first setup.
>
> At my company we *do* have complicated dependency trees that you really don't
> want to manage manually or even think about. We've build a layer on top of
> Component actually. We use edn config files to declare what components should
> be in the system. The dependencies are calculated accordingly (I hope we can
> open source it some time)
Could you give a couple of examples? I just can’t imagine how bad it can get.
In my case, apart from a bus initialization requiring a couple of components to
be initialized first, everything else is very linear. But of course, I might
just be lucky.
Also, are we using the same definition of component? I tend to identify a
namespace “n" as a component if reloading n or its dependents has the potential
of putting the application in an incongruent state (that is, something that you
can’t possibly reach while the application is running normally). def or defonce
with IO or atoms are usually a good indicator.
> > In addition this approach doesn't support substituting alternate
> > implementations. During testing I often want to use a in-memory queue vs
> > RabbitMQ. Or perhaps I want to wire an entire system up with in-memory
> > queues to perform limited integration testing. Hardcoding dependencies
> > limits the flexibility of the app.
>
> Good point about stubbing out sometimes. But shouldn’t something like
> (with-redefs [bootstrap/system {:rabbit “my stub”}] <test-here>) solve the
> problem easily? As of running the app with a different configuration, you
> could get away by “TESTING=true java -jar target/uberapp.jar” and put a
> conditional in system.clj to wire-up the app with in-memory queues.
>
> With the configuration files for instance, we substitute a Kafka component
> with an in-memory logger component during testing and a file-based logger in
> development. I have also been able to generate a full cluster of 10 nodes of
> the same server component in the same JVM running on 10 different ports. This
> was possible because the configuration is just edn data and we don't have any
> global state in our components [1]. This is also something that wouldn't be
> possible with Mount as this library seems to promote global state.
I don’t know Mount sufficiently to judge, but I’m not promoting global state
either. But there instances where a namespace needs a (def cache (atom [])) for
example. The important thing is that I can control the reload of that “def”
from a centralized place (a very handy one being user/reset).
Renzo
>
> [1] except for the system var of course
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
