> AFAIK unlike node, Deno's API is largely promise-based and therefore all unhandled exceptions should become unhandled rejections withou crashing the process - so this should be less of an issue than it is with node
Perhaps you're right, I have not tried this out in Deno-land so I cannot say wether this actually applies to Deno the same way.
I just know that I got burned by this exact issue in node and I think this can be a security issue that people usually don't really think about. If you know that some api is a node api, if you manage to find a bug that is crashing the process one could probably script it to trigger it to crash over and over again. Even if it restarts quickly, usually it takes a second or and in that time one could bring the entire api down.
I am not aware of any instance that this have been used against some api in practice but most other languages handle this much better than node does and the javascript way of crashing on error is one of the things that made me question using javascript for backend services at all.
Regarding the kubernetes... no thanks. I would not go into that beehive unless forced. I didn't like the complexity increase of adding a load balancer and that is like a drop in the ocean of the complexity that is kubernetes.
k8s is not really that complex by default, despite all the complexity hype around it (if you look carefully you'll notice a significant number of the people saying this have a serverless SaaS to sell). You can run something simple such as microk8s on VMs and get better results more quickly than any manually managed process manager and/or load balancer.
You can, of course, make it more complex by piling a ton of stuff on top of it, and most cloud provider offerings do that. But its not required.
Perhaps you're right, I have not tried this out in Deno-land so I cannot say wether this actually applies to Deno the same way.
I just know that I got burned by this exact issue in node and I think this can be a security issue that people usually don't really think about. If you know that some api is a node api, if you manage to find a bug that is crashing the process one could probably script it to trigger it to crash over and over again. Even if it restarts quickly, usually it takes a second or and in that time one could bring the entire api down.
I am not aware of any instance that this have been used against some api in practice but most other languages handle this much better than node does and the javascript way of crashing on error is one of the things that made me question using javascript for backend services at all.
Regarding the kubernetes... no thanks. I would not go into that beehive unless forced. I didn't like the complexity increase of adding a load balancer and that is like a drop in the ocean of the complexity that is kubernetes.