Clojurians Log v2

Hello folks, I’m curious if there’s a good to handle indirect dependencies. For instance, I have a state that represents a connection to an SQS queue. In development, I’m using ElasticMQ to act as an SQS interface, and using a state to represent the server. Nothing depends on the namespace, but it must be loaded before SQS.

@wkf: are you looking for a way to specify the order in which these states need to start?

yah

this is something that I don't have an answer for yet :simple_smile: but definitely something we discussed before: i.e. "don't start subscribing events to an event bus, until the bus is started". in case of direct dependencies, this is not a problem, of course, since the compiler shares its intel. But in case of "one off" states, it is not very deterministic. there are 3 ways I currently use to achieve the desired order (for now, until we come up with a better solution): 1. Have namespaces with one offs to be required last in the entry point on the app 2. Use (mount/start-without a b c), and then do (mount/start) 3. If there are only a few states, you can do (mount/start e d a b c)

ahhh, interesting

thanks for the reply, I’ll have to see which strategy works best for me now

#2 usually works great when there are many states to care about..

in my specific case, perhaps it’s better to always have some “queue” state

and just swap it out for an elasticmq backed queue

in development

If I understand your use case correctly there are two questions there: #1 Not connecting to the real ElasticMQ in dev #2 Starting a server before connecting to the queue You can definitely go with swapping the ElasticMQ with a stub, but in case you do need it in development, something like (mount/start-without #'app/elastic-mq) and then (mount/start) will ensure that everything is started before #'app/elastic-mq

so, I use elasticmq only in dev to provide an SQS compatible API

in production, I use SQS

so I think in this case

I can (mount/start #’app/elasticmq) and then (mount/start) the rest of the application

ie, start the queue service

before consumers attempt to connect

ah... "using ElasticMQ to act as an SQS interface" I missed that part :simple_smile:

sure, if you need the queue to start before everything else

peerfect

thanks for the help :simple_smile:

sure, very welcome

depending on how your app is structured there might still be a problem though.. you do have both states defined: * #'app/elasticmq * #'app/realsqs so you might want to do something like: (mount/start #'app/elasticmq) and then (mount/start-with {#'app/realsqs #'app/elasticmq})