Elixir OTP behaviours for building RabbitMQ consumers and publishers with reduced boilerplate.
GenRMQ is an Elixir library that provides OTP-compliant behaviours for building RabbitMQ consumers and publishers. It simplifies the process of creating and managing RabbitMQ connections, queues, and error handling, reducing the boilerplate code typically required for message queue integrations. The library includes built-in support for dead-letter exchanges, telemetry, and test utilities.
Elixir developers building distributed systems or microservices that require reliable message queue communication with RabbitMQ. It is particularly useful for teams needing standardized, maintainable patterns for consumer and publisher implementations.
Developers choose GenRMQ because it encapsulates best practices for RabbitMQ integration in Elixir, offering a structured, OTP-friendly approach that minimizes manual setup and error-prone code. Its built-in features like automatic reconnection, dead-letter handling, and telemetry make it a robust choice for production systems.
Elixir AMQP consumer and publisher behaviours
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Implements consumers and publishers as GenServers, ensuring seamless integration with Elixir's OTP ecosystem, as shown in the Consumer and Publisher behaviours with automatic reconnection.
Provides configurable dead-letter exchange setup out of the box, reducing boilerplate for robust error management, evident in the consumer init options for error queues.
Emits telemetry events for both consumers and publishers, enabling easy monitoring and observability, as documented in GenRMQ.Consumer.Telemetry and Publisher.Telemetry.
Includes RabbitCase for testing RabbitMQ interactions in a controlled environment, simplifying test setups, as demonstrated in the example test file.
Relies on the underlying AMQP Elixir client, so any bugs or limitations in AMQP directly impact GenRMQ, and updates might be tied to AMQP's release cycle.
The init callback for consumers has numerous options (e.g., prefetch_count, retry_delay_function), which can be overwhelming and require careful tuning, as noted in the documentation.
Has a history of migrations like version 4.0.0, requiring code updates and potentially disrupting existing deployments, as highlighted in the migration guides.