Configuration

← Quick Start | Usage Scenarios →

---

Messenger is configured via a YAML file or programmatically via configuration structures.

The main sections of the configuration and their purpose:

• default_bus is the default message bus name. All messages for which no other bus is specified will be sent and processed via this bus. In the example above, default_bus is set to default.
• buses is a section that defines additional message buses and their parameters. You can declare multiple independent message buses. For each bus, you can set middleware (a chain of intermediaries) through the middleware field. For example:

buses:
  default:
    middleware:
      - logger
      - validator

Here, two middleware are connected for the default bus: logger and validator (they must be registered in the code, see the Middleware section below). If additional middleware is not needed for the bus, you can specify ~ (as in the previous example) to use only the built-in intermediaries.

• transports – transport description section. The key is the name of the transport (any unique name), the value is the transport settings. In v1.0.0, two types of transport are available out of the box:

• amqp: for working with RabbitMQ. Requires you to specify the dsn string for the AMQP connection. You can also specify a retry_strategy (retry strategy) and options. An example of the complete configuration of an AMQP transport:

transports:
  amqp:
    dsn: "amqp://user:pass@rabbit-host:5672/vhost"
    retry_strategy:
      max_retries: 3       # maximum number of retries
      delay: 1s            # basic delay before repeat
      multiplier: 2        # exponential delay multiplier
      max_delay: 10s       # maximum delay between attempts
    options:
      auto_setup: true
      consumer_pool_size: 5   # number of goroutine consumer
      exchange:
        name: messages
        type: topic
        durable: true
      queues:
        default:
          binding_keys: ["messages.#"]
          durable: true

In this example, the amqp transport is configured to resend a message up to 3 times with an exponential increase in the interval (1s, 2s, 4s, ... up to 10s) upon delivery failure. The failure_transport option is not specified here, but it can be set outside the transport section (see below). The consumer_pool_size parameter regulates the number of competitive consumers for this transport. In exchange, the AMQP exchange parameters are set (name, type, and flags durability, auto_delete, etc. In the queues' section, a queue named defaultis defined, which will be declareddurable(non-volatile) and linked to theexchangewith the keymessages.#(i.e. it will receive all messages whose routing key starts withmessages').

• in-memory: Built-in in-memory transport (does not require an external broker). To use this transport, specify dsn: in-memory:// in the configuration. Usually, no special options are required for in-memory transport. Example:

transports:
  memory:
    dsn: "in-memory://"

Such a transport is useful for testing or local message processing without an external broker.

• routing – message routing section. Determines which transport to use to send each type of message. The key is the name of the message type (usually the full name of the type or just the name of the structure), the value is the name of the transport from the transports section. For example:

routing:
  messages.OrderCreatedMessage: amqp
  messages.CacheInvalidationMessage: sync

Here, messages like messages.OrderCreatedMessage will be routed through RabbitMQ, and messages.CacheInvalidationMessage – via sync transport. Important: The type name must match what the Go reflection system sees. Messenger tries to match the type specified in the config with registered handlers. If the name does not match, when building Build() you will get the error “failed to resolve message type ‘X’ in routing configuration”. In this case, make sure that the correct name is specified (including the package, for example `mypkg.MyMessage').

• failure_transport – (optional top-level parameter) the name of the transport to which messages that are not finally delivered after all delays will be sent. If specified, after exhausting the max_retries for transports supporting resending, the message will be redirected to the transport specified in the failure_transport'. This is usually a separate dead letter queue. Make sure that the transport with that name is declared in the transports' section. If failure_transport is not set, messages that are not delivered after all attempts are simply logged as unsuccessful.

To load the configuration, the config.LoadConfig(path) function is used in the code. It reads the YAML file, applies Processors (for example, EnvVarProcessor to replace environment variables) and returns the MessengerConfig structure. You can programmatically change this structure or generate your own if you do not want to use the file. In addition, with the help of Processors, support for default values (via default tags) and environment variables is implemented. For example, you can specify in the config dsn: ${RABBITMQ_DSN} – if EnvVarProcessor is present, this value will be replaced with the contents of the environment variable RABBITMQ_DSN'. The 'cleanenv library is connected for easy linking of the environment and configuration.

---

← Quick Start | Usage Scenarios →