Carica i file dal dispositivo mobile all'architettura Amazon S3

Question

Carica i file dal dispositivo mobile all'architettura Amazon S3

#1 da (1 voti)

4

Ho un'app iOS che comunica con un'API REST che ho sviluppato. Sto usando Amazon S3 per l'archiviazione di file immagine e audio. Al momento sono in grado di caricare / scaricare i file direttamente dall'app mobile (client). Attualmente sto affrontando alcuni problemi con la velocità di upload / download di file di piccole dimensioni (15-20 kB), così come altri problemi come Amazon S3 che non consentono una differenza di tempo di oltre 15 minuti (ovvero se i miei clienti hanno il loro tempo zone o configurazioni data / ora non corrette, non sarebbero in grado di caricare / scaricare questi file da S3.

Ora mi trovo ad affrontare una decisione architettonica verso questi problemi, ovvero caricare / scaricare i file da S3 alla mia API, archiviarli temporaneamente e caricarli / scaricarli sul client mobile. In altre parole cambia da questo:

S3 <----> iOS <----> REST API

a questo:

S3 <----> REST API <----> iOS

I vantaggi:

Tutti i dati vengono elaborati e gestiti dall'API
Nessun problema se il client e lo spazio di archiviazione (S3) non sono sincronizzati (time skew)
Il telefono del cliente comunica con un solo servizio web

Svantaggi:

Tutti i trasferimenti di file sono a due vie
Il traffico web dell'API aumenta sostanzialmente
Aumento della possibilità di perdita di dati / pacchetti, dovendo quindi ripetere l'intero processo

Quale sarebbe la scelta migliore? Lasciare così com'è oppure iniziare a sviluppare trasferimenti di file tramite la mia API?

design architecture ios

posta flizana 01.05.2015 - 14:09

fonte

1 risposta

Leggi altre domande sui tag design architecture ios

Svantaggi della chiave primaria composta specifica relativa a un file di testo

score 1 · Accepted Answer

La velocità di download e caricamento di file di piccole dimensioni può essere aggirata facilmente inserendo diversi file in un archivio (eventualmente con compressione di livello 0 se i file non devono essere compressi, come nel caso dei file JPEG). Se l'utente carica centinaia di file, ciò comporterà due tre file di grandi dimensioni. Se l'utente deve caricare solo uno o due file, la velocità non sarà comunque molto importante.

La configurazione errata di data e ora è il problema dell'utente (la sincronizzazione non dovrebbe essere automatica su quasi tutti i dispositivi mobili collegati a Internet?) La tua applicazione potrebbe verificare se l'ora sul dispositivo è corretta usando NIST ITS. Se, per qualche motivo, questo è impossibile, utilizzare la propria API REST per verificare se l'ora è corretta. Se l'orario non è corretto, informa l'utente che la sincronizzazione è impossibile fino al momento sbagliato, chiedendo se vuole che l'app corregga automaticamente l'ora del dispositivo.

La scelta tra consentire all'app di interagire direttamente con Amazon S3 o utilizzare l'API REST come intermediario dipende principalmente da questi fattori:

Chi possiede le chiavi API di Amazon . Sei pronto a pagare l'utilizzo di S3 per i tuoi utenti o preferisci che si paghino direttamente? Nel primo caso, l'API media ha senso. Nel secondo caso, vai con una connessione diretta a S3.
Privacy, sensibilità dei dati e problemi legali . Se i dati passano attraverso i tuoi server, significa che puoi accedervi e significa anche che tu li stai caricando su S3.

Il primo punto è problematico se i dati sono sensibili e potresti finire denunciato se i clienti non fossero informati correttamente che i dati finiscono sui tuoi server invece di Amazon (che potrebbe diventare ancora più interessante, legalmente parlando, se il tuo i server si trovano in un paese diverso da quello di Amazon).

Il secondo punto è problematico se gli utenti caricano contenuti che sono contrari alle politiche di Amazon. Immagina qualcuno che carichi la pornografia di un bambino. Per Amazon, tu lo stavi caricando, quindi sarai la persona responsabile.
Larghezza di banda . Se la larghezza di banda dei tuoi server è costosa (e perché non lo sarebbe?), Finirai per pagare molto di più per la larghezza di banda di quella che pagherai ad Amazon. Ancora più importante, si paga il doppio della dimensione effettiva dei file, dal momento che li si riceve per la prima volta e quindi li si invia.