-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
persistent cache #30
Comments
For this issue, I would assume the best place to put the cache would be at this function https://github.com/unjs/ipx/blob/main/src/ipx.ts#L72.
If nobody is working on this, I might be able to take a stab at it. |
were you able to do the cache? |
Hello, thank you for an awesome library. Do you plan to release the feature? |
Hi ! Any news on this feature ? |
Hi @pi0 |
Is there any timeframe on this? If it's something that will happen within Q1/2024 we could possibly hold out switching away from IPX in our projects but it would be good to know for planning how far the roadmap this is. |
@bernhardberger It is on my plan. BTW curious how is your setup is it on top of nuxt/niro/h3? |
tbh, no clue - the node process is running supervised by our hosting partner and the nitro server more or less directly exposed to the outside world. There's no reverse proxy involved (that we could have control over) that would do the caching. Our clients and also the higher ups internally want to avoid cloud based solutions at all cost, also because it has a lot of implications regarding compliance etc in the EU with our larger corporate customers. We're trying to move away from monolithic solutions as it would open up more possibilities to share frontend code between different projects and lessen the need to have frontend devs that have backend specific framework knowledge (Laravel, TYPO3, WordPress etc.). Our projects are mostly brand/marketing stuff (MPA, Content driven websites and portals) so going headless is mostly a decision driven by workflow and less by having to have the ability to scale (in which case we'd do SSG). But estimating about 20-30 projects yearly IPX in it's current form is a deal breaker when we had like 10-20 projects per server and now we'd be stuck at like 2 before resources run out 🙈 //Edit: I misread. FE stack is Nuxt3 + some Nitro middlewares for routing+ h3-compression to make Lighthouse stop complaining. SEO stuff unfortunately is the highest priority. PPS: IPX doesn't work properly with SWR in Nuxt3. Delivers Bytestream json instead of images. ISR works. |
hey, any update? maybe persist images like aws-samples/image-optimization could be a good improvement. I'm already using Cloudflare cache to prevent my cpu meltdown, but it's not the ideal. :S if we could store the generated images an use them instead of creating a new one, it should be amazing. |
this is still a major issue preventing us from running SWR on our site.. |
I solved with a middleware implementing this: https://0xacab.org/rbo/site/-/blob/no-masters/server-middleware/ipx.js?ref_type=heads hope it helps |
Thank god for this thread. Otherwise I would have lost another 6weeks to realize my IPX Server has no actual physical storage of the generated files. You restart/rebuild server and everything is gone. PS: also a big issue with current method is cloudflare cannot properly cache these "dynamic optimized urls". |
I guess because in 2024 noone seems to care about self hosting anymore.. except a few poor souls like me/us that have to work in environments where cloud hosting is not an option.. PS: Yes, that's another huge problem that the URLs aren't using unique hashes, so you can't really cache those images "forever." So you can't even properly use a CDN, caching proxy or even cache headers for those images.. Right now, I had to turn away from using IPX and had to implement image processing through server components using either flyimg or custom TYPO3/Statamic/Glide endpoints and hashed, secure URLs to prevent mass resize attacks and get our server resources back to normal.. |
hey guys, the one way was building it my self. I've built my own saving cache into s3 bucket and using varnish cache in front of the service. |
Hi @andrevandal, I think your repository is set to private. 🙃 |
Any update? |
Support abstract persistent cache for both input source and converted images. (implies supporting ttl)
Related: #46
The text was updated successfully, but these errors were encountered: