To me what stands out a lot in this article is the following:
> . However, with this more robust setup, you would need 4 new services (SQS, S3, a Publisher(s), and a Consumer(s)), just to handle a single webhook safely. This is a lot of new infrastructure, architecture, time, and effort.
I most certainly agree that it is a lot of work, but the issue feels in large self-inflicted because of the use of serverless. If you're using a monolithic setup with erlang or running any kind of queue on the side you are fine. You might need to setup some retry logic and alerts but that is done once.
Also the solution of providing a in-browser IDE sounds terrible, developers wouldn't have access to source control, their own tools nor any kind of ability for local testing. Using zapier or any third-party tool is IMO not worth it if its a serious project.
> If you're using a monolithic setup with erlang or running any kind of queue on the side you are fine. You might need to setup some retry logic and alerts but that is done once.
I could be misunderstanding but I think the argument is
if something/somebody is pushing to your webhook URL, and you are down for whatever moment of time, unless they retry, you lost the message
therefore
that's why you ask the entity pushing the data to your webhook to put it into something that is high availability (like an HTTP frontend to AWS SQS I'm guessing), and then you get around to processing it on your end when you can
Webhooks seem to be the publish/subscriber side of message queues without any of the "acknowledge successful processing of the message" parts defined in standard. 5 different companies pushing 5 different webhooks might all handle timeouts/500 errors/ECONNRESET differently retry wise.
> . However, with this more robust setup, you would need 4 new services (SQS, S3, a Publisher(s), and a Consumer(s)), just to handle a single webhook safely. This is a lot of new infrastructure, architecture, time, and effort.
I most certainly agree that it is a lot of work, but the issue feels in large self-inflicted because of the use of serverless. If you're using a monolithic setup with erlang or running any kind of queue on the side you are fine. You might need to setup some retry logic and alerts but that is done once.
Also the solution of providing a in-browser IDE sounds terrible, developers wouldn't have access to source control, their own tools nor any kind of ability for local testing. Using zapier or any third-party tool is IMO not worth it if its a serious project.