Free workers.dev subdomain to play with, curious if anyone has looked into this.
Yes, I have indeed.
I really like the serverless approach of Cloudflare. Specially the ability to use the service worker APIs to cache things like the HTML or even request to the REST API.
But it has some drawbacks that I don’t like:
- Although the service workers APIs they use are standard, no other company is doing serverless this way so far.
- Unlike other serverless services there is a minimum payment of $5 per month.
- As far as I know you must use their DNS service to be able to use their workers.
- You can “host” your server in their workers, but you cannot host your static files. So you need to find another host for your files elsewhere. This means on deploys you must update two different services.
- There’s not an official way to develop workers locally. There’s a library called Cloudworker tho.
Regarding Frontity, I’d love to give support for it but it’s not going to be easy. I’ve investigated if there’s something to make a server works on both Node and CF Workers with the same code but I don’t think it is possible. They are too different.
So my thoughts right now are, if we ever want to give support:
-
Using a different dev command using Cloudworker:
npx frontity dev --worker
– I’m not sure how good Cloudworker is and if it would be appropriate for Frontity development. -
Using a different build step:
npx frontity build --worker.
– This one is easy. -
Server packages must provide code for both Node and Workers (using different entry-points).
– This one is difficult again. We would need to ask the community for workers support in their packages, when the own package developers probably aren’t going to use it and, worse, that solution only works for the service offered by a specific company.
That said, of course if there’s enough interest we will investigate it further and all the feedback about this topic is more than welcomed 
1 Like
Thanks for the great response and insights. I had not been aware that they only host the scripts but no static files but even worse is having to support code specifically for both Node and Workers to be able play nicely together when it’s currently a very new and niche thing does not seem very practical atm. Thx again!
No problem Philip
As I said, I think it’s a very interesting approach to serverless. Let’s see how it evolves.
This interests me very much. I think package devs would generally jump at the opportunity to provide support in their code for this, but for ones who dont, just some kind of warning flag in the output to let site developers know that a particular package isn’t supported with CFW would be sufficient.
If step 2 was relatively easy enough to implement, I could put together a bunch of tutorial documentation and spread the word with devs.
I reckon Cloudflare would love it and help push out the Frontity brand too, they’re hungry for new use cases for workers.
I guess that Frontity’s server is going to be coupled with Koa code. So the most difficult part would be to find a way to make a Koa server work within CFW. So far, I haven’t seen anything like that (Express, Koa, Hapi…) working on CFW.
By the way, I’ve kept in contact with Cloudflare. This is their last answer regarding NodeJS in Cloudflare Workers, from a few weeks ago:
Unfortunately, Workers cannot run Node.js workloads. It’s something we’re looking into support for sometime later this year.
1 Like