-
Notifications
You must be signed in to change notification settings - Fork 155
Remove homepage projects and tags build-time caching #1200
base: master
Are you sure you want to change the base?
Conversation
107d5b7
to
6804d8a
Compare
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:
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 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 Setting up Cloudflare KV (Pages)
Setting up Cloudflare KV (Workers)
Setting up Vercel KV
Here's an example app running a similar configuration of KV: Live proof of work:
|
6804d8a
to
ea585e7
Compare
5395a2c
to
d3f688f
Compare
d3f688f
to
fe32f67
Compare
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. |
fe32f67
to
70663db
Compare
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. |
f390cd9
to
4748502
Compare
Re-building and re-deploying the site every thirty minutes just to update data is very expensive and hurts user experience by constantly blowing out the client's cache without meaningful changes to the bundle. Even ignoring that, hardcoding changing data, even though it would be rebuilt eventually is considered a very bad practice. Overall, this all feels like a terrible hack.
This pull request should address this issue by removing client data generation logic and instead creating the supply logic using Nitro server cached routes that will refresh on the server every thirty minutes unless there's a re-deploy due to actual changes.