graphql-engine: filters for event triggers or conditional triggers

could we have an update on this

I feel like this becomes particularly interesting with all the latest updates. Between Hasura REST endpoints and transforms in the event payloads, we can do a lot of interesting stuff without needing to spin up anything but Hasura, but conditions would really take that to the next level.

5 years have passed. I think we won’t see this happening 😦

Any update on this please? This feature also saves a lot of resources on the API server by not processing unnecessary events. This becomes significant especially when processing millions of events per day.

I second Raphael’s use cases.

We use update events on tables with a status column to trigger an AWS Lambda. It would be our preference, and a lot more cost effective, to check if the conditions on the row are met locally before calling the webhook. We’d save on a large number of Lambda invocations that don’t do much other than simply determine there is no processing required, then exit.

We may be able to cover some of the scenarios with condition checks by proxying through some edge function middleware before invoking the Lambda. For criteria that checks anything beyond what is in that triggered table row, we would need to perform a secondary lookup however, which would likely take too long in an edge function. Thus it makes a lot more sense to do all of that condition checks in memory on the Hasura server before the webhook is ever invoked.

Features we’d make use of if they were there:

1. Upon update, if any column on the listened to table has any one of a list of constant values, then call the webhook, otherwise fail with skipped status.
2. Upon update, if any column compared to any other column is a match or non-match, then call the webhook, otherwise fail with a skipped status.
3. Upon update, if any value is less than|greater than|equal to a constant or another column value from the triggered table row, then call the webhook, otherwise fail with a skipped status.
4. Upon update, if any column on *related table rows *to the triggered table row has specific values, then call the webhook otherwise fail with skipped status.

Thanks, Rob

On Tue, Dec 20, 2022 at 10:45 AM Raphael Titsworth-Morin < @.***> wrote:

Essentially I think this sort of tooling gives us the beginning of a system to define our own events. Ideally someday we would be able to set a trigger that only runs when a value has changed from A to B, but right now we might have to run every single update to an object through external code.

I think an ideal implementation for me would have two sections: one for the previous state of the object and one for the new state. For insert operations, we would only use the new state section, for delete only the previous state section, and for updates we would use both. Ideally they would both work identically to the permissions definitions, including the ability to traverse relations.

Imagine the following use case. We run a newsletter/blogging platform and want to send out a notification to subscribers of a given author when they publish a post, but only if they have a paid account. We don’t want to call our webhook for every change made to the post, only when its status has changed from unpublished to published, and only if the related author account has a paid account flag set. (ideally we could use date functions, but since we can’t do that in permissions yet, I won’t push it 😂) Only then would the webhook be called.

As I was writing this, I actually had a thought… I think I quite like the idea of defining these conditions as objects called “custom events”, rather than in the triggers themselves. I can imagine situations where multiple webhooks should be called for the same conditions. This would allow that. If they are defined as “custom events” though, I think it would also be useful to define them against each of the db events. i.e. The custom “published” event on the blog post table is triggered when:

• on insert: conditions X are satisfied
• on update: conditions Y are satisfied
• on delete: “off”

Hopefully that’s helpful @rahulagarwal13 https://github.com/rahulagarwal13 🙂

— Reply to this email directly, view it on GitHub https://github.com/hasura/graphql-engine/issues/1241#issuecomment-1359589788, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJSXIFZ5CGMW6JWH2PSOKTWOHH7ZANCNFSM4GLJQZ7A . You are receiving this because you commented.Message ID: @.***>

Essentially I think this sort of tooling gives us the beginning of a system to define our own events. Ideally someday we would be able to set a trigger that only runs when a value has changed from A to B, but right now we might have to run every single update to an object through external code.

I think an ideal implementation for me would have two sections: one for the previous state of the object and one for the new state. For insert operations, we would only use the new state section, for delete only the previous state section, and for updates we would use both. Ideally they would both work identically to the permissions definitions, including the ability to traverse relations.

Imagine the following use case. We run a newsletter/blogging platform and want to send out a notification to subscribers of a given author when they publish a post, but only if they have a paid account. We don’t want to call our webhook for every change made to the post, only when its status has changed from unpublished to published, and only if the related author account has a paid account flag set. (ideally we could use date functions, but since we can’t do that in permissions yet, I won’t push it 😂) Only then would the webhook be called.

As I was writing this, I actually had a thought… I think I quite like the idea of defining these conditions as objects called “custom events”, rather than in the triggers themselves. I can imagine situations where multiple webhooks should be called for the same conditions. This would allow that. If they are defined as “custom events” though, I think it would also be useful to define them against each of the db events. i.e. The custom “published” event on the blog post table is triggered when:

• on insert: conditions X are satisfied
• on update: conditions Y are satisfied
• on delete: “off”

Hopefully that’s helpful @rahulagarwal13 🙂

I have a need for this. Our backend has several mutations that it only needs to be alerted for in the case of a boolean being either true or false. Instead, it gets an alert on updates both ways, which doubles the amount of requests sent between hasura and the microservice for that particular event trigger.

That is exactly what I’m facing. I’m using a trigger to call a lambda for image manipulation, which saves more info in the same row later on. I need to have a flag to avoid recursion, but the lambda still needs to be called twice. If I could move the check to the Hasura sever, I would save half of executions. Must be different ways to accomplish the same result though, but it’s just one use case I wanted to share

@Bessonov Thank you very much i have already tried this many times but i didn´t used conversions so it didn´t work.

Would be nice to have this feature. You can quite easyli do most of them with postgresql triggers it is not hard, but i need user id from the hasura which make this impossible make by just postgresql. The permissions are in hasura greate but make it hard to go around. Hope to atleast show need for this feature.

Try:

CREATE FUNCTION getUserId() RETURNS uuid AS $$
BEGIN
  RETURN (current_setting('hasura.user')::jsonb->>'x-hasura-user-id')::uuid;
END; $$ LANGUAGE plpgsql;

Not sure it will work in your context.

This is really critical. Any update? How far are we with this? This is causing a loop in my application.

I saw the change of label 27 days ago, any update about this?