3 ms·
https://www.windmill.dev/docs/misc/benchmarks/aws_lambda https://www.windmill.dev/docs/misc/benchmarks/aws_lambda I did not realize at first glance you can wri
by MuffinFlavored 3y ago
https://www.windmill.dev/docs/misc/benchmarks/aws_lambda https://www.windmill.dev/docs/misc/benchmarks/aws_lambda
I did not realize at first glance you can write a script and then trigger it (with an API key, not sure if you can make a public one or if that's a security nightmare) through HTTP to basically have your own self-hosted AWS Lambda / the whole "serverless HTTP triggers/functions" craze
- rubenfiszel 3y agoYes absolutely, we're even faster than lambda with dedicated workers since the design is simpler, while loop jobs from the queue while still keeping all the error handling, observability, and easy deployment.
- MuffinFlavored 3y agoIs there a workaround I'm missing where the URLs are exposed without needing an API key? (Something I'm pretty sure Lambda allows if you configure it properly)
- slig 3y agoNot natively, one workaround is using a simple CF worker that proxies the request.
- rubenfiszel 3y agoThe api keys can be generated to be webhook specific (that's what they are by default when you generate them in the script's UX) and hence can be made public so there is no risk to expose them publicly, they are similar to a uuid of a lambda (not a key but impossible to guess). We require api key because every request is permissioned and hence we need to know who the script is executed on behalf of. For instance, scripts can fetch secrets/variables but those calls will be permissioned with the permissions of the caller which in this case we get from the webhook specific token.