🛑 Filter Middleware¶
In event-driven architectures, you often consume from a broad stream of events (like a single Kafka topic) but only want
a specific handler to process a subset of those events. The Filter middleware allows you to conditionally control
whether an event continues down the pipeline.
🚀 Using the Built-in Filter Middleware¶
Dispytch provides a built-in Filter middleware out of the box. It accepts a Callable (like a lambda function) that
evaluates the EventHandlerContext and returns a boolean.
Here is an example of how you might use it to filter events from a Kafka topic, ensuring the handler only executes if the event is specifically a "user_registered" event:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | |
🛠️ Writing Custom Filters for Cleaner Code¶
While the built-in Filter using lambda functions is great for quick, one-off checks, writing
Filter(lambda ctx: ctx.event["type"] == ...) on every single route can quickly become repetitive and clutter your
codebase.
When you know the consistent structure of your events—such as having a standard type key in the payload—you can easily
implement a custom filter middleware to make your handler declarations much cleaner and declarative.
Instead of wrapping a lambda, you create a new class that inherits directly from Middleware and implements the
dispatch method.
Here is how you can write a reusable FilterEventType middleware:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
Now, you can update your handler decorator to use this custom, highly readable middleware instead:
1 2 3 4 5 6 7 8 9 10 | |