Replies: 1 comment 1 reply
-
We have some apps with really big configs. We actually started with the topic etc. living with the producer, but more often we wanted to see all the consumers / producers in the app (e.g. to check the group IDs, topic names etc.) rather than each one individually. We generally have a separate initializer for Deimos so everything is pretty self-contained. I can definitely see benefits either way. I did see the autoload issue in the past, but not often. That can maybe be mitigated by having the producer check the Deimos configuration when it's loading itself (I'm not sure if Ruby actually has a hook for this). One thing I'm a bit concerned about is that you wouldn't want to allow consumers to register themselves (since consumers need to be fully defined before the listener is started) so you end up working with producers and consumers in different ways, which might be confusing. I'm definitely open to a PR that allows both ways of operating. A way of checking/updating Deimos's configuration repository might be able to fit both of them. |
Beta Was this translation helpful? Give feedback.
-
According to the Configuration documentation, you define producers by using
producer do ... end
blocks in theDeimos.configure
block.This is handy at the beginning, but has some drawbacks once the project becomes bigger:
Deimos.configure
block is executed in order for the configuration to be applied. This means the configuration is not applied correctly (e.g.Myproducer.topic
isnil
) if the producer is auto-loaded in a Rails application.Deimos.configure
block grows as well and may become really big!There might be some ways to address both these issues that I'm unaware of, but if that's not the case then here is a couple of ideas on how this could be addressed:
topic
can already be set on the producer itself, but the same doesn't apply to other producer's configs that currently needs to go in theDeimos.configure
block.Deimos.configure
block.Beta Was this translation helpful? Give feedback.
All reactions