Skip to content
This repository has been archived by the owner on Dec 11, 2023. It is now read-only.

Use all event metadata attributes in trigger filters #216

Open
jmcx opened this issue Jan 11, 2023 · 3 comments
Open

Use all event metadata attributes in trigger filters #216

jmcx opened this issue Jan 11, 2023 · 3 comments

Comments

@jmcx
Copy link

jmcx commented Jan 11, 2023

Example: I'm using Kafka and routing events across different topics. I want to use event types com.myshop.order.new and com.myshop.order.cancelled and i have some filtering logic in place already for this, e.g. those events go to different Kafka topics and are transformed a certain way.

Now I also want to start routing orders depending on their region or category. I'd like to add new CE metadata extensions category and region and then use then in filters.

Solution idea (including ideas from #215): tmctl create trigger --filter "{"suffix": {"extension-category": "books"}}"

@jmcx
Copy link
Author

jmcx commented Jan 12, 2023

As discussed today, my use case is a workaround that would be solved by content-based filtering, so we might hold on on this while we wait for content-based filtering.

@jmcx
Copy link
Author

jmcx commented Jan 12, 2023

I'm finding some solutions by using versioned cloud event types, e.g. "orders-us-electronics-v1", and then "orders-us-electronics-v2"

But this also has me thinking of use cases in which I might want to route events to different places depending on their version. For example, we can route new versions of events to new versions of consumers, but old versions of consumers can keep receiving the previous version of events.

For this being able to filter on an event version metadata attribute would be powerful. So I can subscribe to event type "com.myshop.order.new" and version "v2", without having to modify the event type to "com.myshop.order.new-v1" to achieve this. Again seems to provide extra evolvability.

@jmcx
Copy link
Author

jmcx commented Jan 12, 2023

Adding to previous comment, we could even imagine that a transformation automatically updates the version number of an event. Any routing built on just the event type is not impacted, but those that want to start routing and consuming specific versions of events (e.g. before or after transformation) can create triggers specifically for that.

Even if transformations don't do automatic version updates, I can try to write them in as part of the transformation (but it would be hacky because there isn't an increment / arithmetic function).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant