That's why it's not reliant on it. If it gets attacked then that's that, the site is still running, just not in pristine condition. That's about it.
And yeah that can work too, in the app/setting page there'd be:
Title: Caching Server [button: add]:
Subtitle: Official servers:
cahcing.degmods.com [button: unset]
Subtitle: Recommended servers:
caching.example1.com [button: set]
caching.example2.com [button: set]
caching.example3.com [button: set]
Subtitle: Custom/user servers:
input-field [button: add]
caching.exampleCustom.com [button: set]
This can be a nip too, now that I think about it.
Login to reply
Replies (2)
Not sure how they're doing it, but here's how I'll be doing it:
View quoted note →
and
View quoted note →
Didn't do much research, so sprinkle salt on this.
There's local caching on my end, but the user deletes it of course, and ya as you said it's not a good idea to burden the user handle such a thing to have a proper site/app experience.
I'll be doing remote caching, but doing it in a way that it's only to run it in parallel to what's already there, where if my server goes poof, the site/app still functions, just not optimally.
And now after a discussion, it'd evolve into giving the user the ability to changing to different caching servers/services too, or turn it off completely if they want. Here's the previous talk about it:
View quoted note →
and
View quoted note →