L'equilibrio tra le funzionalità client e server

Naviga le tue risposte
0

Voglio portare la discussione che è iniziata nei nostri team e ottenere la tua opinione al riguardo.

Supponiamo di avere un account utente che potrebbe avere credenziali diverse per l'autenticazione e l'email associata da recuperare. Un utente ha la possibilità di iscriversi tramite e-mail o utilizzare il suo profilo social per completare la procedura di registrazione.

Come un'API di Rest dal back-end al client assomiglia a:

  1. Crea un account
  2. Autorizza
  3. Aggiorna dati utente
  4. Collega account social
  5. Registra email
  6. Verifica email

Inoltre, il nostro BE è distribuito e suddiviso tra diversi servizi / server / cluster. Quindi chiamate diverse sono legate a diversi punti finali. Inoltre abbiamo diversi client: applicazioni native mobili, applicazioni web.

Il solito flusso di registrazione cerca il client in questo modo:

  1. Chiedi all'utente per email
  2. Crea un account (Riposo)
  3. Autorizza (Riposo)
  4. Chiedi all'utente il nome visualizzato
  5. Aggiorna dati (Riposo)
  6. Registra email (Riposo)

E possibili chiamate future:

  1. Verifica email
  2. Collega account social all'utente

Con l'iscrizione a Facebook:

  1. Chiedi all'utente di accedere a FB
  2. Crea un account (Riposo)
  3. Autorizza (Riposo)
  4. Link FB (Rest)
  5. Registrare e verificare l'e-mail dell'utente FB (Rest)
  6. Aggiorna il nome utente in base ai dati FB (Rest)

Ma tutti questi passaggi sono possibili sul back-end. Quindi abbiamo proposto di avere un altro endpoint che nasconderà / combinerà chiamate diverse su BE e restituirà l'intero risultato del processo ai client:

  1. Chiedi all'utente login FB
  2. Nuovo utente con FB (Riposo proposto)
  3. BE sta facendo registrazione / collegamento email verificata / aggiornamento dati utente / autorizzazione

I professionisti per questo approccio:

  1. Niente più duplicazione delle funzionalità tra i client
  2. Velocizza il networking e l'esperienza utente

I contro per questo approccio:

  1. Lavoro aggiuntivo per il back-end
  2. Probabilmente gli scenari più complessi nei futuri aggiornamenti

Vorrei avere la tua opinione o esperienza in questa situazione. Soprattutto se hai già sperimentato il punto "Probabilmente la maggior parte degli scenari complessi in futuri aggiornamenti" da contro i motivi.

    
posta Eugen Martynov 22.10.2013 - 13:02
fonte

1 risposta

1

Il punto 2 è un ragionevole argomento contro l'uso dell'approccio dato. Ho lavorato su qualcosa di simile in cui l'utente può avere dati in forma diversa a seconda del punto di ingresso. Ovviamente, la complessità del codice aumenterà in base al numero di nuovi flussi introdotti, ma a seconda dei vantaggi a cui si aggiungono a volte è necessario aggiungere nuovi flussi di utenti. Se non hai casi d'uso con fattore di ramificazione follemente alto, puoi gestire facilmente la complessità se ti concentri su poche cose.

Prova a a rendere le cose leggibili a ogni livello. Indipendentemente dal fatto che esponi la tua API o il codice di scrittura, tieni tutto a portata di mano sia per i programmatori che per gli utenti API. Se ti occupi della leggibilità, di cose più piccole come la denominazione ecc., Le cose diventeranno meno complesse.

Non fare affidamento sui modelli di dati nel tuo archivio ti aspetti alcuni campi chiave, dovrai stare attento mentre definisci ciò che avrai sempre. Ad esempio, hai creato la tua API assumendo, questo campo verrà sempre riempito dall'utente, ma poi introduci un nuovo caso d'uso in cui tale campo non è obbligatorio. Potresti avere difficoltà a cambiare il tuo codice per questo.

Segui i principi di codifica standard che i nostri anziani ci hanno insegnato come KISS, SOLID, design pattern ecc. Questo include anche il mio primo punto ma che è stato menzionato separatamente perché questa è la cosa peggiore in uno scenario complesso.

    
risposta data 22.10.2013 - 14:14
fonte

Leggi altre domande sui tag

Mostra tutte le definizioni in Schema? Controller JSP - nessuna vista