Redrafting to add support for persistent storage (KV) for workers and resolve conflicts.

It seems that this approach is not compatible with short-living workers or serverless functions:

• You can, of course, use Workers KV, but reads on it will probably be quite expensive.
• Also, when using serverless functions insead of workers, you cannot use KV bindings directly and have to rely on KV over HTTP, which doesn't have low latency benefit. There also seems to be a bug in Unstorage with KV over HTTP driver where it simply doesn't read nor store anything.
• Using Redis could've been possible, but establishing connections may also get expensive and suboptimal.

So it seems there is no good solution to this problem, expect for directly contacting API to fetch tags and homepage projects, but this may be taxing on the API if no proper caching is implemented for these endpoints, there is also no /homepage API endpoint at this time.

Closing this pull request. Hopefully some better solution comes up in the future to replace the re-deployment hack.

Reopening as according to Geo KV won't cost much. I have implemented KV support for Cloudflare and Vercel, below are steps to set it up properly. If cache is not set up then it falls back to in-memory storage that is not persistent in workers. Additional persistent storage drivers should be relatively easy to add, check out Unstorage documentation for the list of all storage options and custom storage driver implementation steps.

Additionally also implemented a cached overlay driver that will store KV response in memory for the lifespan of a worker to prevent excessive and stale KV reads. Writes aren't immediately flushed with Cloudflare KV for whatever reason and may return stale data making Nitro re-compute the response and write it back to KV (effectively making caching ineffective), so having a cached overlay somewhat protects against this. #WondersOfModernWebDevelopment

Here's an example app running a similar configuration of KV:
https://github.com/brawaru/nuxt-cf-test-app

Live proof of work:

• Cloudflare Pages
  • https://nuxt-cf-test-app.pages.dev/api/timestamp (10s)
  • https://nuxt-cf-test-app.pages.dev/api/long-timestamp (24h)
• Cloudflare Workers
  • https://nuxt-cf-test-main.alexander-sorokin.workers.dev/api/timestamp (10s)
  • https://nuxt-cf-test-main.alexander-sorokin.workers.dev/api/long-timestamp (24h)
• Vercel
  • https://nuxt-cf-test-app.vercel.app/api/timestamp (10s)
  • https://nuxt-cf-test-app.vercel.app/api/long-timestamp (24h)

Saw merge conflicts, tried to resolve them, but figured why not take the opportunity and decided to re-create this almost from scratch to make it much cleaner and maintainable 👍🏻

Pretty much ready for review

We talked about this internally, and it's probably just better to convert it back to the old way of requesting everything on the client - ever since redis caching was added to the backend, it wouldn't affect performance any more or less than this would, from our understanding.

Addressed the concerns both of you had, @falseresync and @triphora. Reapplied simple strategy and just removed all of the build-time caching as you asked. There's no local caching or anything like that. Now the server will make a request and serve it to client as a payload, the client will refetch it every time homepage or Modrinth app page are open.

Since then I learnt a bit about ISR (Incremental Static Regeneration) which we could've used for the API routes (so they just regenerate every x minutes and in a meanwhile serve the same data to everyone), but Cloudflare Pages and Workers don't support this technology, so it essentially would end up what I made in the first iteration — caching with KV.