Fork me on GitHub
#mount
<
2016-02-01
>
wkf21:02:25

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.

tolitius21:02:48

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

tolitius21:02:40

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)

wkf21:02:31

ahhh, interesting

wkf21:02:41

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

tolitius21:02:46

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

wkf21:02:50

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

wkf21:02:03

and just swap it out for an elasticmq backed queue

wkf21:02:04

in development

tolitius21:02:44

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

wkf21:02:43

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

wkf21:02:51

in production, I use SQS

wkf21:02:05

so I think in this case

wkf21:02:42

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

wkf21:02:16

ie, start the queue service

wkf21:02:20

before consumers attempt to connect

tolitius21:02:32

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

tolitius22:02:09

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

wkf22:02:58

peerfect

wkf22:02:01

thanks for the help simple_smile

tolitius22:02:17

sure, very welcome

tolitius22:02:51

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})