Replies: 2 comments 2 replies
-
Hi,
If that is the case, those processes running the strategies need to push the trading signals via a message queue system, and the position management process needs to rebuild the trading signals out of those messages. On the strategy processes side, you could do something as simple as having your strategies push messages to the queue, instead of doing One the other hand, in your position management process, you need to have a loop consuming messages pushed to your queuing system, re-building trading signals out of those, and serving those to the dispatcher via an event source. Take a look at https://basana.readthedocs.io/en/latest/basana.html#basana.Producer for the loop part, and to https://basana.readthedocs.io/en/latest/basana.html#basana.TradingSignalSource. This event source would be the one that your position manager is subscribed to via Let me know if that helps. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the reply. I though about this somewhat further and think the best solution would involve replacing (or adding) the event/queue backend with eg rabbitmq/pika - if that makes sense? Is it easily achievable with current basana architecture? The event components of this is new to me, so would appreciate any light shed on this part |
Beta Was this translation helpful? Give feedback.
-
Hi,
Again - what a great package you've built.
I'm looking into separating the model strategy logic and the position manager logic to run on separate instances. Limited experience with event-based architectures, but understand the natural setup for this would be to use a deployed e.g. RabbitMQ-setup to push and consume the events via.
What would be the natural way to incorporate this into the current Basana-architecture?
Beta Was this translation helpful? Give feedback.
All reactions