Architettura software | App con back-end API

Ci sono tre (modifica: quattro) ragioni per cui non andrei per questo.

1. Ci si affida all'API di terze parti per integrare ulteriormente con la propria API, per restituire un token e quindi fornire una risposta da un token non un'immagine caricata. Quindi dovresti sapere che forniscono quell'integrazione e la mantengono

2. Stai ottenendo che i tuoi clienti (l'app) effettuino due chiamate API per eseguire un'unica operazione e che necessitino di documentazione perché non è un concetto standard, quindi è necessario documentare e fornire supporto per questo.

3. Affrontare l'autenticazione è difficile e richiede tempo e pensieri. Quando puoi evitarlo, ci provo sempre.

4. Se dai la tua chiave API ai tuoi clienti, cosa significa smetterla seguendo la tua procedura e non solo chiamando direttamente il metodo di analisi delle immagini direttamente e tagliandoti brevemente?

Sono d'accordo con altri commentatori che l'opzione 1 sia ragionevole. Stai mantenendo le tue implementazioni come una scatola nera per i tuoi clienti e un giorno, quando trovi un'API di terze parti migliore che è più veloce ed economica e fa un riconoscimento migliore - devi solo aggiornare la tua API e non devi preoccuparti di dal punto di vista dei tuoi clienti.

Se sei preoccupato per la velocità di trasferimento, perché non guardare prima il ridimensionamento delle immagini sul client o far caricare il client su qualcosa come l'archiviazione BLOB / Amazon S3 di Azure e passare semplicemente gli URL?

La divisione della logica di business nel client e nel back-end non è una buona pratica. Dovresti farlo completamente nel tuo back-end o nel client, e secondo me dovrebbe essere fatto completamente nel tuo back-end. Quindi l'immagine 1 è la strada da percorrere.

Sono d'accordo con il consenso generale ...

1. Il carico sul tuo server per instradare queste immagini sarà minimo fino a quando non avrai successo, il che a quel punto il carico maggiore non ha importanza.
2. L'alternativa richiede molto più tempo.
3. L'alternativa non è sicura.
   4. Se l'altro servizio cambia il modo in cui operano, è molto riparato più velocemente al backend.
   5. Il client sarà molto più facile da costruire e mantieni, poiché sarà meno incline agli errori.

Un'alternativa potrebbe essere quella di caricare il client su S3, quindi inviare l'indirizzo al back-end per l'elaborazione. S3 ha sistemi di sicurezza, oppure puoi mantenerlo semplice e basta configurare il tuo bucket per cancellare tutti i messaggi che sono vecchi ...