Make configuring topology more flexible

[bkielbasa]

Ou our RabbitMQ, we have topologies with 2 exchanges and we use routing keys to route the messages between exchanges/queues.

The problem we are facing is that we cannot configure 2 topologies currently. The fix adds a builder which can be easily replaced with a custom one.

There are no breaking changes.

[roblaszczak]

what do you think about adding exchangeDeclarer DeclareExchange(channel *amqp.Channel, exchangeName string) error) ? to the interface?

[bkielbasa]

yeah, definitely good idea

[roblaszczak]

I think that it will be a good idea to make it public (may be useful for example for Dependency Injection)

[roblaszczak]

buildTopology can be also public :)

[roblaszczak]

maybe using Config to pass builder (with defaultBuilder default value) may be a cleaner way? and it will be also backward compatible and more consistent with the rest of the code

[roblaszczak]

in that case probably it will be a better idea to pass Config to buildTopology method

[bkielbasa]

the problem with this solution is that:

• while creating the topologyBuilder I don't have the config yet

func NewDurablePubSubConfig(amqpURI string, generateQueueName QueueNameGenerator) Config {
	config := Config{
		Connection: ConnectionConfig{
			AmqpURI: amqpURI,
		},

		Marshaler: DefaultMarshaler{},

		Exchange: ExchangeConfig{
			GenerateName: func(topic string) string {
				return topic
			},
			Type:    "fanout",
			Durable: true,
		},
		Queue: QueueConfig{
			GenerateName: generateQueueName,
			Durable:      true,
		},
		QueueBind: QueueBindConfig{
			GenerateRoutingKey: func(topic string) string {
				return ""
			},
		},
		Publish: PublishConfig{
			GenerateRoutingKey: func(topic string) string {
				return ""
			},
		},
		Consume: ConsumeConfig{
			Qos: QosConfig{
				PrefetchCount: 1,
			},
		},
	}
	
	config.TopologyBuilder = DefaultTopologyBuilder{
		config:config,
	}
	
	return config
}

I'm not sure if it's a clearer way :) you decide

and the second is that I don't have the logger there so we have two options:

• add the logger separately (everyone who uses ex NewDurablePubSubConfig will have to add the logger)
• remove the logger from buildTopology but we'll lose some logs
• add logger to method NewDurablePubSubConfig

if we choose the last option, maybe it's a good idea (in next step) to have separate configuration for every topology?

WDYT?

[roblaszczak]

I think that we can pass config and logger as the argument to DeclareExchange function, it will become pretty long but I think that here it will be not a problem because it will be not often used and all params types are different so it will be no problem with confused

[bkielbasa]

@roblaszczak thanks for merging! Can you create the tag as before? :P

[roblaszczak]

done, thanks again! 👍