>
>
>> > 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)
> > 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.
[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.
