Cloudflare Workers compatibility, costs and limits

[lakano]

Hello,

Could you please help me to understood how Vitedge works exactly inside Cloudflare Workers to evaluate the cost and limits?

1. When we decide to save the template and props in the cache, is it saved inside KV store or inside CF cache feature ? The cache feature seems to be free of charge (limited storage to 5GB), but in this case it's seems to be only cached in this PoP. If it's inside the KV store, it's cloned to their ~200 PoP around the world in 60s, but this have a cost on each Read/Write/Delete.

2. If it's KV store, I suppose we always need to paid 1 KV Read operation and if not yet exists, to add 1 KV Write operation ? Or do you save it in multiple keys (eg: one key for template, another key for props) ?

3. For each page on the website with vitedge, this mean this will cost at minimum 1 Worker request + 1 KV Read request, even for simple static files assets ( .css, .svg, robots.txt ... ) or static .html files ?

4. Do you believe it's possible to use vitedge only in fallback after Cloudflare Pages ? Pages is limited to 20.000 files, but this permit to save cost when theses files are requested. So, if a route/file isn't found in Pages, to execute the Worker vitedge to generate it on-the-fly.

5. I've read the Worker have a memory limit of 128MB, so each time we add more plugins/packages to vitedge, this will surely require more and more memory for execute the SSR build, and we also need memory for our own code execution. Do you believe this memory limit could be reach ?
   Our idea in that case, is to have an intermediate step, kind of "vitedge generate templates" to run on our dev machines. The .tpl files should be a simple .html with some {{ var }} replacements ( and some {{ if / else }} logic ). Then in the SSR worker, the works require less memory/time, only regex replacements, and may be if the .tpl doesn't exists, then to load the current SSR system to generate the page.

Thanks in advance for your help :)

[frandiox]

Hello! Sure thing but first of all, Vitedge can also run on Vercel/Netlify or any Node.js environment, in case cost is a problem.
Specifically for CF Workers:

1. Currently it only uses CF cache feature. As you say, I think a page will be rendered once per region and cached separately. However, I think purging the cache on demand can be done globally using the management API. The main reason to use cache is that it is faster and cheaper.

2. Not using KV but just for completion: props and html are cached separately to enable more flexibility (e.g. cache props but render HTML always to change dates, etc).

3. You are correct. Workers always run, even if the request is for a static asset that is found in KV. For example, getting a rendered page will trigger server push for CSS files, which will count as separate requests to the same worker.

4. I've actually asked this in CF discord and they said they plan to allow combining Workers and Pages at some point. Hopefully, we will be able to get static assets from Pages for free, but it entirely depends on CF. The only thing that comes to mind to do this in user-land is having a worker at domain.com and adding a page rule to redirect domain.com/assets/* to CF Pages (I think page rules should run before workers) where you deploy all the static assets generated by Vitedge. There might be rabbit holes there, tho 🤔
   I will definitely explore the combination of Workers + Pages once they release it, and see if it's possible to generate full static routes and move them to Pages.

5. It is 128MB for the free/Bundled plan. I think they raised the limit for the new Workers Unbound but I'm not 100% sure. I haven't seen many stats about memory usage in CF dashboard so unfortunately I can't give you an answer about it. There's this public repo that runs on Vitedge and has good number of dependencies: https://github.com/subhendukundu/cool-bio-analytics . @subhendukundu Did you run into any memory issue?

Generally I would say an app that runs on CDN nodes should be kept as slim as possible for obvious reasons. So pre-compiling templates could probably be a good benefit but I would suggest to do this once you notice the first problems.

Hope it helps!

[lakano]

Thanks @frandiox for all theses clear explanations ! :-)
I have a call meeting with CF tomorrow, so may be I could share here more information about CF Pages + Workers.

About pre-compiling, I think this could be a very good feature, not only for memory limits, but also for SEO, if we can deliver files quicker, it's surely better for SEO.

[frandiox]

@lakano Did you figure out anything after talking to CF?

[lakano]

The person on the phone doesn't have enough knowledge to answer to my questions, so I've sent an email and still waiting their answers, but I'll keep you in touch :)