Immagine flessibile REST api con cdn e caching

Question

Immagine flessibile REST api con cdn e caching

#1 da (1 voti)

1

Considera un social network in cui è necessaria una foto utente in diverse risoluzioni large / small / medium ecc.

Quando la foto viene caricata, non voglio che l'utente attenda troppo a lungo per l'immagine da elaborare e i diversi URL per ogni dimensione da restituire.

Voglio solo restituire l'url di base ex domain.com/images/something.jpg Quindi, quando il frontend richiede domain.com/images/something.jpg?s=large, generano l'immagine grande, la memorizzi nel cache e restituiscilo sempre.

Il problema che non riesco a capire con l'approccio sopra è che non posso più usare s3 senza il doppio trasferimento dei dati.

Per prima cosa ho bisogno di trasferire i dati da s3 - > server di backend quindi dal server back-end - > frontend.

Se vado con la soluzione che non mi piace, frontend attende più a lungo il backend per generare tutte le dimensioni dell'immagine e restituire tutti gli URL, quindi è necessario eseguire un solo trasferimento, da s3 a frontend.

Ho anche pensato ad un'altra possibile soluzione che il backend restituisca gli URL senza che l'immagine sia disponibile, ad esempio:

[
  large: domain.com/dd.jpg?s=large
  small: domain.com/dd.jpg?s=small
]

Quindi quando il frontend chiama ad esempio il piccolo url, se non esiste prima viene generato, quindi memorizzato in s3 quindi backend restituisce il reindirizzamento 302 all'url s3. Penso che questo approccio non funzionerà a causa di molti reindirizzamenti 302, ma offre la flessibilità che voglio.

Sto ancora cercando di capire come risolvere il problema. Qualche suggerimento per favore?

api-design api rest

posta Kristi Jorgji 05.05.2018 - 22:14

fonte

1 risposta

Leggi altre domande sui tag api-design api rest

Contenuto di Project Wiki come possiamo migliorare la documentazione del progetto

score 1 · Answer 1

Se non vuoi che gli utenti attenderanno il caricamento, probabilmente non vuoi che attenderanno quando richiederanno la dimensione specifica di un'immagine (poiché in generale, l'utente che ha caricato l'immagine sarebbe il primo chi lo chiederà comunque). In questo caso, esiste una terza soluzione: generare le versioni ridimensionate di un'immagine tramite un cron job o un'attività in background.

Quando l'utente carica l'originale, tu:

Restituisce la risposta non appena il file viene caricato. L'utente non ha bisogno di aspettare che il server riduca le immagini.
Metti in coda l'attività di ridimensionamento.

Il ciclo in background elabora la coda, raggiunge l'attività per l'immagine specifica, crea le diverse versioni dell'immagine e cambia il database per indicare che l'immagine è ora disponibile in diverse dimensioni.

Una volta che l'immagine è stata elaborata, le sue diverse dimensioni possono essere offerte agli utenti.

Se l'immagine non è ancora stata elaborata, solo la variante 1: 1 dell'immagine sarà disponibile per gli utenti.

Si noti che l'attività in background può essere distribuita tra molti lavoratori, il che significa che si ridimensionerà molto bene. Ciò significa che, data un'infrastruttura decente, puoi essenzialmente ottenere le versioni ridimensionate dell'immagine in pochi secondi.