RCurrently, we are using deno as a forked process rather than an integrated lib. The deno project doesn't provide deno as a lib so I forked it: https://crates.io/crates/deno_cli_lib_windmill
I have hope to achieve ultimate performance through this scheme.
Transpiling deno into js at time of saving the script (which is impossible currently since deno doesn't expose that as primitive), and pre-warming v8 isolate in a pool to not have to load them at execution time. Furthermore, we will gain a lot by avoiding a system fork. Will update this thread as I make progress. Goal: naive deno execution under 10ms
I have hope to achieve ultimate performance through this scheme.
Transpiling deno into js at time of saving the script (which is impossible currently since deno doesn't expose that as primitive), and pre-warming v8 isolate in a pool to not have to load them at execution time. Furthermore, we will gain a lot by avoiding a system fork. Will update this thread as I make progress. Goal: naive deno execution under 10ms
SDid you see superbase open source their deno runtime?
https://supabase.com/blog/edge-runtime-self-hosted-deno-functions
Seems relevant, so wanted to share.
https://supabase.com/blog/edge-runtime-self-hosted-deno-functions
Seems relevant, so wanted to share.
RI did, and commented on their hacker news launch post
RIt's for sure interesting, and there is a bit of code that could be shared for the permanent endpoints
RI think long term we could give the option to either package the whole workspace as one http server or just some scripts
SIt's not possible to have the "main worker" live in the server and invoke each deno script. So you do not to invoke deno run?
From a user perspective it's sure is nice if things is standardizes so you know that things are battled tested and you are able to move scripts between services.
From a user perspective it's sure is nice if things is standardizes so you know that things are battled tested and you are able to move scripts between services.
RWhat I had in mind is a deploy function:
It takes a set of script, a snapshot of the resources/variables, and produce a bundle that you can deploy anywhere. And we include a service to deploy it alongside windmill using cloudflare workers or this
It takes a set of script, a snapshot of the resources/variables, and produce a bundle that you can deploy anywhere. And we include a service to deploy it alongside windmill using cloudflare workers or this
ROne open question, what about workflows. It's probably out of scope
RSo I think you'd get the full loop, you prototype within windmill and can use it staight up to a certain point and once you're at the million of req/s you can still keep windmill as the source of truth to bundle and deploy stuff. You wouldn't even need to use the service, the cli can probably do the bundling
RIt's probably a few days of work to come up with this bundler if you only care about deno
SSeems like a good idea. Then you can use windmill for userfacing stuff like apis also. Where you want low ms responds time.
RYes, the full vision is a sort of serverless 2.0 where what matters is to expose the right abstraction as the main function
RThen once we have enough users like supabase, we can build in a lot of directions
Rwindmill for data streaming, etl, low latency, etc
Rbut I think internal tool is for now the right entrypoint
Rbut anyway, I think there are a few middle ground before doing that:
- optimize everything for deno to achieve sub 10ms overhead, including v8 pool and aot transpilation
- allow for a direct mode instead of a queue for deno