graphql-engine: Allow Relationship Data to be Used in Triggers

Came looking for something similar… subscribed! ✔

Bump +1

Yea, almost at every trigger i require related data. It will be cool to have object relation data at event trigger

Thank you everyone for the request and comments for this feature. We would like to inform you that this is on our roadmap but we do not have a timeline at present. Please continue to follow this Github issue. We plan to publish on this issue a detailed RFC that covers all use cases and limitations of the feature. We welcome more detailed feedback from you once we provide those details.

Any news from this feature? I also think sending a lot of separate request to Hasura only to get the relationships data is not a performant way for most scenario. Maybe a flag setting in event definition page to enable/disable relationship data in payload can be useful for a lot of use-cases.

Our use-case for this is sending notifications to users. Our system tracks a series of “ticket” type records that users can have open, these tickets go through workflows and often change, with updates being pushed to the user.

Currently when a “ticket” changes, we have to receive that change as a webhook in a microservice, make another GraphQL call back to Hasura to get things like:

• Related user
• Related users contact details
• Related users notification preferences.

Effectively this doubles the back-end load for every change as an additional entire round-trip GraphQL call needs to be made. Ideally we could just get all this related data in the original webhook request.

Note: Our app includes 4 different types of entities that all require similar-ish behaviour to this, but with mildly different relational data for each. So we actually have to implement this 4x times.

We should define optional graphql query for a event trigger to query related data from different tables. This graphql query would run before event transform.

I think we can do 1).

2) has the following nuances:

i) You can’t insert, update or delete ANY view natively (only simple views)

ii) A nicer abstraction would be to trigger a webhook when the underlying table changes though this is impossible to detect via a view because it is not materialized. So, the workaround is to have the underlying table(s) as a trigger and then query your view in the webhook.

One of the biggest concern for having relationship data in event trigger is how do you reason about consistency in an async system.

E.g. Say, you send a payload with a table and its relationship. Before the event is processed by the webhook, the relationship gets modified. Now, when your webhook is processing the data, should it or should it not check for the current state of the relationship before execution?

This is why the most “consistent” (in the ACID sense) pattern for event trigger is to use it as a notification system when a model changes (with its primary, unique keys). And fetch the required state in the execution. This is obviously not needed if your data is static or can be reasoned about in other ways.

That is why it would help if people interested in this feature can tell the exact use-case/application they are trying to build (hence I have tagged it as triage/0-needs-info).

Great feature to have. Subscribed.

In the interest of keeping this from becoming stale. I encountered this today and it would be a great feature to have!

I now stumbled upon same issue in my usecase (grabbing users name). Are there any updates for this?

Bump +1

This feature would save me a lot of custom endpoints, bumping

For now I think it is @tcaraccia . This discussion is about avoiding to have to call back hasura for something you wish you knew beforehand 😉

This is an interesting problem!

I can appreciate the reticence based on concerns for atomic behaviour in transactions. But having landed in this issue after suffering a similar problem, I can also see the use case!

We are left with three options:

1. avoid the use of related fields: leads to a degraded user experience
2. use a webhook’s function invocation to spawn a reactive query: a heavyweight and slow solution IMO
3. allow relational fields in the webhook event payload: some compromise over data validity

My use case is this: I want to send an email to a user when a new row appears in the session table. This table has a location_uuid fk field to the location table. So in the email we want to say:

Hello ${event.data.new.uploader_email}!
Your assets from ${event.data.new.location.display_name} are ready to collect!

Does that make seem a valid and clear use case?

I’m really keen to see how this moves along.