I’ve read the docs on Scenario Inputs.
I can see how from an authoring perspective this would be a more user-friendly approach for invoking sub-scenarios and passing params. Are there any performance gains associated with doing it this way though? Security implications?
I wrote up a tutorial over the weekend showing how to break up a monolithic Make workflow into modular components using the HTTP Req/Webhook method but I would love to know if this carries a performance penalty doing it that way. I believe there are agility/interoperability advantages of using the HTTP/Webhook approach but have no semblance of the performance hit. Scenario Inputs seem to be a Pro feature so I’m unable to benchmark it myself and curious if anyone has compared apples-to-apples with any load testing to see how both perform side-by-side. TIA
Welcome to the Make community!
One possible issue with HTTP → Webhooks method is the uptime of the webhook system on the Make server. If the webhook server receiving those requests are down for any reason, your scenario will need to retry (using a break handler on the HTTP module).
This is an issue as there have been intermittent webhook issues on Make recently over the past few months.
1 Like
Thanks @samliew this is interesting. So basically there’s more surface area for things to fail with Webhooks - like a separate listener process that can be down independent of the workers that process the scenario nodes themselves.
Reading about the Break Error Handler now. Helpful to know- thank you.