[Feature] Webhooks service

[hrdwdmrbl]

I would love a service that allows for subscribe, unsubscribe, list subscriptions for clients and reliable sending & retrying events for servers.

Some clients prefer a polling-style service (GET /events.json?since=2022-09-28+15%3A02%3A59+%2B0200) where they can fetch events at their own pace.

[hrdwdmrbl]

Some more:

• /events with long-polling would be great!
• Automatically remove subscriptions after N retry failures
• Receiver should be able to validate the message using HMAC signatures from the sender

[asim]

How are these events produced? Assuming if it's a webhook service that there's an endpoint where events are sent?

[hrdwdmrbl]

I imagine 3 parties: a client consumer, a server producer and the webhook microservice between them.

Example: e-commerce website

Channels: orders/create, orders/update, orders/shipped

Consumers: Subscribe to the channels they are interested in

Producer: The e-commerce website lets the webhook service know (creates an event) each time an order was created, updated or shipped.

Webhook service: Let's all subscribed consumers know about the event.

[asim]

I think what you're talking about in general is a message queue or stream of events not exclusive to webhooks. We have an event service for this. https://github.com/micro/services/tree/master/event

[hrdwdmrbl]

@asim Oh yeah, I'm aware of the event service. I am talking about a webhook service. You can think of webhooks like a specialized message service though. It's just like, events received in a certain way or style.

[asim]

I'd be interested to see what a complete API for webhook service looks like. Definitely something that we should include.

[hrdwdmrbl]

Here is an example for Webhook consumers https://shopify.dev/api/admin-rest/2022-07/resources/webhook

I don't have an example of a producer API though. I googled and found this though: https://api.svix.com/docs#tag/Message/operation/create_message_api_v1_app__app_id__msg__post

[asim]

Do you have a specific use case in mind for this? I think its better built when needed as opposed to just for the sake of building it. Likely the use case will help inform the design.

[hrdwdmrbl]

Only a bad experience at a company that chose to invest far too much time and resources creating yet another webhook service. :)

At this time I am only a webhook consumer of Shopify's API I reference. Though as https://hookdeck.com/ demonstrates and I can personally attest to, reliably receiving all webhooks that are sent is not as easy as it sounds :) So perhaps a dedicated webhook consumer (middleman) service would also be valuable. Up until now I only had in mind a webhook dispatching sending service.

[asim]

I welcome a webhook service contribution. I think personally it's a little bit beyond my capabilities at this moment.