📥 EventDispatcher¶
EventDispatcher is Dispytch’s high-level abstraction for consuming events from a message broker
and dispatching them to appropriate handler functions where your domain logic lives — clean,
decoupled, and dependency-injected.
✅ Why do I need it?¶
-
Decoupled event handling:
EventDispatcherconnects your logic to the outside world without mixing transport concerns into your business code. It listens, routes, and invokes handlers—you just write the logic. -
Event validation: With
Event[...]and Pydantic models, your handlers receive structured, validated data. No manual parsing, no ambiguous payloads. -
Built-in dependency injection: Handlers don’t need to do everything. With first-class support for DI, you can split logic into small, testable, reusable functions that plug into the handler automatically.
-
Async execution: Handlers fully support async execution. Whether you're processing 5 events or 5,000,
EventDispatcherdoesn’t block on I/O unless explicitly told to do so. -
Configurable retry logic: Failures happen. With per-handler retry middleware, you decide what’s worth retrying and how persistent to be—without bloating your handler code.
-
Organized routing: With
Router, you can group related handlers by concern, making codebases more maintainable and modular. -
Backend flexible: Support for Kafka, RabbitMQ, and Redis PubSub is built-in. With clearly defined boundaries for custom transport, you can write your own consumer to fit your specific infrastructure needs.
Bottom line: EventDispatcher gives you a clean, scalable, and testable way to react to events across your system.
Without it, you're hand-wiring consumers, parsing raw payloads, and stuffing all your logic into bloated callback
functions.
🧱 Basic Structure¶
1 2 3 4 5 6 | |
Where:
consumeris an instance of a compatible consumer (e.g.KafkaConsumer,RabbitMQConsumeror your own)Tis yourpydanticmodel for the event body.- Decorated handler is auto-wired to the event subscription.
✍️ Example: Setting Up Event Listener¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | |
⚠️ Important:
When using Kafka with EventListener, you must manually start your KafkaConsumer instance.
1 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | |
⚠️ Important:
When using RedisConsumer with EventListener, you should pass the asyncio-compatible Redis client (from redis.asyncio) to the consumer.
⚠️ Notes¶
- Handlers receive the
Event[T]param as your Pydantic model - The event payload must match the Pydantic schema — or decoding will fail.
- Event handling is async, and multiple handlers can run concurrently if you need to limit concurrency (for example, to avoid race conditions) use AsyncLock middleware
🧩 Router¶
Router allows you to organize and register handlers modularly, useful for grouping handlers by concern
✅ Use Cases¶
- Defining a group of related handlers
- Splitting handlers into modules
- Avoiding repetition of middlewares in every decorator
🔧 Setup¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | |
You can register this Router with an EventDispatcher:
1 | |
Behind the scenes, Dispytch will collect all handlers in the group and attach them to the dispatcher.