Servizi Web vs Metodi lato server

Mentre dici "servizi web" (non un singolo servizio), sottoponi i tuoi utenti a più richieste di rete per popolare la tua pagina. Questo può essere una cosa negativa, l'HTTP 1.1 ha introdotto l'idea di mantenere la connessione aperta per richiedere ogni elemento della pagina in una singola connessione dato che era abbastanza veloce, per non parlare del server più efficiente.

C'è anche una questione di sicurezza se i tuoi servizi web che forniscono dati sono direttamente connessi ai tuoi clienti non fidati.

Come risultato di ciò, è meglio progettare la tua pagina per fare una singola richiesta a un singolo server che può quindi richiedere più origini dati e aggregarle in un singolo set di dati per il client. Tutto ciò che potrebbe sembrare bello per lo sviluppatore non significa nulla per l'utente che dovrà aspettare l'arrivo di un blocco di dati, quindi guardare la pagina popolare un altro set - sembrerà molto più lento del semplice dover aspettare il vecchio stile Richiesta HTML (indipendentemente dalla velocità effettiva).

Ovviamente oggi il modo migliore sarebbe utilizzare un websocket e trasmettere continuamente i dati al cliente. Ciò richiederebbe un singolo server sul back-end per servire questo (l'ultima cosa che vuoi è che molti socket siano aperti sul tuo server per servire un singolo utente, che non scalerà bene)

C'è un tempo e un amp; posto per tutto. A volte la risposta giusta è quella di offrire un servizio web che è consumato dal codice lato client.

Questo ti dà il vantaggio di separare chiaramente la tua presentazione dal tuo modello e dalla tua logica di business. Un esempio è che potresti sostituire completamente la tua interfaccia web con un'app nativa.

Ovviamente c'è un inconveniente nell'usare un servizio web. Spesso è più complicato eseguire la codifica e sono necessari 2 round trip sul server, uno per il modello e uno per i dati.

Per rispondere alla tua domanda

Are there any performance cost to writing all client/server communication as web services?

Sì: ci vuole un po 'più di concentrazione degli sviluppatori per programmare e mantenere, e richiede 2 round trip al server per ottenere il modello e i dati.

Tuttavia, questo costo aggiuntivo è spesso un buon investimento e vale la pena.

Non esiste una pratica generalmente accettata. Esistono diversi modelli architettonici per le applicazioni Web.

Il modello di presentazione sul lato server ha l'intero lavoro di generare una pagina eseguita sul lato server. La navigazione nell'applicazione è tra pagine renderizzate interamente dal server. Questo è il modello più vecchio in quanto è stato supportato fintanto che HTML stesso.

L'applicazione a una pagina presenta una pagina del caricatore di applicazioni fornita dal server che potrebbe essere statica. Questa pagina fa riferimento a un'applicazione completamente client che eseguirà il rendering delle pagine e otterrà il contenuto tramite XHR (richieste frequenti poco frequenti), EventSource (eventi side server basati su testo), Websocket (streaming, contenuto binario) o WebRTC (audio peer-to-peer in tempo reale / video) a seconda delle necessità. Questo è un modello popolare per le recenti applicazioni Web.

Esistono anche ibridi di entrambi gli approcci che consentono di ottimizzare il tempo di caricamento della pagina e il consumo delle risorse. Un aspetto spesso trascurato dello sviluppo di applicazioni Web è il consumo di energia sui dispositivi mobili. Un esempio particolarmente negativo di questo è un XHR periodico per ottenere aggiornamenti. Attiverà l'attivazione della radio cellulare subito dopo l'inattività, massimizzando il consumo della batteria e massimizzando la latenza.

Qui non ci sono risposte assolute dirette. Ci sono alcuni principi con ovvi successi però:

1. Crea il minor numero possibile di richieste
2. Invia il minor numero di dati possibile (usa rappresentazioni e compressione efficienti)
3. Approfitta della memorizzazione nella cache (imposta le intestazioni di Cache-Control e Last-Modified e Etag correttamente)

La mia esperienza personale con il passaggio dalla presentazione lato server a un'applicazione a singola pagina è stato un sostanziale miglioramento nella reattività. Ci sono sicuramente aspetti negativi di avere tutti i dati impostati sulla pagina tirato giù in una richiesta separata. Gli svantaggi sono direttamente correlati al modo in cui violano i principi di cui sopra. Abbiamo dovuto imparare a raggruppare i set di dati in un numero inferiore di richieste.

È interessante notare che con HTTP / 2 il raggruppamento è controproducente perché HTTP / 2 supporta più flussi (richieste standard o altro) su una singola connessione TCP. Non spendere molta energia per ottimizzare HTTP / 1.1 in modi che potrebbero danneggiare la tua app per HTTP / 2. Questo trade off non è completamente diretto come scoperta dell'Accademia Khan .

Nel tuo caso, consiglierei di andare con un framework di presentazione lato client. Ti dà più flessibilità nel rendering delle timeline e dei conteggi delle richieste. Ancora più importante ti dà un'applicazione che non va su una schermata bianca quando il server che elabora una richiesta si strozza o scompare. È possibile gestirlo come eccezione sul lato client e fornire meccanismi di feedback e tentativi degli utenti. Non raccomando i framework di presentazione lato server eccetto per facilitare la consegna più efficiente di applicazioni a singola pagina.

Molto altro è disponibile in Rete di browser Web ad alte prestazioni di Ilya Grigorik .