Currently, the workers lack node.js support to be a real serverless provider. While it is possible to use webworker to run some packages, any native code parts (eg crypto, fs) won’t run.
So when can we expect to use real node.js code for a real serverless deployment? Is it currently planned or out of reach?
I’ve worked only on CF Workers for many months now and it’s made me a much better developer. With less code comes less complexity and having to think more about the design of the applications, with the added benefit of much higher performance and less bugs.
With improvements in the Key-value-database and (possibly) worker-queues, there will not be much that we cannot create.
I am aware of that, that’s why I asked - so there isn’t any plan to extend it to a NodeJs stack? Having to program all tools from scratch because you don’t want to support it doesn’t appear very user-friendly to me, even though it is understandable from an architecture standpoint. It works for a “you can script small things for your website”, but not for the serverless direction Cloudflare wants to go.
It actually is - feel free to try programming crypto in native JS yourself. You can find the official nodejs-crypto library here that is audited and tested: https://github.com/apowers313/fido2-lib
Otherwise you need to re-program, test, audit and maintain it yourself, which is simply not feasible, considering there are dozens of existing node implementations already.
I have actually done that and built in Auth with cookies, JWT, sessions, hashing and even request signing with the web crypto. Was it easy? No… but is it possible? Yes. And it’s a reliable API that’s well documented.
I know that this decision was a good one for most use cases, but as mentioned there are some that require different decisions - costs to maintain a separate crypto project are in a different ballpark compared to a few seconds for a cold start, especially for pages with less volume.
While I understand that you do not plan to use NodeJs stack in a full way, is it planned or can be evaluated to optionally offer NodeJs opt-in workers?
Tell me once you have Fido2 ported to webcrypto in a secure way - I’ll buy you a beer
Didn’t know that, that’s great to hear! Is that documented somewhere?
This is incorrect. The runtime still counts CPU time executing the WebCrypto implementation. It’s far more efficient than native JS implementations, but if you do many heavyweight operations (like PBKDF2 key derivation) in the context of a single request, you’ll start seeing requests fail with an 1102.