There are challenges on this model for sure. A big advantage is that, by routing to the dev environments, you can have the dev interact directly with the webhook when they code, instead of having to wait for a shared environment to test integrations. This is pretty useful, specially if your application depends a lot on webhooks for it's main functioning.
This is an area where I'm particularly interested in. We are constantly experimenting in ways to better integrated it into our idea of remote development environments.
> you can have the dev interact directly with the webhook when they code
But how? A webhook needs to call a single endpoint (with a dns/ip pair). How can you route incoming webhooks from a 3rd party vendor to every dev machine running the service locally?
Weird people downvoted my previous comment on this, it's a genuine problem with this "DTAP on your machine" setup, isn't it?
1. Register each dev env with the provider. Dev Envs can have predictable URLs (e.g in okteto cloud it's the name + namespace + domain), so you can directly register it. This works well with self-service webhooks like Github.
2. Have a proxy that routes to the right dev env. This works if there's a key you can use for the routing, like a user ID or the subscription.
3. Have a proxy that duplicates traffic and send it to all the dev envs.
I'm curious wow do you solve this on the DTAP env. Are you registering a single endpoint with the webhook? Then how does it reach the separate dev envs? (or do you have a single, shared dev env?)
