Sorry, we don't support your browser.  Install a modern browser

Granular Webhooks#36

The ability to define the webhook trigger.

a year ago
2

It would be great to see a payload preview of the webhook based on the type of content that is bring configured to fire the webhook.

a year ago
1

One of the addition that could make sense is to add the ability to configure the webhook trigger’s rule.

Currently, the rule is “one trigger for one content change”, but that doesn’t fit all use cases.

For instance, when handling changes in a batch (like a mass delete, or import script), one could be interested to debounce the triggers, and instead of triggering 100 times (for 100 content changes) only trigger once.

The rule in such case would be “debounce 2000ms at the end”, so that if those 100 changes are made within 2s of each other, they’d be debounced and only one event would be sent once no content change is detected for 2s. (for use-cases such as refreshing a cache, for instance)

Extensive discussion on Slack at https://graphcms.slack.com/archives/C2VP3HAJH/p1565560565203000

Another really handy addition would be to add a few more metadata by default for all webhooks, such as:

  • query name: We have the ability to name our queries with GraphQL. If we can know which query was the origin of a data change, we could do some very workflow-related stuff based on it. It’d definitely be the base of a super flexible webhook handler, because we could know exactly where the query was sent from.
mutation queryNameProvidedToWebHook {
  ...
}
  • source: GraphCMS UI vs API?
    I may want to do something very specific if a delete was made through the GUI, like trigger some other process. Use case could be a follow-up action after deleting an item manually, to clean up data in another service for instance. This could be made configurable through headers for instance, to identify the origin of an API-related operation, and perform an action only when X service made the API request that triggered a content change.
a year ago

After re-reading the discussion and thinking on it, it may be easier to think of this functionality as two pieces: granular Webhooks, and customizable Triggers. Triggers would basically just be logic you can define on top of API events, and Webhooks would be a valid output type. I think that’s easier to develop, easier to build UX around, and easier to explain in docs. For big-scaling, it would also make more sense to have a high-throughput, read-only stream of all API events, where Triggers can then drop actions into a queue when criteria are met.

a year ago
1

It makes sense indeed, it could/should be 2 different features, I’m just not familiar with what “granular webhooks” is supposed to bring to the table (any example?)

in any case, both could be implemented in the next webhook planned update

a year ago

It pretty much revolves around Model based webhooks with a payload in form of a gql query you can specify. Its similar to the setup we had in our legacy platform.

a year ago
Changed the status to
Planned
9 months ago
Changed the status to
In Development
9 months ago
Changed the status to
Completed
7 months ago