You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see this as a "bridge" between the two components, so with this idea in mind, why not have the convention that the PG channel is equal to the RMQ entity, where entity is either an exchange or a queue. This is also probably the way users will want to set up things anyway, in order to make it obvious where the PG event will end up in RabbitMQ.
I am not sure if this component should take on the creation of the queue/exchange since this will complicate the code and the config interface, maybe it should just error out (or try to reconnect again) if the entity is not yet created in Rabbit.
Another idea to consider is that you probably want to be able to bridge multiple channels at the same time (each handled by a separate thread)
With this ideas/features in place, the config interface is very simple yet very flexible/powerful
I would like to definitely enforce an exchange, everytime so it creates a layer of indirection and helps for debugging or extension
I am not sure if this component should take on the creation of the queue/exchange since this will complicate the code and the config interface, maybe it should just error out (or try to reconnect again) if the entity is not yet created in Rabbit.
In theory I think every app should create their own exchanges/queues on the broker and they should be removed when no one is publishing/listening on them anymore BUT for the v1 I won't go into that path and let the dev(ops) configure it manually :) so 👍
Another idea to consider is that you probably want to be able to bridge multiple channels at the same time (each handled by a separate thread)
I will prefer to have an instance of the app per channel instead of letting the app handle it itself, since postgresql-to-amqp is so lightweight we can definitely do this (and it will keep the code easy, not complex reconnection feature), the only issue I see will be that it will grow the number of active connection to both PG and the AMQP broker but it's not that big of an issue.
With this ideas/features in place, the config interface is very simple yet very flexible/powerful
I see this as a "bridge" between the two components, so with this idea in mind, why not have the convention that the PG channel is equal to the RMQ entity, where entity is either an exchange or a queue. This is also probably the way users will want to set up things anyway, in order to make it obvious where the PG event will end up in RabbitMQ.
I am not sure if this component should take on the creation of the queue/exchange since this will complicate the code and the config interface, maybe it should just error out (or try to reconnect again) if the entity is not yet created in Rabbit.
Another idea to consider is that you probably want to be able to bridge multiple channels at the same time (each handled by a separate thread)
With this ideas/features in place, the config interface is very simple yet very flexible/powerful
What do you think?
The text was updated successfully, but these errors were encountered: