Scegliere tra app Web tradizionali e a pagina singola

Suggerimento

Questo contenuto è un estratto dell'eBook Progettare applicazioni Web moderne con ASP.NET Core e Azure, disponibile in .NET Docs o come PDF scaricabile gratuitamente che può essere letto offline.

Architect Modern Web Applications with ASP.NET Core and Azure eBook cover thumbnail.

"Legge di Atwood: qualsiasi applicazione che può essere creata in JavaScript, finirà per essere creata in JavaScript".
- Jeff Atwood

Attualmente esistono due approcci generali alla creazione di applicazioni Web: le applicazioni Web tradizionali che eseguono la maggior parte della logica dell'applicazione nel server e le applicazioni a pagina singola che eseguono la maggior parte della logica dell'interfaccia utente in un Web browser, comunicando con il server Web principalmente attraverso API Web. È anche possibile un approccio ibrido: l'esempio più semplice è l'hosting di una o più sottoapplicazioni a pagina singola all'interno di un'applicazione Web tradizionale più grande.

Usare applicazioni Web tradizionali quando:

  • I requisiti lato client dell'applicazione sono semplici o di sola lettura.

  • L'applicazione deve funzionare in browser che non supportano JavaScript.

  • L'applicazione è pubblica e trae vantaggio dall'individuazione e dai referral dei motori di ricerca.

Usare un'applicazione a pagina singola quando:

  • L'applicazione deve esporre un'interfaccia utente avanzata con numerose funzionalità.

  • Il team ha familiarità con lo sviluppo in JavaScript, TypeScript o BlazorWebAssembly.

  • L'applicazione deve già esporre un'API per altri client (interni o pubblici).

I framework delle applicazioni a pagina singola richiedono anche maggiori conoscenze a livello di architettura e sicurezza. Sono più soggetti all'abbandono rispetto alle applicazioni Web tradizionali, a causa degli aggiornamenti frequenti e dei nuovi framework client. La configurazione dei processi di compilazione e distribuzione automatizzati e l'uso di opzioni di distribuzione come i contenitori risultano più difficili con le applicazioni a pagina singola che con le app Web tradizionali.

I miglioramenti dell'esperienza utente offerti dall'approccio delle applicazioni a pagina singola devono essere valutati a fronte di queste considerazioni.

Blazor

ASP.NET Core include un modello per la creazione di un'interfaccia utente avanzata, interattiva e componibile denominata Blazor. Blazor sul lato server consente agli sviluppatori di compilare l'interfaccia utente con C# e Razor nel server e di connettere l'interfaccia utente in modo interattivo al browser in tempo reale usando una connessione SignalR permanente. BlazorWebAssembly introduce un'altra opzione per le app Blazor, consentendone l'esecuzione nel browser con WebAssembly. Poiché si tratta di vero codice .NET reale in esecuzione in WebAssembly, è possibile riutilizzare codice e librerie dalle parti lato server dell'applicazione.

Blazor fornisce una nuova, terza opzione da considerare quando si valuta se creare un'applicazione a pagina singola o un'applicazione Web pura che esegue il rendering lato server. Con Blazor è possibile creare comportamenti avanzati simili a quelli delle applicazioni a pagina singola, senza bisogno di uno sviluppo significativo di codice JavaScript. Le applicazioni Blazor possono chiamare API per richiedere dati o eseguire operazioni sul lato server. Possono interagire con JavaScript, se necessario, per sfruttare le librerie e i framework JavaScript.

Considerare la possibilità di creare l'applicazione Web con Blazor quando:

  • L'applicazione deve esporre un'interfaccia utente avanzata

  • Il team è più a suo agio con lo sviluppo .NET rispetto allo sviluppo JavaScript o TypeScript

Se si ha un'applicazione Web Forms esistente di cui si sta valutando la migrazione a .NET Core o all'ultima versione di .NET, può essere utile consultare l'e-book gratuito Blazor per sviluppatori Web Forms per verificare se è opportuno eseguirne la migrazione a Blazor.

Per altre informazioni su Blazor, vedere Introduzione a Blazor.

Quando scegliere le app Web tradizionali

La sezione seguente descrive in modo più dettagliato i motivi indicati in precedenza per cui scegliere applicazione Web tradizionali.

L'applicazione ha requisiti lato client semplici o di sola lettura

Molte applicazioni Web vengono usate principalmente in modalità di sola lettura dalla maggior parte degli utenti. Le applicazioni di sola lettura (o prevalentemente di sola lettura) tendono a essere molto più semplici rispetto a quelle che devono gestire e modificare grandi quantità di dati di stato. Ad esempio un motore di ricerca può essere costituito da un singolo punto di ingresso con una casella di testo e da una seconda pagina per la visualizzazione dei risultati della ricerca. Qualsiasi utente anonimo può formulare richieste e la logica lato client necessaria è minima. In modo analogo, l'applicazione destinata al pubblico di un blog o di un sistema di gestione dei contenuti è in genere costituita soprattutto da contenuto, con funzionalità lato client limitate. Le applicazioni di questo tipo possono essere facilmente create come applicazioni Web tradizionali, che eseguono la logica nel server Web e restituiscono risultati in formato HTML da visualizzare nel browser. Il fatto che ogni pagina univoca del sito disponga di un proprio URL, al quale i motori di ricerca possono applicare un segnalibro e un indice (per impostazione predefinita, senza aggiungere questa operazione come funzionalità separata dell'applicazione) è un altro evidente vantaggio in questi scenari.

L'applicazione deve funzionare in browser che non supportano JavaScript

Le applicazioni Web che devono funzionare in browser con supporto limitato o senza supporto per JavaScript devono essere scritte con i flussi di lavoro tradizionali per le app Web (o almeno devono essere in grado di attivare il comportamento corrispondente se necessario). Per il funzionamento delle applicazioni a pagina singola, JavaScript deve essere disponibile sul lato client. In caso contrario, le applicazioni a pagina singola non rappresentano la scelta ottimale.

Il team non ha dimestichezza con le tecniche di sviluppo di JavaScript o TypeScript

Se il team non ha dimestichezza con JavaScript o TypeScript, ma ha familiarità con lo sviluppo di applicazioni Web lato server, probabilmente potrà produrre un'app Web tradizionale più rapidamente di un'applicazione a pagina singola. A meno che l'apprendimento della programmazione di applicazioni a pagina singola non sia un obiettivo o che sia necessaria l'esperienza utente offerta da un'applicazione a pagina singola, le app Web tradizionali sono una scelta più produttiva per i team che hanno già familiarità con lo sviluppo di queste app.

Quando scegliere le applicazioni a pagina singola

La sezione seguente contiene una spiegazione più dettagliata dei casi in cui è opportuno scegliere l'approccio di sviluppo applicazione a pagina singola per l'app Web.

L'applicazione deve esporre un'interfaccia utente avanzata con numerose funzionalità

Le applicazioni a pagina singola supportano funzionalità lato client complete, che non richiedono di ricaricare la pagina quando gli utenti eseguono operazioni o passano da un'area all'altra dell'app. Le applicazioni a pagina singola vengono caricate rapidamente recuperando i dati in background e le singole azioni dell'utente risultano più rapide, perché pagine vengono ricaricate completamente solo in casi sporadici. Le applicazioni a pagina singola supportano gli aggiornamenti incrementali, salvando documenti o moduli completati solo parzialmente senza richiedere all'utente di fare clic su un pulsante per inoltrare un modulo. Le applicazioni a pagina singola supportano comportamenti lato client complessi, quali il trascinamento della selezione, con maggior facilità rispetto alle applicazioni tradizionali. Le applicazioni a pagina singola possono anche essere progettate per l'esecuzione in modalità non connessa mediante aggiornamento di un modello lato client che viene sincronizzato nel server quando viene ristabilita una connessione. Scegliere un'applicazione a pagina singola se i requisiti dell'app includono funzionalità complete, che vanno oltre quelle offerte dai tipici form HTML.

In molti casi le applicazioni a pagina singola devono implementare funzionalità che sono incorporate nelle app Web tradizionali, quali la visualizzazione nella barra dell'indirizzo di un URL corretto che rifletta l'operazione in corso, oltre all'autorizzazione degli utenti alla creazione di un segnalibro o un collegamento diretto a tale URL, per poter tornare alla pagina. Infine le applicazioni a pagina singola devono consentire agli utenti di usare i pulsanti Indietro e Avanti del browser con risultati prevedibili.

Il team ha familiarità con lo sviluppo in JavaScript e/o TypeScript

Per creare applicazioni a pagina singola è necessario avere dimestichezza con JavaScript e/o TypeScript e con le tecniche e le librerie della programmazione lato client. Il team deve essere in grado di creare codice JavaScript moderno tramite un framework per applicazioni a pagina singola come Angular.

Riferimenti: framework per applicazioni a pagina singola

L'applicazione deve già esporre un'API per altri client (interni o pubblici)

Se si supporta già un'API Web per l'uso con altri client, può risultare meno oneroso creare un'implementazione di tipo applicazione a pagina singola che si avvale di tale API anziché riprodurre la logica nel formato lato server. Le applicazioni a pagina singola usano sistematicamente le API Web per eseguire query e aggiornare i dati quando gli utenti interagiscono con l'applicazione.

Quando scegliere Blazor

La sezione seguente è una spiegazione più dettagliata di quando scegliere Blazor per l'app Web.

L'applicazione deve esporre un'interfaccia utente avanzata

Come le applicazioni a pagina singola basate su JavaScript, le applicazioni Blazor possono supportare un comportamento avanzato del client senza ricaricare le pagine. Queste applicazioni sono più reattive, poiché recuperano solo i dati (o il codice HTML) necessari per rispondere a una determinata interazione dell'utente. Progettate correttamente, le app Blazor lato server possono essere configurate per l'esecuzione come app Blazor lato client con pochissime modifiche quando questa funzionalità è supportata.

Il team è più a suo agio con lo sviluppo .NET rispetto allo sviluppo JavaScript o TypeScript

Molti sviluppatori sono più produttivi con .NET e Razor che con linguaggi lato client come JavaScript o TypeScript. Poiché il lato server dell'applicazione è già sviluppato con .NET, l'uso di Blazor garantisce che ogni sviluppatore .NET del team possa comprendere e potenzialmente compilare il comportamento del front-end dell'applicazione.

Tabella decisioni

La tabella seguente riepiloga alcuni fattori di base da considerare per la scelta tra un'applicazione Web tradizionale, un'applicazione a pagina singola e un'app Blazor.

Fattore App Web tradizionale Applicazione a pagina singola App Blazor
Il team deve conoscere JavaScript o TypeScript Minima Obbligatorio Minima
Supporto dei browser senza script Supportata Non supportato Supportata
Comportamento minimo dell'applicazione lato client Adeguato Eccessivo Accettabile
Esigenza di un'interfaccia utente dettagliata e complessa Limitato Adeguato Adeguato

Altre considerazioni

Le app Web tradizionali tendono a essere più semplici e hanno criteri di ottimizzazione motore di ricerca (SEO) migliori rispetto alle app a pagina singola. I bot dei motori di ricerca possono utilizzare facilmente il contenuto delle app tradizionali, mentre il supporto per l'indicizzazione delle applicazioni a pagina singola potrebbe essere limitato o assente. Se l'app trae vantaggio dall'individuazione pubblica da parte dei motori di ricerca, questa è spesso una considerazione importante.

Inoltre, a meno che non sia stato creato uno strumento di gestione per il contenuto dell'applicazione a pagina singola, può essere necessario affidare la gestione delle modifiche agli sviluppatori. Le app Web tradizionali sono spesso più semplici da modificare per gli utenti non sviluppatori, poiché gran parte del contenuto è semplicemente HTML e potrebbe non richiedere un processo di compilazione per l'anteprima o persino per la distribuzione. Se è probabile che saranno utenti non sviluppatori dell'organizzazione a mantenere il contenuto dell'app, un'app Web tradizionale può rappresentare una scelta migliore.

Le applicazioni a pagina singola offrono risultati eccellenti quando l'app ha moduli interattivi complessi o altre funzionalità di interazione con l'utente. Per le app complesse per il cui utilizzo è necessaria l'autenticazione e che pertanto non sono accessibili agli spider dei motori di ricerca pubblici, le applicazioni a pagina singola rappresentano un'ottima scelta in molti casi.