I've run into 3 big limitations when using Workers:
1) The CPU limit.
2) Not being able to use Node modules.
3) Not being able to add domains other than adding those to our CF account. SSL for SaaS solves this but, so far, it's only available to enterprise customers.
The CPU limit was not so bad when considering Workers were not intended as a general use-case for serverless functions. Now that this has been lifted I feel the Workers environment limitations are going to be much more important.
You can't, for example, use many Node packages in Workers since these are running in a custom V8 environment which resembles browser service workers. I say "resembles" because the API is not 100% identical. For example, you can use streams, but you don't get the full API.
A different runtime from nodejs is more a feature than an issue. The worker runtime is much closer to deno than to nodejs from a philosophy standpoint and i expect a lot of synergies between cf workers and deno in the future. the cf workers being as much compatible with the service worker api as possible makes them the only faas solution close to a web standard, so vendor lockin will only be an issue until compatible offerings appear. A killer argument for this approach is also that you can be sure you can run the cf worker code also in a browsers service worker (with minimal modification). This allows more flexible architectures and also more unified development between backend and frontend.
Also regarding the domains: cloudflare routes the requests to the edge centers based on dns anycast, so cloudflare workers cannot really be seperated from the dns functionality of cloudflare, see it as a faas offering inside your worldwide distributed dns. If that is not what you want, it is still possible to use cf workers with worker domains and use your own domain and dns setup
ahhh, sorry i did not know "SSL for SaaS" was a product name for a specific feature. I totally agree, this would have been really nice to be able to offer my clients, but is currently not really accessible. There are a few things like this such as custom error page etc. Lets hope more enterprise offerings will be more accessible for smaller projects in the future...
true, cloudflare communicates that extremly well in talks they give about it and online presentations, but the documentation is often not as easy to read
This is a major dealbreaker that it needs to be called out earlier.
Not only is this an interface you adhere to to use their service (incoming event, outgoing response), that type of coupling is fair and expected, but the underlying runtime is custom without full support for standard APIs?! What's the upgrade path? Can they port things over in a reasonable amount of time? Is it well documented what's supported and what isn't? Imagine developing against this and resolving these issues as they come up. Oof.
1) The CPU limit.
2) Not being able to use Node modules.
3) Not being able to add domains other than adding those to our CF account. SSL for SaaS solves this but, so far, it's only available to enterprise customers.
The CPU limit was not so bad when considering Workers were not intended as a general use-case for serverless functions. Now that this has been lifted I feel the Workers environment limitations are going to be much more important.
You can't, for example, use many Node packages in Workers since these are running in a custom V8 environment which resembles browser service workers. I say "resembles" because the API is not 100% identical. For example, you can use streams, but you don't get the full API.