Quali sono i compromessi del rendering lato client rispetto al rendering lato server?
Ho lavorato nello spazio delle applicazioni web fin dai tempi in cui molti non si rendevano conto che c'era una differenza tra un sito web e un'applicazione basata sul web.
All'epoca, le applicazioni client/server erano la grande cosa e JavaScript era usato per lo più solo per la validazione, e in realtà non poteva fare molto di più.
All'epoca, il grid computing e il clustering dei server erano ancora concetti molto nuovi e poche imprese li stavano usando efficacemente, se mai lo hanno fatto. Questo è il momento in cui dovevi essere davvero consapevole del costo delle tue decisioni di sviluppo, poiché anche l'aggiunta di pochi secondi di tempo di elaborazione alla tua pagina era moltiplicata per il numero di persone che la usavano, poiché era resa lato server, il server stava facendo tutto il lavoro.
Pensaci in questo modo. Il vostro server può essere 10 volte più veloce del client, forse anche 100 se considerate che è dedicato solo a servire la pagina web. Se avete meno di 100 persone che accedono al vostro sito in un dato momento, allora è probabile che sia più veloce eseguire il vostro rendering sul server. Tuttavia, se state ricevendo più di 100 utenti alla volta, tutto ad un tratto, il server comincia ad essere intasato di richieste. Questo causa un rallentamento per tutti gli utenti del sito.
Se state gestendo un grande sito che serve più di 1000 utenti alla volta, essi vedranno una significativa diminuzione della velocità e voi vedrete un significativo aumento dei costi a meno che non possiate mettere più elaborazione sul client. Salvate il server per ciò per cui è veramente necessario, elaborando la logica di business.
Una delle cose difficili da vedere per me è tutta l'incomprensione di come e perché queste varie tecnologie funzionano. Fondamentalmente, abbiamo un gruppo di piccoli sviluppatori di app che lavorano su un'applicazione aziendale e si rendono conto che a quel livello le loro pratiche non funzionano, quindi escogitano una nuova strategia per affrontare il problema che è elegante e molto utile se si capisce il contesto. Poi scrivono un libro o un post sul blog, o condividono la loro tecnologia con il mondo dove gli sviluppatori su piccola scala la ottengono e gli viene detto che è il modo migliore di fare le cose, ma non hanno idea del perché, ma pensano di saperlo, così vanno a scrivere tutorial e alla fine tutti i tipi di cattive pratiche vengono introdotti in questa nuova tecnologia. Quando altri sviluppatori entrano in un'applicazione di livello aziendale e cercano di utilizzare questi falsi paradigmi pensano, "questo non funziona". Creano la loro soluzione e l'intero processo ricomincia da capo.
La cosa importante è considerare sempre il TUO ambiente e il TUO pubblico. Se sarà più efficiente mettere tutta l'elaborazione sul server per il tuo piccolo pubblico, allora fallo, ma ti avverto di pensare in anticipo. Assumete che la vostra applicazione avrà successo. Questo significa che avrete più utenti? Se è così, sarà bene che abbiate già una strategia per affrontare l'aumento di carico.
Se considerate queste cose, vi aiuterà a vedere dove gli sviluppatori non ci arrivano quando cercano di insegnarvi come si fa.
Articoli simili
- Se si esegue uno script sul client locale ottenendo e trasmettendo l'indirizzo IP del client al server, la VPN non è forse violata?
- Flutter for Web' supporterà il rendering lato server per un migliore SEO?
- Ho un nuovo parasole per il parabrezza della mia auto. Un lato riflettente e un lato carino. Quale lato dovrebbe essere rivolto al sole?
- Quali sono i vantaggi in termini di prestazioni dell'uso di React Router rispetto al routing lato server?