Are you using our SaaS platform (Baserow.io) or self-hosting Baserow?
Self-hosted
What do you need help with?
I’m confused about how the view-related webhooks work. It looks like they trigger when the view itself is created or updated or deleted, which is of such little value that I spent an hour this morning testing them, convinced I was mistaken.
The whole point of views is to have a slice of data, and it makes sense to trigger events when data within the view is updated/added/removed, such as having a record appear within the view because it’s ready for some action to be taken on it. Airtable supports this.
Is Baserow’s implementation really just supposed to fire every time someone changes a filter or adds a sort? (Also, I can’t get it to fire at all, no matter what I do with the view.)
Is Baserow’s implementation really just supposed to fire every time someone changes a filter or adds a sort?
No, it’s supposed to call the webhook every time something happens to the view or the data in the table, such that one or more rows that weren’t visible in the view before become visible.
I just tested both on our SaaS and locally and it’s working as expected. When a row enters the view, the webhook is called with a payload with the same structure of the one shown in the example in the modal.
Which tests have you done? Are you sure the celery-export-worker process is running and processing tasks?
Baserow recently added support for webhooks firing when a row enters or leaves the view, but it’s a paid feature. I’m self-hosting the community version, largely because I can self-host the community version. As soon as I have to consider paid options, then I have to review the value prop between Baserow and Airtable. I’m not willing to pay for this one feature that seems like it should just be included. I understand that you’re a business that needs to make money, but if you already fire webhooks on rows being added/removed from the table, why do I have to pay to fire them on views?
Thank you for the feedback, I’ll share it with the team.
I understand your point and I know it may look like other webhooks, but from a technical point of view, this one requires far more resources because it must fire every time a row enters a view.
Triggering a webhook on row creation is pretty straightforward, it is just a callback to the function that creates the row. This new webhook instead, is marked as advanced because it can fire on many operations or events:
• Creating, editing or deleting rows can bring rows into a view
• Changing view filters can add thousands of rows at once
• Formulas using now() or today() can move rows in or out of a view when recalculated
• Date filters with exact dates may change rows daily, altering which rows match
• And other similar cases
Also, you can enable it on hundreds of views in the same table.
The complexity and compute cost are part of the reason why it is offered as a paid feature.