Event-based systems are always nuanced. Generic message design for future flexibility or narrow scope to prioritise known requirements now.
With subscription filters, you can get a bit of both.
What are subscription filters?
Subscription filters are a mechanism in sailhouse to only care about specific events for a given subscription. When it comes to sending events, Sailhouse will check the shape of the event sent to see if it should be included for that subscription.
[[subscription]]
slug = "new-pro-user-notification"
topic = "new-users"
[subscriptions.filter]
path = "type"
value = "pro"Effectively, they’re a declarative filter for your events. It cuts down on the potential noise from a subscription, and you can keep a generic topic scope if you need while fulfilling a basic requirement now.
Why not just filter in the application?
It saves on execution. A push subscription here will only be called when there is a match, reducing the number of HTTP calls to a given endpoint. For pull subscriptions, it reduces the number of events you’re pulling down. Saving bandwith, outbound acknowledgement for no-op events and removing the need for you to add boilerplate checks for events you’re recieving.
This lowers cost, allowing you to architect in a way where you get the benefits of a narrow-scope and the flexibility of generic events.
Use cases
Oh where to begin, some highlights:
- High-volume events where you have a large number of subscriptions (e.g.
new-users) - Allows implementation of small, isolated features without big up-stream changes to optimise cost/performance
- A/B Testing and gradual roll out
The opportunity to filter in the event-layer gives huge technical freedom to teams of any size. A small solo engineer doesn’t have to think about the overheads of generic messaging while larger teams benefit from the autonomy given to each team by listening to what they need.