Manutenzione degli avatar degli utenti

1

Il problema in questione riguarda gli avatar degli utenti che provengono dai loro account sui social media. Quando un utente si iscrive alla nostra app, l'utente utilizzerà il suo account social media e semplicemente salviamo l'URL nell'avatar dell'utente nel nostro database.

Ora stiamo riscontrando un problema perché in un database NoSQL stiamo creando molte copie degli stessi dati, come l'URL dell'avatar dell'utente. C'è un'unica fonte di verità sulle informazioni dell'utente che è il suo record utente nel nostro database. Quindi è abbastanza facile aggiornarlo e rilevare una modifica nell'URL dell'avatar.

La domanda è: qual è il modo migliore per gestire questo cambiamento in tutti gli altri luoghi, ad es. commenti pubblicati dall'utente, ecc. Questo non sarebbe un problema in uno scenario di database relazionale, ma stiamo usando alcuni database NoSQL e gli URL degli avatar degli utenti sono salvati in più posti.

Posso pensare a quattro modi per gestirlo e volevo vedere come altri hanno gestito questo sceglione:

  1. Salviamo l'URL dell'avatar dell'utente in tutte le entità correlate come i commenti, ecc. Quando l'URL avatar cambia, usa semplicemente un processo di back-end per aggiornare l'URL in tutti gli oggetti correlati. Penso che questo approccio darebbe le migliori prestazioni perché usiamo qualunque URL venga fornito con i dati. Non è necessario alcun tipo di elaborazione in tempo reale. Tuttavia, questo approccio può essere molto costoso in termini di manutenzione, ad es. aggiornare centinaia o persino migliaia di entità come gli avatar cambiano.

  2. Un altro modo per gestire ciò è non salvare l'URL dell'avatar utente in nessuna delle entità correlate all'utente diverso dal suo record principale. Quindi prendiamo l'URL dell'avatar dell'utente alla prima richiesta e lo memorizziamo nella cache, diciamo nella cache Redis. Man mano che elaboriamo le richieste nell'applicazione, estraggono semplicemente gli URL degli avatar dalla cache e li colleghiamo alle entità appropriate al volo. Vedo due problemi principali con questo approccio. Innanzitutto, creerà un piccolo ritardo nella gestione delle richieste degli utenti. Ad esempio, se un utente richiede un video con centinaia di commenti sotto di esso, dovrei estrarre gli avatar per tutti gli utenti dalla mia cache e alcuni potrebbero non essere nemmeno memorizzati nella cache quindi dovrei fare una chiamata al database per ottenere i loro avatar e conservarli in cache per un uso futuro. Il secondo problema che vedo con questo è l'uso intensivo della cache, che non sono affatto contro, ma in questo scenario, mi sembra di utilizzare la risorsa più costosa per gestire un requisito così banale.

  3. Un terzo modo è quello di ottenere l'avatar di un utente, ad esempio dal suo accesso social e memorizzare il file localmente. Da quel momento in poi, abbiamo il pieno controllo su quel file e il suo URL non cambierà mai a meno che non lo cambiamo. Tre problemi con questo approccio: il primo problema è che non penso che ci sia un modo per scaricare le immagini dei profili dei social media in quanto non forniscono un collegamento a un file. Il secondo problema è la legalità. Non sono sicuro se avremmo il diritto di scaricare e archiviare un file che appartiene a LinkedIn, Facebook, Google, ecc. Il terzo problema è che quando l'utente cambia il suo avatar nell'account dei social media, l'avatar dell'utente nella nostra app non si aggiornerà automaticamente. Lui / lei avrebbe dovuto gestirlo manualmente. Nemmeno la fine del mondo, ma neanche l'esperienza utente.

  4. Utilizza il servizio gravatar. Conosco solo alcune informazioni di base su questo servizio, quindi non posso dire molto a riguardo. La mia preoccupazione principale è che stiamo utilizzando un'altra risorsa di terze parti su una risorsa di terze parti che complicherà ulteriormente le cose. Inoltre, non sei proprio sicuro di come funzioni gravatar ma cosa succede se l'utente non ha un account gravatar?

Mi piacerebbe vedere come altri hanno gestito questo scenario. Grazie.

P.S. Basandomi su alcuni post che ho letto qua e là, avevo l'impressione che gli URL degli avatar non cambiassero perché i provider di social media avrebbero generato un URL per l'avatar dell'utente che non era il nome del file. Quindi, anche se l'utente cambia il proprio avatar sul proprio account di social media, l'URL non cambierà. Ora so che questo presupposto non è corretto e l'URL di avatar proveniente dai social media cambia. Mi è successo con LinkedIn. Un URL completamente diverso è ora il mio URL di avatar. La cosa divertente è che non ho nemmeno aggiornato la mia immagine del profilo con loro. In qualche modo, LinkedIn ha deciso di restituire un URL diverso alla mia immagine del profilo.

    
posta Sam 04.04.2018 - 18:39
fonte

2 risposte

1

Una delle possibili soluzioni potrebbe essere quella di aggiungere un percorso come link che reindirizza il browser a l'avatar vero e proprio.

Ad esempio, se l'avatar reale è memorizzato su link , il tuo sito web memorizzerà questo URI solo una volta, in users documento, associato all'utente 123 . Ovunque nell'interfaccia utente, ad esempio in tutte le entità come i commenti, l'avatar verrà implementato in questo modo:

<img src="https://example.com/user/123/avatar"alt="..." />

Durante una richiesta HTTP al link , il server carica l'URI salvato e risponde con:

HTTP/1.1 302 Found
Location: https://linkedin.com/avatars/40bd001563085fc35165

che costringerebbe in modo efficace il browser a mostrare l'immagine corretta.

Note:

  • In termini di prestazioni, non ci dovrebbero essere troppi problemi. La richiesta è relativamente veloce da elaborare e utilizza solo la larghezza di banda marginale (diversamente dalle immagini di te stesso)

  • È essenziale utilizzare HTTP 302 e non HTTP 301; altrimenti, gli utenti che hanno cambiato avatar a volte continueranno a vedere il vecchio avatar, probabilmente per un lungo periodo.

  • È possibile implementare una corretta memorizzazione nella cache lato client per impedire al browser di richiedere lo stesso avatar più e più volte (in genere, quando si modifica un avatar, non si sarebbe sorpresi di vedere ancora il vecchio per diversi minuti su alcuni siti).

Nota che se stai riscontrando questa difficoltà con l'avatar, probabilmente avrai lo stesso problema con altre informazioni, a causa di una normalizzazione / denormalizzazione impropria. Mentre alcuni database NoSQL ti incoraggiano a duplicare i dati per rendere le query più veloci e garantire la coerenza dei dati all'interno di un documento, ciò comporta il costo di non poter modificare facilmente i dati sparsi in tutto il database. Pertanto:

  • Assicurati di capire quando duplicare i dati e dove fare riferimento a un singolo pezzo di dati da altri documenti.

  • Se applicabile, fare affidamento su tecniche come quella che ho presentato qui, che consentono di memorizzare una parte di dati una sola volta, senza riferirne direttamente in altri documenti. Ad esempio, su Stack Exchange, la zona che visualizza un utente mostra non solo il nome e l'avatar dell'utente, ma anche i badge, la posizione geografica, il link al sito Web e una firma. Poiché questi dati non sono cruciali per il sito web, possono essere interrogati tramite AJAX dopo il caricamento della pagina, il che significa che una domanda / risposta non ha bisogno di contenere queste informazioni o di collegarle in alcun modo.

risposta data 05.05.2018 - 21:58
fonte
0

Non lo so, se sono un grande aiuto su questo argomento, dal momento che non ho dovuto risolvere questo problema. Ma sembra interessante e - se non ti dispiace - voglio condividere le mie opinioni su questo.

  1. We save user's avatar URL in all related entities such as comments, etc.

Come hai scritto, ha uno svantaggio: quando l'utente cambia il suo avatar, devi correggere ogni singolo documento che l'utente ha mai creato (ultimamente - a seconda di una politica per quanto tempo sei disposto a ospitare l'utente -soddisfare). Supponiamo che tu stia avendo un sito, che è attivo da mezzo decennio e che gli utenti stanno commentando pesantemente, che hai molti URL da correggere.

Quello che potresti fare invece è: su richiesta di una risorsa (ad es. comments ), prendi i dati effettivi per la risorsa (ad esempio commenti su quell'argomento) e in base ai documenti dell'utente e combina il risultato. Come accennato nei commenti, GraphQL potrebbe aiutare - ma non è in ogni caso necessario.

Quindi, invece di informazioni di avatar ridondanti, si memorizzano le informazioni dell'avatar nel documento dell'utente.

  1. Another way to handle this is not to save user avatar URL in any of the entities related to the user other than his/her primary record. We then grab the user's avatar URL on first request and cache it, say in Redis cache. As we process requests in the application, we simply pull their avatar URLs from the cache and link to appropriate entities on the fly.

Questo è il modo in cui vorrei andare. Al login dell'utente, aggiornerei il documento dell'utente contenuto nel sistema.

First, it will create a small delay in managing user requests. If you do it on every request for every user involved, yes. But why do it this way?

For example, if a user requests a video with hundreds of comments under it, I'd have to pull the avatars for all users from my cache and some of them may not even be cached so I'd have to make a database call to get their avatars and cache them for future use.

Seguendo ciò che hai scritto sopra, sì.

Ma potresti farlo in modo un po 'diverso:

Per offrire un'esperienza accattivante, non eseguirai il rendering di ogni commento, ma pronuncerai nei primi 10 o giù di lì. Mentre questi vengono visualizzati e l'utente deve elaborare le informazioni, è possibile attivare le richieste nel back-end per riempire la cache con le informazioni mancanti. Se l'utente raggiunge una posizione di scorrimento che rende necessario per recuperare ulteriori informazioni, la cache si spera pronta a servire le informazioni:. fingere fino a quando si rendono è il mio consiglio qui

È necessario sviluppare una strategia di caching intelligente che aiuta a identificare quali informazioni viene utilizzato con quale frequenza (una sorta di "AutoUpdate" viene attivato ogni volta che un utente accede a, che rinfresca la sua / il suo avatar). Ma non vedo un problema difficile qui.

The second issue I see with this is the heavy use of cache, which I'm not against at all but in this scenario, it feels like I'm using the most expensive resource to manage such a trivial requirement.

Non capisco il tuo punto. Sembra che le persone si lamentino, con così tanta RAM, che viene utilizzata dal sistema operativo; quindi installano "RAM-cleaners" per avere più RAM "libere". Se vuoi conservare questa informazione, devi tenerla da qualche parte.

A third way is to get a user's avatar, say from his/her social login and store the file locally. From that point on, we have full control over that file and its URL will never change unless we change it

Non è diverso da 2?

Second issue is legality. I'm not sure if we'd have the right to download and store a file that belongs to LinkedIn, Facebook, Google, etc.

Non conosco le condizioni. Ma penso che, quando gli utenti hanno acconsentito a fidarsi della tua applicazione e tu abbia la necessità di ottenere una foto avatar, non vedo alcun problema qui. Ma IANAL.

The third issue is that when the user changes his/her avatar in the social media account, user's avatar in our app won't update automatically.

Quindi cosa?

Penso che l'avatar di un utente non sia la parte più cruciale del tuo sistema. La strategia, vorrei usare: aggiornare le informazioni sull'avatar dopo il login dell'utente corrispondente. Finché l'utente non ha effettuato il login (di nuovo) visualizza le informazioni obsolete (chi se ne frega?). Qui non vedo uno stopper.

O se pensi allo scenario di caching (che aggiorna più frequentemente): a meno che le tue informazioni memorizzate nella cache non siano scadute, altre vedranno il vecchio avatar. Ma chi noterà? E ancora: chi si lamenterà?

    
risposta data 05.04.2018 - 14:23
fonte

Leggi altre domande sui tag