Gli sviluppatori di backend si preoccupano del loro codice nel frontend?

Spetta a tutti coloro che sono coinvolti nello sviluppo di un'applicazione (desktop, web, mobile) per garantire che l'esperienza dell'utente sia il migliore possibile. Se hai tutte le parti del team che collaborano per raggiungere questa fine, ti ritroverai con un'applicazione semi decente.

Il codice di back end deve essere veloce, affidabile e scalabile, ma deve anche essere abbastanza flessibile per far fronte a un'interfaccia utente potenzialmente cambiante e abbastanza semplice da consentire allo sviluppatore dell'interfaccia utente di non legarsi (e potenzialmente all'utente) in nodi per farlo funzionare.

Il livello di accesso al database più veloce è inutile se non è possibile ottenere i dati nel e dal modulo di cui l'utente ha bisogno in un ragionevole lasso di tempo. Ad esempio, se la tua applicazione si occupa di set di dati potenzialmente di grandi dimensioni devi essere in grado di restituire piccole sezioni all'interfaccia utente in modo che sia veloce e reattiva e che l'utente possa fare qualcosa mentre restituisci il resto dei dati. Non va bene se devi rendere l'utente in attesa di tutti i dati da restituire.

Come qualcuno che si è mosso verso il fare principalmente il backend del lavoro dopo averlo fatto end-to-end direi che non mi interessa. Finché non sembra terribile.

Durante lo sviluppo del backend, il tuo compito è fornire servizi solidi e performanti su cui è costruito il frontend. Finché l'infrastruttura funziona senza problemi, il tuo lavoro è finito. Preferiresti che fosse bello ma non è una tua responsabilità.

La parte dell'interfaccia utente di cui si ha una certa responsabilità è la performance. Ci sono molti trucchi che puoi usare nell'interfaccia utente per far sembrare il backend reattivo, ma è molto meglio se è davvero reattivo.