Do you see a need for webhook (Reverse API) management solution ?

Webhooks are gaining popularity & no wonder the need for reverse APIs.

  • Do you think they will become mainstream for Server2Server notifications ?
  • Do you see a need for cloud solution which manages your event webhooks, handles scale, visibility, triggering all webhooks callbacks using a single API call fired on an event to the webhook management platform ?
Solved Solved
1 5 940
2 ACCEPTED SOLUTIONS

Webhooks are already mainstream!

A platform dedicated to managing webhook subscriptions might be nice. For now it is not too difficult to build such a thing in BaaS + Edge. The way I see it working:

  • sending server invokes an API on Edge proxy
  • API proxy does a lookup in BaaS for the named webhook, gets a collection of subscribed URLs
  • API proxy performs GET / POST to each of the subscribed URLs

Do we need things like audits and analysis of whether the webhook calls succeeded? I don't know. Maybe YAGNI.

View solution in original post

Not applicable

Good question @Anil Sagar. I think webhooks enable real or near real-time integration of decoupled APIs/systems that in the past it was just too difficult.That being said, when we're talking about webhooks, we're just talking about event/message-driven architecture (EDA), which requires careful consideration regarding reliability and complexity. Here some thoughts:

  • How critical is the operation of webhooks for your business? Mission critical? Then you need to think more about providing the right infrastructure to support expected reliability. i.e. implementing messaging queues. If the business can afford the eventual loss of messages, maybe putting more safeguards are just overkill, perhaps not. It is important to calculate these risks to measure the level of effort to implement this functionality. Fortunately, all the infrastructure required to achieve desired reliability is available from most cloud providers.
  • If reliability is a concern, on the implementation side, you'll also need to consider what happens when webhooks fail to deliver a message to a consumer API/system?
    • Will it support retries? If so, how often? How long?
    • Or will you allow external systems to reply requests?
    • How will you scale this infrastructure?
    • Make sure webhooks don't impact the regular flow of your APIs. Make sure it doesn't impact latency, for instance, ensure that webhooks execute in a fire-and-forget fashion.
  • On usability side
    • How will you manage subscribers to webhooks? Self-Service?

For more details about the implementation of a webhook facade, we created a sample Node.js webhook API Proxy that sits on top of the Management API. It also implements some pub/sub features.

Hope it helps!

View solution in original post

5 REPLIES 5

Interesting to think about. I have been looking at setting up webhooks similarly to clients for my APIs, so I suppose I have been managing this already, in a way. When supply a URL for a webhook I create an app for that in Edge and include the API key in the URL. I haven't been concerned about that at scale, but I think the model would work.

Webhooks are already mainstream!

A platform dedicated to managing webhook subscriptions might be nice. For now it is not too difficult to build such a thing in BaaS + Edge. The way I see it working:

  • sending server invokes an API on Edge proxy
  • API proxy does a lookup in BaaS for the named webhook, gets a collection of subscribed URLs
  • API proxy performs GET / POST to each of the subscribed URLs

Do we need things like audits and analysis of whether the webhook calls succeeded? I don't know. Maybe YAGNI.

Completely agree with you @Dino , Myself & @Grandhi Srinivasulu discussed exactly same. Interested to hear some of the solid use cases related to server2sever notifications.

Not applicable

Good question @Anil Sagar. I think webhooks enable real or near real-time integration of decoupled APIs/systems that in the past it was just too difficult.That being said, when we're talking about webhooks, we're just talking about event/message-driven architecture (EDA), which requires careful consideration regarding reliability and complexity. Here some thoughts:

  • How critical is the operation of webhooks for your business? Mission critical? Then you need to think more about providing the right infrastructure to support expected reliability. i.e. implementing messaging queues. If the business can afford the eventual loss of messages, maybe putting more safeguards are just overkill, perhaps not. It is important to calculate these risks to measure the level of effort to implement this functionality. Fortunately, all the infrastructure required to achieve desired reliability is available from most cloud providers.
  • If reliability is a concern, on the implementation side, you'll also need to consider what happens when webhooks fail to deliver a message to a consumer API/system?
    • Will it support retries? If so, how often? How long?
    • Or will you allow external systems to reply requests?
    • How will you scale this infrastructure?
    • Make sure webhooks don't impact the regular flow of your APIs. Make sure it doesn't impact latency, for instance, ensure that webhooks execute in a fire-and-forget fashion.
  • On usability side
    • How will you manage subscribers to webhooks? Self-Service?

For more details about the implementation of a webhook facade, we created a sample Node.js webhook API Proxy that sits on top of the Management API. It also implements some pub/sub features.

Hope it helps!

Great Points @Diego Zuluaga , Have you come across any business / use cases where webhooks reliability / mission critical / Usability matters & see a need for them ?