This is awesome! I'm working on a project that will heavily utilize FaaS and I've explored many options. Your combination of "secure and configure via workerd" with "autoscale and orchestrate with fly.io" is really great!
I know it's a POC but just some of my thought's / questions to see if you have any ideas or opinions on them:
- I briefly browsed workerd repo and it doesn't seem like there's an api to load a new worker script file to the existing workerd instance. Which is, i'm guessing, one reason why you're just restarting the whole fly machine to re-fetch the latest zipped resources at boot.
- workerd repo mentions it's currently single-threaded
- i'm wondering how fast workerd itself boots?
- due to ^ those three points I'm wondering if a nice design would be:
- publisher & worker use bullmq and it's sandbox-worker to spawn child process workers running workerd (helps utilize more threads & the bullmq worker code can take the job data input which contains the new user script to bootstrap config at job run). This would be good IF workerd boots fast..
- if workerd doesn't boot fast, and eventually you have many user scripts i can't see any other option than to have a third server that acts as a load-balancer/orchestrator. It would keep state of user scripts and which worker fly machines have told it it can run that script. Could still use a "buffer worker machine" which can "cold-boot" newly published scripts using the bullmq method i mentioned above.
Anyway, this is all really cool just wanted to spitball some ideas!
I know it's a POC but just some of my thought's / questions to see if you have any ideas or opinions on them:
- I briefly browsed workerd repo and it doesn't seem like there's an api to load a new worker script file to the existing workerd instance. Which is, i'm guessing, one reason why you're just restarting the whole fly machine to re-fetch the latest zipped resources at boot. - workerd repo mentions it's currently single-threaded - i'm wondering how fast workerd itself boots? - due to ^ those three points I'm wondering if a nice design would be: - publisher & worker use bullmq and it's sandbox-worker to spawn child process workers running workerd (helps utilize more threads & the bullmq worker code can take the job data input which contains the new user script to bootstrap config at job run). This would be good IF workerd boots fast.. - if workerd doesn't boot fast, and eventually you have many user scripts i can't see any other option than to have a third server that acts as a load-balancer/orchestrator. It would keep state of user scripts and which worker fly machines have told it it can run that script. Could still use a "buffer worker machine" which can "cold-boot" newly published scripts using the bullmq method i mentioned above.
Anyway, this is all really cool just wanted to spitball some ideas!