8 ms·
The SaaS can run your wasm code for you. In this case, you'd write the same code that you'd otherwise run in your infra to respond to the webhook, but it would
by nilslice 3y ago
The SaaS can run your wasm code for you. In this case, you'd write the same code that you'd otherwise run in your infra to respond to the webhook, but it would be compiled to Wasm and run _in the SaaS app_ where the source event was triggered.
In your specific case, you'd still be making a call-out to your system to adjust the entitlements as you describe. However, many cases are actually taking action back on the SaaS side via API calls to the SaaS. So instead of a handful of back-and-forth calls over the Internet between you and SaaS, you just call their functions from the Wasm code running in their infra.
- deleted 3y ago[deleted]
- tonyhb 3y agoSo you have to give your 3rd party providers access to _code you write_, _secrets to your own datastores_, _open firewalls to 3rd parties_, and then allow them to run any code which could access your system, hoping that they do in fact run the blob you upload?
- nilslice 3y agopretty much everything of any level of sophistication require this. unsure what your point is. wouldn't your customers for inngest need to do the same for anything integrated?
- goodoldneon 3y agoNo, Inngest doesn't host your code so it doesn't need your secrets
- nilslice 3y agoyet
- jddj 3y agoI've re-read this a few times to try to grasp the wisdom which the confident contrarian tone makes me suspect is in there. I have to say I couldn't find it. Could you give an example scenario where the status quo would be improved by uploading a wasm handler to a server instead of passing messages?
- nilslice 3y agoLook at the Shopify Functions platform