convoy VS smokescreen

Yup. Even DigitalOcean still doesn't have webhooks despite several user requests see here [0]

My business is building a Webhooks Gateway for delivering webhooks at scale - Convoy [1]. We use Convoy Cloud to power Nohooks. The goal is to show what's possible with Convoy so more providers can easily provide webhooks.

[0] https://github.com/digitalocean/api-v2/issues/14

[1] https://github.com/frain-dev/convoy

Speaking with platform engineers at events, in various online communities and even within the Convoy community validated the notion that managing webhooks in production is not always easy and can require a lot of effort. Platform engineers believe strongly in frictionless self-service developer experience, and solving for efficiency to quickly provide business value. Let’s take a look at why some haven't adopted a webhooks gateway such as Convoy to manage webhook events and integrations yet and what we are doing to change that.

If you feel like this article helped you understand Webhooks better! I would be super happy if you could give us a star! And let me also know in the comments ❤️ https://github.com/frain-dev/convoy

This is precisely what Convoy does. See here: https://github.com/frain-dev/convoy. If you have any questions, the team is reachable on Slack here.

My initial reaction would be to use a self-hosted webhook relay (e.g. Convoy) that will queue / retry until my internet is back online. However, I'm a bit hesitant to throw a large dependency in the mix in the name of reliability. My other thought I had was setting up some form of load balancer, that will initially attempt to be a passthrough straight to Discord, and only if that fails, then get a queue / retry software involved?

You should check out getconvoy.io, if you're interested in our cloud platform please reach to us at [email protected]

Also from Stripe

https://github.com/stripe/smokescreen

Smokescreen is a HTTP CONNECT proxy. It proxies most traffic from Stripe to the external world (e.g., webhooks).

Smokescreen restricts which URLs it connects to:

It uses a pre-configured hostname ACL to only allow requests addressed to certain allow-listed hostnames, to ensure that no malicious code is attempting to make requests to unexpected services.

It is built on Elixir/Phoenix with live view and uses https://github.com/stripe/smokescreen and nextdns in the background.

I often need to make a HTTP request to a user supplied URL, but I then need to protect myself from SSRF attacks, such as users supplying URL's to "localhost:3000/protected-thing" etc. SSRF Proxy is hopefully the simplest and quickest way to get protection. Currently there is just a Node SDK but I will generate other languages soon.

It is built on Elixir/Phoenix with live view and uses https://github.com/stripe/smokescreen and nextdns in the background.

Sometimes, webhooks consumers require providers to send webhooks from predefined IP addresses. In this release, Convoy ships with an HTTP connect proxy support to route webhooks traffic through a dedicated egress. With this, we can maintain the IP address of our cluster across all requests. To configure, we deploy mole(our fork of smokescreen) and configure convoy to use this proxy with this environment variable - HTTP_PROXY

Nice. Looking more at it, looks like its a mix of wireguard and smokescreen maybe?

> "https://github.com/stripe/smokescreen"

I don't understand why they built this.

The problem described here is solved by using a firewall. What else is there to it?