Con la filosofia 1RTT di Discourse, penso che potrebbe essere il momento di riscrivere il codice di gestione delle immagini Avatar.
Le immagini Avatar dovrebbero essere trattate come qualsiasi altro caricamento di immagini. Ridimensionate al caricamento, archiviate e servite direttamente dal file system/S3/CDN.
Il metodo attuale di Discourse utilizza un metodo proxy per servire le immagini Avatar. Questo approccio crea viaggi di andata e ritorno HTTP non necessari e sfide relative agli indirizzi IP.
Ecco una panoramica delle richieste Avatar:
Viene visualizzata l’HTML iniziale di Discourse.
Il browser rileva un’immagine avatar e richiede un’immagine dal server Discourse
Il server Discourse agisce come proxy e richiede l’immagine dallo store locale/S3/CDN
Il server Discourse riceve l’immagine
Il server Discourse invia l’immagine al browser.
Ogni avatar personalizzato ha 1 viaggio di andata e ritorno HTTP aggiuntivo e il relativo tempo di elaborazione del server. Un tipico argomento o elenco di argomenti può avere più di 30 immagini avatar personalizzate. Sul mio sito, ciò si traduce in 10.000-20.000 RTT aggiuntivi e relativo carico del server al giorno che potrebbero essere evitati.
Inoltre, le immagini avatar vengono chiamate direttamente dal server. Per ottenere qualsiasi protezione a livello di CDN è necessaria la whitelist dell’indirizzo IP. Ciò richiede la whitelist dei gateway anziché degli indirizzi IP del server. Le società di hosting apportano regolarmente modifiche per bilanciare il traffico di rete. Il mio indirizzo IP del gateway cambierà/evolverà. Il software non dovrebbe dipendere dall’aggiornamento dell’indirizzo IP affinché le immagini avatar di base funzionino. Ciò si basa sul seguente incidente nel supporto, Avatar Proxy and CDN Hot-Link Protection
Da una prospettiva di prestazioni e semplicità, possiamo avere le immagini avatar servite direttamente dallo store di file designato di Discourse?
Questa è davvero una parte molto complicata dell’app @LotusJeff.
Per affrontare alcune delle sue carenze, abbiamo recentemente sviluppato un modo per ridurre questi viaggi a vuoto nel nostro hosting, ma non credo che l’abbiamo mai documentato qui. Ci sono documenti pubblici a riguardo @david?
Sì, abbiamo questa GlobalSetting, che puoi abilitare impostando la variabile d’ambiente DISCOURSE_REDIRECT_AVATAR_REQUESTS=true
Quindi, invece di fare il proxy, le richieste di avatar verranno servite con un reindirizzamento 302 allo store dei file.
Di per sé… non è una buona idea. Significa che i browser devono effettuare due viaggi di andata e ritorno HTTP completi per ogni avatar. Quindi, anche se potrebbe risolvere il tuo problema di “protezione dall’hotlinking”… non ti consiglio di abilitarlo. Renderà l’esperienza peggiore per i tuoi utenti.
Utilizziamo l’impostazione sul nostro hosting discourse.org. Ma la integriamo con una lambda in esecuzione sul nostro CDN Cloudfront. Rileva il 302 ed esegue il proxying da sola. In sostanza: spostiamo il proxying dai nostri server applicativi al CDN.
Per quanto riguarda la domanda più generale “possiamo cambiare gli avatar in modo che puntino direttamente all’asset”. È complicato perché gli URL degli avatar sono incorporati in tutti i post storici (ad esempio, le citazioni). Gli URL dinamici /user-avatar/ ci consentono di mantenerli funzionanti quando un utente cambia il proprio avatar. Temo che non abbiamo in programma di cambiare quel sistema.
Se esiste un modo semplice e a basso rischio per far funzionare il proxying esistente per il tuo caso d’uso (ad esempio, aggiungere una GlobalSetting che inserisce un’intestazione HTTP specifica in qualsiasi richiesta di proxy di avatar), allora potremmo considerare di accettare una PR per la modifica.
Nessuna delle opzioni sopra menzionate è fattibile o preferita nel mio ambiente attuale. Mi piacerebbe aiutare a risolvere questa parte complicata dell’applicazione, ma sono molto nuovo in questa stack tecnologica.
L’unico aiuto che posso offrire ora è usando le mie vecchie competenze di BA e Gestione dello Sviluppo. Quindi, nello spirito di sentirsi utile, ecco i miei pensieri.
Quando affronto un problema tecnico, esamino prima le possibili ipotesi che renderebbero una soluzione più difficile.
Una ipotesi è salvare un’immagine avatar aggiornata come un nuovo nome di file. La persona ha solo un avatar. Non teniamo traccia dei nomi degli avatar. Suggerirei che, quando una persona aggiorna la sua immagine avatar, questa venga salvata usando lo stesso nome di file dell’avatar esistente. Questo è fondamentalmente ciò che fa il link /user-avatar/. Invece di avere una soluzione alternativa, applica questa logica durante la creazione/aggiornamento dell’avatar. Questo risolverebbe le preoccupazioni dei post storici per i futuri post “baked”.
Chiedere un cambiamento radicale? No, questa modifica potrebbe essere implementata nel corso di mesi, migliorando lentamente le prestazioni del sito. Le mie squadre di sviluppo avevano sempre una lista di codice opportunistica per ogni blocco di codice. Volevamo apportare queste migliorie, ma non erano critiche e non si facevano singolarmente. Quando il codice veniva aperto per altri motivi, lo sviluppatore apportava anche modifiche opportunistiche. Questo riduceva i test e gli errori, perché si apriva e si aggiornava il codice meno volte.
Suddividerei questo progetto nelle seguenti fasi:
Aggiornare la logica di salvataggio dell’immagine avatar per sostituire eventuali aggiornamenti usando l’attuale nome di file.
Sostituire tutti gli usi delle immagini avatar con una funzione standard che utilizza il sistema di archiviazione/consegna file preferito di Discourse. Queste potrebbero essere implementate nel tempo, passando lentamente alla nuova logica di presentazione dell’avatar.
Una volta completati i primi due punti, fornire alla community i passaggi e gli esempi di codice per cambiare e rinnovare le immagini avatar storiche integrate in HTML baked al filesystem preferito. Questo sarebbe a discrezione dei proprietari dei vari siti Discourse. (Le istruzioni e gli snippet di codice sarebbero utili per effettuare modifiche HTML semplici)
Sono sicuro che anche tu abbia considerato tutto ciò. So anche che correggere il codice più vecchio non è mai una priorità.
Se c’è qualcosa in cui posso essere utile in questo sforzo, fammelo sapere.
PS. Apprezzo l’offerta di un PR per una impostazione globale dell’intestazione. Lasciami fare ulteriori ricerche e ti fornirò requisiti più definiti. Grazie per il tuo aiuto.
Sfortunatamente, se il file è mutabile, ciò significherebbe che non potremo più abilitare la memorizzazione nella cache infinita dell’asset nella CDN e nei browser degli utenti finali.
Esistono strategie per far funzionare qualcosa del genere senza compromettere troppo le prestazioni… ad esempio, la direttiva stale-while-revalidate. Ma ciò comporta costi e implicazioni UX propri.