Applicazione a pagina singola: vantaggi e svantaggi [chiuso]

Ho letto di SPA e vantaggi. Trovo la maggior parte non convincente. Ci sono 3 vantaggi che destano i miei dubbi.

Domanda: puoi agire come avvocato di SPA e dimostrare che ho torto sulle prime tre dichiarazioni?

                              === ADVANTAGES ===

1. SPA è estremamente utile per i siti molto sensibili:

Il rendering sul lato server è difficile da implementare per tutti gli stati intermedi - gli stati di visualizzazione di piccole dimensioni non si associano bene agli URL.

Le app a pagina singola si distinguono per la capacità di ridisegnare qualsiasi parte dell'interfaccia utente senza richiedere un roundtrip del server per recuperare HTML. Ciò si ottiene separando i dati dalla presentazione dei dati disponendo di un livello modello che gestisce i dati e un livello vista che legge dai modelli.

Cosa c'è di sbagliato nel mantenere un livello di modello per non SPA? SPA è l'unica architettura compatibile con MVC sul lato client?

2. Con SPA non è necessario utilizzare query aggiuntive sul server per scaricare pagine.

Ah, e quante pagine l'utente può scaricare durante la visita del tuo sito? Due tre? Invece compaiono altri problemi di sicurezza ed è necessario separare la pagina di accesso, la pagina di amministrazione ecc. In pagine separate. A sua volta è in conflitto con l'architettura SPA.

3.Potrebbero esserci altri vantaggi? Non sentir parlare di nessun altro ..

                            === DISADVANTAGES ===

1. Il client deve abilitare JavaScript.
2. Solo un punto di accesso al sito.
3. Sicurezza.

PS Ho lavorato su progetti SPA e non SPA. E sto ponendo quelle domande perché ho bisogno di approfondire la mia comprensione. Nessun mezzo per danneggiare i sostenitori della SPA. Non chiedermi di leggere qualcosa in più sulla SPA. Voglio solo sentire le tue considerazioni al riguardo.

Diamo un'occhiata a uno dei siti SPA più popolari, GMail.

1. SPA è estremamente utile per i siti molto sensibili:

Il rendering sul lato server non è così difficile come una volta con semplici tecniche come mantenere un #hash nell'URL o più recentemente HTML5pushState . Con questo approccio lo stato esatto dell'app Web è incorporato nell'URL della pagina. Come in GMail ogni volta che apri una mail, all'URL viene aggiunto un tag hash speciale. Se copiato e incollato in un'altra finestra del browser, è possibile aprire esattamente la stessa posta (a condizione che possano autenticarsi). Questo approccio si associa direttamente a una stringa di query più tradizionale, la differenza sta semplicemente nell'esecuzione. Con HTML5 pushState () è possibile eliminare #hashe utilizzare URL completamente classici che possono essere risolti sul server alla prima richiesta e quindi caricati tramite Ajax nelle richieste successive.

2. Con SPA non è necessario utilizzare query aggiuntive sul server per scaricare pagine.

Il numero di pagine scaricate dall'utente durante la visita al mio sito Web ?? davvero quante e-mail alcune leggono quando apre il suo account di posta. Ho letto> 50 alla volta. ora la struttura delle mail è quasi la stessa. se utilizzerai uno schema di rendering lato server, il server lo renderebbe ad ogni richiesta (caso tipico). - problemi di sicurezza - non dovresti / non dovresti tenere pagine separate per gli amministratori / login che dipendono interamente dalla struttura del tuo sito prendi paytm.com ad esempio anche fare un sito web SPA non significa che apri tutti gli endpoint per tutti i utenti intendo che utilizzo i moduli auth con il mio sito web spa. - nel framework SPA probabilmente più utilizzato Angular JS, lo sviluppatore può caricare l'intero tempio html dal sito Web in modo da poterlo fare in base al livello di autenticazione dell'utente. pre-caricamento html per tutti i tipi di autenticazione isn '

3. Potrebbero esserci altri vantaggi? Non sentir parlare di nessun altro ..

• in questi giorni puoi tranquillamente presumere che il client disporrà di browser abilitati a JavaScript.
• solo un punto di accesso al sito. Come ho già detto, è possibile mantenere lo stato in qualsiasi momento, ma è possibile avere un numero qualsiasi di punti di accesso come desiderato, ma si dovrebbe averne uno sicuramente.
• anche in un utente SPA vedere solo ciò che ha i diritti propri. non devi iniettare tutto in una volta. anche il caricamento di modelli html diff e async javascript è una parte valida di SPA.

I vantaggi che mi vengono in mente sono:

1. il rendering html ovviamente richiede alcune risorse ora che tutti gli utenti che visitano il tuo sito lo stanno facendo. inoltre, non solo il rendering delle principali logiche viene ora eseguito sul lato client anziché sul lato server.
2. problemi relativi all'ora della data - Fornisco solo al client l'ora UTC un formato preimpostato e non mi importa nemmeno dei fusi orari che lascio che javascript gestisca. questo è un grande vantaggio per cui dovevo indovinare i fusi orari in base alla posizione derivata dall'IP degli utenti.
3. per me lo stato è più ben mantenuto in una SPA perché una volta che hai impostato una variabile sai che sarà lì. questo dà la sensazione di sviluppare un'app piuttosto che una pagina web. questo aiuta molto tipicamente nel creare siti come foodpanda, flipkart, amazon. perché se non si utilizza lo stato lato client si stanno utilizzando sessioni costose.
4. i siti Web sicuramente sono estremamente reattivi - Prenderò un esempio estremo per questo tentativo di creare una calcolatrice in un sito Web non SPA (lo so strano).

Aggiornamenti dai commenti

Non sembra che qualcuno abbia parlato di socket e polling a lungo. Se esci da un altro client, ad esempio app mobile, anche il tuo browser dovrebbe disconnettersi. Se non si utilizza SPA, è necessario ricreare la connessione socket ogni volta che si verifica un reindirizzamento. Questo dovrebbe funzionare anche con qualsiasi aggiornamento di dati come notifiche, aggiornamento del profilo, ecc

Una prospettiva alternativa: a parte il tuo sito web, il tuo progetto coinvolgerà un'app mobile nativa? In caso affermativo, molto probabilmente fornirai dati non elaborati a quell'app nativa da un server (ad esempio JSON) e eseguirai l'elaborazione sul lato client per renderli, giusto? Quindi, con questa affermazione, stai già facendo un modello di rendering sul lato client. Ora la domanda diventa: perché non dovresti usare lo stesso modello per la versione del sito web del tuo progetto? Una specie di gioco da ragazzi. Quindi la domanda diventa se si desidera eseguire il rendering di pagine lato server solo per vantaggi SEO e comodità di URL condivisibili / segnalibro

Sono un pragmatico, quindi cercherò di esaminarlo in termini di costi e benefici.

Si noti che per qualsiasi svantaggio che do, riconosco che sono risolvibili. Ecco perché non guardo a nulla come in bianco e nero, ma piuttosto a costi e benefici.

vantaggi

• Tracciamento dello stato più semplice: non è necessario utilizzare cookie, invio di moduli, archiviazione locale, archiviazione di sessioni, ecc. Per ricordare lo stato tra 2 caricamenti di pagine.
• Il contenuto della piastra della caldaia presente in ogni pagina (intestazione, piè di pagina, logo, banner sul copyright, ecc.) Viene caricato solo una volta per sessione tipica del browser.
• Nessuna latenza di sovraccarico nel passaggio da "pagine".

svantaggi

• Monitoraggio delle prestazioni - mani legate: la maggior parte delle soluzioni di monitoraggio delle prestazioni a livello di browser che ho visto concentrarsi esclusivamente sul tempo di caricamento della pagina, come il tempo al primo byte, il tempo di creare DOM, il round trip di rete per l'HTML, l'evento di caricamento, ecc. Aggiornamento della pagina il post-caricamento tramite AJAX non verrebbe misurato. Esistono soluzioni che ti consentono di strumentare il tuo codice per registrare misure esplicite, come quando fai clic su un link, avvia un timer, quindi termina un timer dopo aver eseguito il rendering dei risultati AJAX e invia quel feedback. New Relic, ad esempio, supporta questa funzionalità. Usando una SPA, ti sei legato solo a pochi strumenti possibili.
• Test di sicurezza / penetrazione - mani legate: le scansioni di sicurezza automatizzate possono avere difficoltà a trovare collegamenti quando l'intera pagina è costruita dinamicamente da un framework SPA. Probabilmente ci sono soluzioni a questo, ma ancora una volta ti sei limitato.
• Raggruppamento: è facile entrare in una situazione quando si sta scaricando tutto il codice necessario per l'intero sito Web al caricamento della pagina iniziale, che può funzionare in modo terribile per le connessioni a larghezza di banda ridotta. Puoi raggruppare i tuoi file JavaScript e CSS per provare a caricare blocchi più naturali mentre procedi, ma ora devi mantenere quella mappatura e guardare i file non intenzionali da ottenere tramite dipendenze non realizzate (mi è appena successo). Ancora una volta, risolvibile, ma con un costo.
• Refactoring del big bang: se si desidera apportare un cambiamento architettonico importante, come ad esempio passare da un framework all'altro, per ridurre al minimo il rischio, è preferibile apportare modifiche incrementali. Cioè, inizia a utilizzare il nuovo, migra su una base, come per pagina, per funzione, ecc., Quindi elimina il vecchio dopo. Con l'app tradizionale multipagina, è possibile passare da una pagina Angolare a React, quindi passare a un'altra pagina nello sprint successivo. Con una SPA, è tutto o niente. Se vuoi cambiare, devi cambiare l'intera applicazione in una volta sola.
• Complessità della navigazione: esistono strumenti per aiutare a mantenere il contesto di navigazione nelle SPA, come history.js, Angular 2, la maggior parte delle quali si basa sul framework URL (#) o sulla più recente API di cronologia. Se ogni pagina era una pagina separata, non ne hai bisogno.
• Complessità di capire il codice: naturalmente pensiamo ai siti Web come a pagine. Un'app multi-pagina di solito suddivide il codice per pagina, il che aiuta la manutenibilità.

Ancora una volta, riconosco che ognuno di questi problemi è risolvibile, a un certo costo. Ma arriva un punto in cui passi tutto il tuo tempo a risolvere problemi che potresti aver evitato in primo luogo. Torna ai vantaggi e all'importanza che hanno per te.

svantaggi

1. Il client deve abilitare JavaScript. Sì, questo è un chiaro svantaggio della SPA. Nel mio caso so che posso aspettarmi che JavaScript sia abilitato per i miei utenti. Se non puoi, non puoi fare una SPA, punto. È come provare a distribuire un'app .NET su una macchina senza .NET Framework installato.

2. Solo un punto di accesso al sito. Risolvo questo problema usando SammyJS . 2-3 giorni di lavoro per configurare correttamente il tuo percorso e le persone saranno in grado di creare segnalibri di collegamento diretto nella tua app che funzionino correttamente. Il tuo server dovrà solo esporre un endpoint - l'endpoint "dammi l'HTML + CSS + JS per questa app" (consideralo come un percorso di download / aggiornamento per un'applicazione precompilata) - e il JavaScript sul lato client che scrivi scriverà gestire l'entrata effettiva nell'applicazione.

3. Sicurezza.Questo problema non è univoco per le SPA, devi avere a che fare con la sicurezza esattamente allo stesso modo quando hai un'app client-server "vecchia scuola" (il modello HATEOAS di usare Hypertext per collegarti tra le pagine). È solo che l'utente sta facendo le richieste anziché il tuo JavaScript e che i risultati sono in HTML anziché in JSON o in alcuni formati di dati. In un'app non SPA devi proteggere le singole pagine sul server, mentre in un'app SPA devi proteggere gli endpoint dei dati. (E, se non vuoi che il tuo client abbia accesso a tutto il codice, devi dividere il JavaScript scaricabile anche in aree separate. Lo collego semplicemente al mio sistema di routing basato su SammyJS, quindi il browser richiede solo cose a cui il cliente sa che dovrebbe avere accesso, in base a un carico iniziale di ruoli dell'utente,

vantaggi

1. Un grande vantaggio architettonico di una SPA (che viene raramente menzionato) in molti casi è l'enorme riduzione della "chattiness" della tua app. Se lo si progetta correttamente per gestire la maggior parte dell'elaborazione sul client (l'intero punto, dopotutto), il numero di richieste al server (leggere "possibilità di errori 503 che rovinano l'esperienza dell'utente") è notevolmente ridotto. In effetti, una SPA rende possibile l'elaborazione completamente offline, che è enorme in alcune situazioni.

2. Le prestazioni sono certamente migliori con il rendering lato client se lo fai bene, ma questo non è il motivo più convincente per costruire una SPA. (Dopotutto, la velocità della rete sta migliorando.) Non basarti su SPA solo su questa base.

3. La flessibilità nella progettazione dell'interfaccia utente è forse l'altro grande vantaggio che ho riscontrato. Dopo aver definito la mia API (con un SDK in JavaScript), sono stato in grado di riscrivere completamente il mio front-end con zero impatto sul server a parte alcuni file di risorse statiche. Prova a farlo con un'app MVC tradizionale! :) (Questo diventa prezioso quando hai distribuzioni live e coerenza della versione della tua API di cui preoccuparti.)

Quindi, linea di fondo: se hai bisogno di elaborazione offline (o almeno vuoi che i tuoi clienti siano in grado di sopravvivere a occasionali interruzioni del server) - riducendo drasticamente i tuoi costi hardware - e puoi assumere JavaScript e browser moderni, allora hai bisogno di una SPA. In altri casi è più un compromesso.

Uno svantaggio principale della SPA - SEO. Solo di recente Google e Bing hanno iniziato a indicizzare le pagine basate su Ajax eseguendo JavaScript durante la ricerca per indicizzazione, e ancora in molti casi le pagine vengono indicizzate in modo errato.

Durante lo sviluppo di SPA, sarai costretto a gestire i problemi SEO, probabilmente post-rendering di tutto il tuo sito e creando snapshot html statici per l'uso del crawler. Ciò richiederà un solido investimento in infrastrutture adeguate.

Aggiornamento 19.06.16:

Da quando ho scritto questa risposta qualche tempo fa, ho acquisito molta più esperienza con le app a pagina singola (vale a dire AngularJS 1.x), quindi ho più informazioni da condividere.

A mio avviso, il principale svantaggio delle applicazioni SPA è il SEO, che le rende limitate al solo tipo di app "dashboard". Inoltre, avrai tempi molto più difficili con la memorizzazione nella cache, rispetto alle soluzioni classiche. Ad esempio, nella cache ASP.NET è estremamente semplice: basta attivare OutputCaching e sei a posto: l'intera pagina HTML verrà memorizzata nella cache in base all'URL (o a qualsiasi altro parametro). Tuttavia, in SPA dovrai gestire la cache da solo (utilizzando alcune soluzioni come cache di secondo livello, cache dei modelli, ecc.).

Vorrei che il caso SPA fosse il migliore per le applicazioni basate sui dati. gmail, ovviamente, è tutto basato sui dati e quindi un buon candidato per una SPA.

Ma se la tua pagina è principalmente per la visualizzazione, ad esempio una pagina dei termini di servizio, una SPA è completamente eccessiva.

Penso che il punto debole sia avere un sito con una combinazione di pagine sia in stile SPA che statiche / MVC, a seconda della pagina particolare.

Ad esempio, su un sito che sto costruendo, l'utente atterra su una pagina di indice MVC standard. Ma poi quando passano all'applicazione effettiva, chiama la SPA. Un altro vantaggio è che il tempo di caricamento della SPA non è nella home page, ma nella pagina dell'app. Il tempo di caricamento nella home page potrebbe essere una distrazione per gli utenti del sito per la prima volta.

Questo scenario è un po 'come usare Flash. Dopo alcuni anni di esperienza, il numero di siti solo Flash è sceso quasi a zero a causa del fattore di carico. Ma come componente di pagina, è ancora in uso.

Per aziende come Google, Amazon, ecc., I cui server funzionano alla massima capacità in modalità 24/7, ridurre il traffico significa denaro reale: meno hardware, meno energia, meno manutenzione. Spostare l'utilizzo della CPU dal server al client paga e le SPA brillano. I vantaggi in sovrappeso svantaggi di gran lunga. Quindi, SPA o non SPA dipende molto dal caso d'uso.

Solo per menzionare un altro caso d'uso, probabilmente non così ovvio (per gli sviluppatori Web) per le SPA: attualmente sto cercando un modo per implementare le GUI nei sistemi integrati e l'architettura basata su browser mi sembra interessante. Tradizionalmente non c'erano molte possibilità per le interfacce utente nei sistemi incorporati: Java, Qt, Wx, ecc. O quadri commerciali propri. Alcuni anni fa Adobe ha cercato di entrare nel mercato con il flash ma sembra non avere molto successo.

Al giorno d'oggi, poiché alcuni "sistemi integrati" sono potenti come i mainframe alcuni anni fa, un'interfaccia utente basata su browser collegata all'unità di controllo tramite REST è una possibile soluzione. Il vantaggio è che l'enorme gamma di strumenti per l'interfaccia utente è gratuita. (ad es. Qt richiede 20-30 $ per unità venduta con diritti di royalty più 3000-4000 $ per sviluppatore)

Per tale architettura, la SPA offre molti vantaggi, ad esempio un approccio allo sviluppo più familiare per gli sviluppatori di app desktop, un accesso ridotto al server (spesso nell'industria automobilistica l'interfaccia utente e le confusioni del sistema sono hardware separato, dove la parte del sistema ha un sistema operativo RT).

Poiché l'unico client è il browser integrato, gli svantaggi citati come la disponibilità di JS, la registrazione lato server, la sicurezza non contano più.

2. Con SPA non è necessario utilizzare query aggiuntive sul server per scaricare pagine.

Devo ancora imparare molto, ma da quando ho iniziato a conoscere la SPA, li adoro.

Questo particolare punto può fare un'enorme differenza.

In molte app Web che non sono SPA, vedrai che recupereranno e aggiungeranno ancora contenuto alle pagine che fanno richieste Ajax. Quindi penso che SPA vada oltre considerando: cosa succede se il contenuto che verrà recuperato e visualizzato utilizzando Ajax è l'intera pagina? e non solo una piccola parte di una pagina?

Vorrei presentare uno scenario. Considera che hai 2 pagine:

1. una pagina con un elenco di prodotti
2. una pagina per visualizzare i dettagli di un prodotto specifico

Considera di essere nella pagina di elenco. Quindi fai clic su un prodotto per visualizzare i dettagli. L'app lato client attiverà 2 richieste ajax:

1. una richiesta per ottenere un oggetto json con i dettagli del prodotto
2. una richiesta per ottenere un modello html in cui verranno inseriti i dettagli del prodotto

Quindi, l'app lato client inserirà i dati nel modello html e li visualizzerà.

Quindi si ritorna all'elenco (non viene effettuata alcuna richiesta per questo!) E si apre un altro prodotto. Questa volta, ci sarà solo una richiesta Ajax per ottenere i dettagli del prodotto. Il modello html sarà lo stesso, quindi non è necessario scaricare di nuovo.

Puoi dire che in una non SPA, quando apri i dettagli del prodotto, fai solo 1 richiesta e in questo scenario abbiamo fatto 2. Sì. Ma ottieni il guadagno da una prospettiva generale, quando navighi attraverso molte pagine, il numero di richieste sarà inferiore. E anche i dati che vengono trasferiti tra il lato client e il server saranno più bassi perché i modelli html verranno riutilizzati. Inoltre, non è necessario scaricare in ogni richiesta tutti quei file CSS, immagini, javascript presenti in tutte le pagine.

Inoltre, consideriamo che la lingua lato server è Java. Se analizzi le 2 richieste che ho menzionato, 1 scarica i dati (non è necessario caricare alcun file di visualizzazione e chiamare il motore di rendering della visualizzazione) e gli altri download e il modello html statico in modo da poter disporre di un server Web HTTP in grado di recuperare direttamente senza dover chiamare il server delle applicazioni Java, non viene eseguito alcun calcolo!

Infine, le grandi aziende utilizzano SPA: Facebook, GMail, Amazon. Non giocano, hanno i più grandi ingegneri che studiano tutto questo. Quindi, se non vedi i vantaggi, puoi inizialmente fidarti di loro e sperare di scoprirli lungo la strada.

Ma è importante utilizzare buoni modelli di progettazione SPA. È possibile utilizzare un framework come AngularJS. Non tentare di implementare una SPA senza utilizzare buoni modelli di progettazione perché potresti finire per avere un pasticcio.

Svantaggi : tecnicamente, la progettazione e lo sviluppo iniziale della SPA sono complessi e possono essere evitati. Altri motivi per non utilizzare questa SPA possono essere:

• a) Sicurezza: l'applicazione a pagina singola è meno sicura rispetto alle pagine tradizionali a causa del cross site scripting (XSS).
• b) Perdita di memoria: la perdita di memoria in JavaScript può persino rallentare il potente computer. Poiché i siti Web tradizionali incoraggiano a navigare tra le pagine, qualsiasi perdita di memoria causata dalla pagina precedente viene quasi ripulita lasciando meno residui.
• c) Il client deve abilitare JavaScript per eseguire SPA, ma nell'applicazione multi-pagina JavaScript può essere completamente evitato.
• d) SPA raggiunge dimensioni ottimali, causa lunghi tempi di attesa. Ad esempio: lavorare su Gmail con una connessione più lenta.

Oltre a quanto sopra, altre limitazioni architettoniche sono la perdita dei dati di navigazione, nessun registro della cronologia di navigazione nel browser e difficoltà nel test funzionale automatizzato con selenio.

Questo link spiega i vantaggi e gli svantaggi dell'applicazione a pagina singola.

Nel mio sviluppo ho trovato due distinti vantaggi nell'uso di una SPA. Ciò non significa che in un'app Web tradizionale non si possa ottenere quanto segue, solo che vedo un beneficio incrementale senza introdurre ulteriori svantaggi.

• Il potenziale per una minore richiesta del server poiché il rendering di nuovi contenuti non è sempre o addirittura mai una richiesta del server http per una nuova pagina HTML. Ma dico potenziale perché i nuovi contenuti potrebbero facilmente richiedere una chiamata Ajax per estrarre i dati, ma tali dati potrebbero essere progressivamente più leggeri rispetto allo stesso, oltre al markup che fornisce un vantaggio netto.

• La capacità di mantenere lo "stato". In parole povere, imposta una variabile all'ingresso dell'app e sarà disponibile per altri componenti durante l'esperienza dell'utente senza passarla o impostarla su un modello di archiviazione locale. La gestione intelligente di questa capacità è tuttavia fondamentale per mantenere ordinato l'ambito di livello superiore.

Oltre a richiedere JS (che non è una cosa folle da richiedere alle app Web), a mio avviso, altri svantaggi noti non sono specifici della SPA o possono essere mitigati attraverso buone abitudini e modelli di sviluppo.

Cerca di non prendere in considerazione l'utilizzo di una SPA senza prima definire come affronterai la sicurezza e la stabilità dell'API sul lato server. Quindi vedrai alcuni dei veri vantaggi dell'utilizzo di una SPA. In particolare, se si utilizza un server RESTful che implementa OAUTH 2.0 per motivi di sicurezza, si otterranno due fondamentali separazioni di preoccupazioni che possono ridurre i costi di sviluppo e manutenzione.

1. Questo sposterà la sessione (e la sua sicurezza) sulla SPA e alleggerirà il server da tutto quel sovraccarico.
2. Le tue API diventano sia stabili che facilmente estensibili.

Accennato a prima, ma non reso esplicito; Se il tuo obiettivo è distribuire applicazioni Android e Apple, scrivere una SPA SPA racchiusa da una chiamata nativa per ospitare lo schermo in un browser (Android o Apple) elimina la necessità di mantenere sia una base di codice Apple che una base di codice Android.

Capisco che questa è una domanda precedente, ma vorrei aggiungere un altro svantaggio delle applicazioni a pagina singola:

Se si crea un'API che restituisce risultati in un linguaggio di dati (come XML o JSON) anziché in un linguaggio di formattazione (come HTML), si abilita una maggiore interoperabilità delle applicazioni, ad esempio nelle applicazioni business-to-business (B2B). Tale interoperabilità ha grandi vantaggi ma consente alle persone di scrivere software per "estrarre" (o rubare) i tuoi dati. Questo particolare svantaggio è comune a tutte le API che utilizzano un linguaggio di dati e non alle SPA in generale (anzi, una SPA che richiede al server HTML pre-renderizzato lo evita, ma a scapito della scarsa separazione tra modello / vista). Questo rischio esposto da questo svantaggio può essere mitigato con vari mezzi, come la limitazione della richiesta e il blocco delle connessioni, ecc.