Why Are Webhooks Better Than Serverless Extensibility?

Why Are Webhooks Better Than Serverless Extensibility?

Serverless is becoming a popular pattern in the web development world–but it isn’t all sunshine and rainbows. There’s a lot of benefits to be had by simply using webhooks. In this article I’ll show you why webhooks > serverless.

ntan3

Even though I agree at your point about webhooks, I guess in today’s Engineering stack we can’t complain about learning curves and things, so these points are somewhere not holding the priority:

>He has to figure out how your serverless functions work, what hooks are available, etc. This is a high learning curve and requires all of his engineers to have a thorough understanding of your product in order to be productive.
>Because your serverless platform only supports running JavaScript ES5 code at the moment, John’s team of C# engineers are having issues writing their complex application logic in JavaScript which they are not all familiar with.
>John’s team doesn’t have any insight into how your serverless platform is running his code: they can’t figure out how to monitor server resources, how to do proper unit and integration testing, how to look for failures, etc.

You can add these as points that matter at the last :slight_smile:

Randall Degges

Thanks for the comment! It really just boils down to a matter of preference.

I see a lot of people hopping into implementing serverless for their products without really thinking about it: hence the article. Wanted to point out some things to keep in mind.

David Multer

I totally agree that webhooks permit cleaner dependency separation than serverless extensibility. Feels to me like they went one step too far with the serverless excitement. Basically the extensibility approach is promoting a serverless version of the old hook approach. At the same time, I do think implementing webhook consumers using serverless is an awesome approach.