Fornitura di risorse JS e CSS locali per fallback CDN

Dato che

• Le CDN sono una buona cosa perché possono servire risorse più vicine al client, il client può memorizzarle nella cache e ridurre il carico sul proprio server.
• Nei browser recenti, il caricamento di risorse da server di terze parti non riduce la sicurezza grazie all'integrità delle risorse secondarie (SRI) .
• I CDN potrebbero essere inattivi o bloccati in alcuni Paesi e non sono disponibili durante lo sviluppo offline ¹ .

Penso che sia interessante usare i CDN, ma anche essere pronti a renderli non disponibili. Questo post sul blog offre una buona introduzione a diversi approcci per fornire fallback. Se guardi l' esempio di base , puoi vedere che contiene già un po 'di codice boilerplate per fornire fallback solo per jQuery e Bootstrap, mentre la soluzione preferita suggerisce l'uso di Fallback.js , che sembra essere rimasto in gran parte non mantenuto per l'anno passato . Allo stesso modo, la domanda SO più rilevante per l'argomento riguarda solo la fornitura di un fallback per jQuery.

Tuttavia, nella maggior parte dei progetti del mondo reale, mi aspetterei di avere 5 o più risorse js / css, quindi mi sento come se non dovessi ripetere un po 'di piastra disordinata per fornire fallback per tutti loro. Inoltre, ogni volta che aggiungi o aggiorni una risorsa, ora devi farlo

• Aggiorna il collegamento CDN
• Aggiorna la copia di fallback locale scaricando manualmente o modificando la versione in npm / bower config
• Aggiorna il collegamento al fallback
• Aggiorna l'hash SRI

Mentre nel mondo ideale , mi aspetterei di aggiungere / aggiornare la risorsa in un file di configurazione e fare eseguire automaticamente tutti gli altri passaggi (e quindi eseguire i test per vedere se l'aggiornamento ha interrotto qualcosa).

Esiste già un flusso di lavoro prestabilito per raggiungere questo obiettivo?

Oppure i CDN, e in particolare gli SRI, sono ancora troppo recenti?

O alla maggior parte delle persone semplicemente non interessa fornire fallback per le risorse CDN?

_{1. Anche se potresti avere una build di sviluppo che non si basa su CDN, ma considero anche una forma di fallback, poiché deve anche essere mantenuta.}

Penso che forse fraintendiate come i siti più grandi che potrebbero aver bisogno di questo tipo di resilienza utilizzino i CDN.

non si tratta solo di ospitare jQuery o alcune immagini. La maggior parte del sito sarà ospitata sulla CDN, con solo cose generate dinamicamente come pagine di pagamento o cestini della spesa ospitate sui "webfarm principali"

Anche questi stanno diventando sempre più elaborati localmente con JS e cookie per visualizzare elementi specifici dell'utente senza colpire l'elaborazione lato server.

Se un CDN fallisce e inizi a far passare tutto il traffico al tuo server web, è probabile che cada, altrimenti non hai davvero bisogno del CDN.

Il sito su cui lavoro sulla nostra CDN è diventato sempre più importante per il sito. All'inizio l'abbiamo semplicemente usato per memorizzare nella cache le immagini / CSS / JS. A questo punto disponevamo di una proprietà di configurazione che riscriveva il nome host di queste risorse da www.mysite.com/ a www.cdn.com/, quindi se la CDN fosse diminuita potremmo semplicemente modificare questo valore host o disattivarlo completamente e lasciare gli URL che puntano al nostro server web.

Tuttavia, ora siamo passati alla memorizzazione nella cache delle pagine praticamente intere con contenuti personalizzati caricati tramite AJAX. La nostra CDN è diventata essenziale per il nostro sito e potremmo funzionare senza di essa come i nostri server HTTP. Paghiamo buona parte della nostra CDN in parte a causa della resilienza e delle promesse di tempi di attività di SLA, pertanto impiegare tempo e fatica in fallback sembra una perdita di tempo. Abbiamo un piano DR in atto nel caso in cui ci sia un grosso problema con il nostro provider, ma non è un semplice processo automatizzato e vedremmo un periodo di interruzione mentre migriamo alla nostra CDN di fallback.

Quindi, in risposta alla tua domanda, dipende da quanto sia integrata nel tuo sito la CDN. Se sono solo le tue risorse che stai inserendo nella CDN e supponendo che i tuoi server http possano gestire il carico di pubblicazione di questo contenuto, puoi utilizzare un interruttore di configurazione per essenzialmente accendere o spegnere la CDN. Insieme a uno strumento di monitoraggio è possibile automatizzare l'accensione o lo spegnimento dell'interruttore.

Vedo 3 motivi molto importanti per l'utilizzo di CDN:

1. Ridurre la latenza di rete per gli utenti in regioni distanti. Quando hai un sito web per un pubblico globale, il tuo hosting in Nord America non sembrerebbe veloce per gli utenti in Asia meridionale, specialmente in Cina. La differenza nell'esperienza utente può essere così grande da scoraggiare gli utenti dall'uso del tuo sito. In questo caso la CDN multiregionale sarà essenziale per la tua azienda.

2. Servire il più possibile da risorse altamente disponibili. L'affidabilità è uno dei motivi principali per l'utilizzo di CDN cloud: il traffico viene automaticamente reindirizzato ai nodi disponibili e puoi aggiungere alcune misure aggiuntive per reindirizzare il traffico se l'intera area cloud è inattiva.

3. La CDN è più facile da gestire ed economica rispetto ai server delle applicazioni che offrono contenuti dinamici. Quando devi affrontare i problemi sopra menzionati, è un modo naturale per risparmiare denaro.

Tutto ciò significa che l'obiettivo di CDN è aumentare la disponibilità dei tuoi contenuti per gli utenti finali. Se la CDN non riesce o diventa lenta per qualche motivo, il fallback sul lato client aumenterà in modo significativo il caricamento della pagina, poiché tenterà innanzitutto di ottenere la risorsa non accessibile. La soluzione migliore è avere il design lato server che sostituirà l'URL di base in collegamenti come "{CDN} /js/jquery-version-min.js". Ciò consentirà di reindirizzare il traffico al server delle applicazioni anziché a CDN se il controllo dello stato della CDN fallisce: i client non eseguiranno richieste non necessarie e andranno direttamente al server delle app, che sarebbe il tuo fallback con la soluzione lato client. Ciò risolverà anche il problema delle distribuzioni locali e di gestione temporanea,