Sto lavorando alla frontend di un prodotto, e ora è rotto a causa di dati errati dal back-end.
Questo può essere catturato internamente prima che arrivi vicino alla produzione, ma finiamo per armeggiare con le dita mentre viene riparato il backend. (Quindi perché sono qui ...)
Ho qualche correzione hackish che esegue un controllo di integrità, in questa particolare istanza, sui dati ricevuti; questo significa che devo fare un controllo per tutti dati?
Onestamente, quanto ti fidi dei dati dal back-end dopo l'esperienza effettiva? Immagino non al 100%, quindi aggiungere alcuni controlli aggiuntivi potrebbe valerne la pena per cogliere alcuni potenziali bug.
Tuttavia, non conosciamo il tuo prodotto, non sappiamo cosa succede quando il tuo frontend si rompe e quale rischio finanziario è in gioco quando i tuoi utenti vedono il tipo di messaggio di errore che il tuo prodotto mostra ora con "dati errati". Inoltre, non sappiamo se il tuo prodotto diventa totalmente inutilizzabile o se solo una funzionalità secondaria del tuo prodotto non funziona. Inoltre, non sappiamo se sanificare "tutti i dati" significa solo poche ore di lavoro aggiuntivo o tre mesi di consegna. Ma questi sono i fattori che devi considerare quando ti chiedi "devo aggiungere solo alcuni controlli" o "devo disinfettare tutti i dati di input come diavolo".
Solo sulle funzionalità, non sulla sicurezza:
Affidati solo ai dati del back-end quando si tratta dello stesso sistema / soluzione. Che cosa significa:
Se hai un'applicazione in qualcosa come Meteor / Nodejs con Angular o una soluzione MS con client e server in un'unica applicazione puoi fidarti.
Questo perché è una soluzione e verrà implementato e testato nel suo complesso. Utilizza la stessa pipeline di consegna. In questo caso, se qualcosa va storto, i test di integrazione / end-to-end sono errati. Li risolvi e sei di nuovo stabile.
Quando il backend è un'applicazione diversa (diciamo una app PHP separata) che può anche provenire da un fornitore / team diverso trattarla come una fonte esterna. Convalidare il maggior numero di dati possibile. Perché: perché questo back-end può essere modificato e potrebbe non notificarti. Quindi il tuo software potrebbe fare cose sbagliate in base ai loro errori e cambiamenti.
I dati dovrebbero essere convalidati all'origine e sarebbe bello se una routine avesse solo dati validi. Nel mondo reale però è raro che sia così. Anche per fonti affidabili, i dati raramente sono al 100% puri come la neve che cade. Doc colpisce alcuni punti chiave. Mi limiterò a aggiungere una domanda per rafforzare: quanto è grave se i dati non sono puliti? Quali sono le conseguenze? Il peggio dei risultati può essere l'elaborazione di dati non validi, più è imperativo che i dati vengano disinfettati prima dell'elaborazione, indipendentemente da quanto tu ti fidi della fonte. Poiché le conseguenze dell'elaborazione dei dati errati si riducono, più è possibile accettare i dati senza convalida per le fonti giudicate affidabili.
Generalmente mi fido dei dati del back-end e diffido dei dati dal front-end. Se il back-end restituisce dati errati, probabilmente è arrivato da un front-end danneggiato. Se non ti puoi fidare dei tuoi back-end, è improbabile che tu possa fornire risultati affidabili.
I dati provenienti dai sistemi dovrebbero in generale essere convalidati. Quanto dettagliata questa convalida dipende dal tipo di dati. Alcune delle convalide che uso includono:
Supponendo che ci si riferisca ad una tipica applicazione basata su architettura client-sever. È sempre una buona idea implementare controlli di integrità o convalida dell'input su ENTRAMBI i lati dell'applicazione (lato client e lato server). Ciò garantirà un ulteriore livello di controlli di integrità su ciascun lato dell'applicazione.
Ora, nel caso del tuo esempio, se ritieni che i dati di back-end siano in qualche modo sbagliati e che devi sempre aspettare una correzione per riportare il front-end a un buon stato di funzionamento; quindi sarebbe una buona idea mettere alcuni degli sforzi di sviluppo nella produzione di stati di errore utili all'interno dell'applicazione invece di "essere appena rotto" o correzioni di Hacky. Producendo uno stato di errore utile è possibile eseguire ulteriori analisi delle cause principali.
Ciò che intendo per utili stati di errore qui è fondamentalmente un modello per catturare la causa principale del problema ma visualizzare un messaggio contestuale pertinente all'utente nel front-end. Ad esempio, quando è rotto e il suo cliente guarda lo schermo " Dì il suo temporaneamente non disponibile, per favore riprova tra X ore ... " o qualcosa del genere, ma quando uno sviluppatore / lo guarda si assicura che ha sufficienti dettagli di errore rilevanti in modo che possano indagare sul problema o seguire le persone giuste.
Bene, controllare i dati ricevuti nel front-end può essere una buona cosa per fornire all'utente un feedback rapido in caso di errori.
Tuttavia, questo è il più delle volte eccessivo e potrebbe essere pericoloso, se le specifiche cambiano e la convalida cambia con esso, puoi controllare i dati nel front-end in qualche modo e il back-end in altri modi, che creerà incongruenze.
Non sono d'accordo con
the backend team broke the frontend because of some bad data being returned to us
però, hanno rotto il backend lì. Il front-end non dovrebbe subire alcun impatto anche se i dati sono negativi, poiché si tratta solo di un livello di presentazione dei dati.
Leggi altre domande sui tag design