Sai cosa considerare prima di sviluppare un'applicazione web?

Quante volte ti è capitato di sentirti dire da un utente la frase “l’applicazione è lenta”? La prima cosa che fai è controllare i log e le metriche delle tue API di backend, ma se ti accorgi che rispondono correttamente e nei tempi attesi, cosa succede? Come è possibile che le tue API funzionano correttamente ma l’applicazione è lenta?

Sappi che potresti aver fatto un errore molto grande il cui costo di risoluzione sarà alto.

Ti spiego meglio.

C’è solo una cosa peggiore di una applicazione che non funziona, una applicazione che è percepita come non funzionante. Infatti se una applicazione non funziona può essere trovato un workaround o magari può essere risolta con un intervento, ma in ogni caso c’è la possibilità che l’utente non si sia accorto del malfunzionamento. Differentemente, se una applicazione è percepita non funzionante (benché i parametri possano dirti il contrario) l’utente avrà un disagio e un malessere sicuro nell’usarla.

È un paradosso lo so: malfunzionamenti reali possono non generano frustrazione, mentre nessun reale problema può generare malessere. Se ci pensi è così: conta più ciò che è percepito di ciò che è reale ed è proprio per questo che dobbiamo creare applicazioni che diano il maggior senso di fluidità possibile all'utente che la usa.

In questo articolo non voglio addentrarmi nel campo della User Experience Design ma se una applicazione è progettata non pensando ai problemi che deve risolvere per l’utente, il risultato sarà la frustrazione che l’utente stesso avrà nell’usarla, con buona pace a tutto lo sforzo che magari hai investito nel costruire un backend performante, sicuro e - se serve - scalabile.

Considera che la diffusione degli smartphone e delle app mobile, hanno fatto sì che l'utente si abituasse ad avere rispetto al passato una user experience a livelli molto molto alti: pensa ad applicazioni che usi tutti i giorni come Airbnb, Instagram, Uber, YouTube… Queste applicazioni hanno una esperienza utente estremamente ottimizzata e oramai anche nelle applicazioni web e nelle applicazioni enterprise, l’utente si aspetta un livello di interazione della stessa qualità ed allo stesso livello.

Sarai d’accordo con me che è quindi fondamentale spendere tempo adeguato a progettare il frontend.

Prima di scrivere una riga di codice dovrai:

• comprendere l’esigenza del tuo utente
• elencare le funzionalità da implementare
• capire quali di queste funzionalità o parti di essa l’utente utilizza più spesso
• ottimizzare le operazioni più frequenti
• scegliere quale modello di frontend è più adatto per la tua applicazione

In questo articolo analizzeremo proprio questo ultimo punto considerato quanto questa scelta sia vincolante e rappresenti la base iniziale per le scelte implementative successive.

Che cos'è una single page application

Una single page application (SPA) è un'applicazione web che carica la pagina con un primo set di richieste al server e tutte le interazioni successive con l'utente provocano il ricaricamento dinamico solo di una porzione della pagina invece che il ricaricamento di tutta la pagina.

Questo modello è in contrapposizione con quella che viene chiamato server side rendering, modello di sviluppo di applicazioni web basato sul ricaricamento dell’intera pagina ad ogni interazione dell’utente. Le conosci sicuramente perché è il modello con cui è nato php, asp 3.0 ed Asp.Net WebForms.

Ad un primo sguardo sembra che la SPA sia sempre preferibile ma ci sono vari fattori che possono influenzare questa scelta.

La differenza principale tra questi due approcci almeno, per quanto riguarda la user experience, fa sì che le single page application offrano un risultato per l'utente molto più fluido perché le transizioni tra uno stato e l'altro all’interno della pagina sono molto più morbide proprio perché non viene ricaricato tutta pagina eliminando quella fastidiosa sensazione di cambio schermo tipica del server side rendering. Dal punto di vista dello sviluppo del codice la differenza principale è che le single page application comunicano con il server scambiando dati - spesso messaggi json - mentre una applicazione sviluppata con il server side rendering comunica con il server scambiando codice di markup (html) che sarà poi renderizzato dal client.

Vista in questa ottica le richieste effettuate dalle SPA sono molto meno pesanti perché quello che viaggia sono i dati minimi per far sì che poi dinamicamente il browser possa, tramite script javascript, costruirsi il markup a partire dai dati usando dei template html in cui sono sostituiti i dati provenienti dal server. Diversamente, il server side rendering invia dal server al client sia dati che markup aumentando il carico di rete.

perché sono nate le single page application

In passato tutte le applicazioni venivano sviluppate col modello server side rendering per vari motivi, principalmente perché la tecnologica, i framework a disposizione e i linguaggi di programmazione per il web erano principalmente linguaggi di scripting come asp 3 o php. Con queste tecnologie era molto più semplice sviluppare applicazioni server side rispetto a single page application, inoltre le applicazioni web erano poco dinamiche rendendo i server web poco più di fornitori di ipertesto.

La vera nascita delle singole page application l'abbiamo avuta con i client di posta di Gmail di Google e ancora prima nel 2004 di Microsoft Exchange. Per la prima volta, queste applicazioni funzionavano come single page application perché per imporsi dovevano ricreare un'esperienza d’uso molto simile a quella fornita dalle applicazioni desktop di mail. Se le applicazioni web non avessero fornito un'interattività pari o molto simile a quelle applicazioni desktop non sarebbero state utilizzate.

In quei tempi sviluppare single page application era dannatamente difficile per vari motivi: javascript infatti non era un linguaggio strutturato e soprattutto non aveva un ecosistema di librerie come oggi.

Javascript, linguaggio alla base delle Single Page Application, ha avuto una grossa evoluzione diventando un linguaggio standard sempre più robusto e moderno. Inoltre oggi grazie a Typescript che aggiunge un typesystem a Javascript, gli sviluppatori possono scrivere codice molto più facilmente mantenibile. Questi fattori hanno sicuramente favorito parte della diffusione delle Single Page Application.

Javascript però non poteva bastare da solo. Infatti il vero problema che ha frenato una prima diffusione delle SPA è il fatto che per anni, ogni vendor di browser offriva API differenti di accesso al Document Object Model (DOM), il modello che serve a manipolare da Javascript il contenuto di una pagina web.

Per colpa di queste differenze, lo sviluppatore impazziva per riuscire a dare la stessa esperienza d'uso per i differenti browser dovendo tenere conto di ogni peculiarità del dom sui vari browser e rendendo molto difficile e molto oneroso sviluppare applicazioni che funzionassero su tutti i browser. La situazione migliorò prima con l'avvento di librerie come jQuery che permette di astrarre con una api comune le differenze tra i vari browser e successivamente grazie agli accordi tra i maggiori vendor portando avanti uno standard comune per esporre le funzionalità dei browser.

Cosa scegliere?

Oggi invece con la nascita di tantissimi framework ed un ecosistema man mano diventato sempre più maturo, negli anni siamo riusciti ad avere degli strumenti che rendono l'esperienza di sviluppo di un'applicazione web SPA molto simile allo sviluppo di un'applicazione desktop.

L’evoluzione dei framework SPA è stata talmente dirompente che oggi sviluppare una SPA richiede un effort simile allo sviluppo di una applicazione basata sul server side rendering. L'esperienza di sviluppo è molto simile e si raggiunge un ottimo livello di mantenibilità in entrambe le casistiche: la scelta di un modello all altro si basa principalmente su su altri fattori.

Quando scegliere il Server Side Rendering

Una dei maggiori fattori che fanno preferire il Server Side Rendering ad una SPA è la SEO. Infatti, le pagine basate su server side rendering, sono accessibili dal punto di vista dei motori di ricerca esattamente alla pari delle pagine statiche e sono molto efficienti dal punto di vista SEO.

Una SPA non è indicizzabile dai motori di ricerca: quello che passa tra client e server non è html ma sono i dati (di norma in formato json) usati dal client per generare la pagina. Per questo motivo è fortemente sconsigliato utilizzare single page application per sviluppare landing page, pagine aziendali e siti vetrina.

Al contrario le SPA possono essere un'ottima scelta là dove l'interazione con l'utente è molto spinta e la User Experience è un aspetto primario da considerare per evitare frustrazioni tue e dell’utente.

Come reperire gli sviluppatori per lo sviluppo della user interface

Il reperimento delle risorse per il tuo team è un altro aspetto importante da tenere conto quando devi scegliere come progettare il tuo frontend. Infatti, Il Server Side Rendering si basa su un framework server side quindi nella maggior parte dei casi sarà uno strumento molto più vicino a lo sviluppatore backend perché questo integrerà nella richiesta servita dal server, sia l'accesso alle logiche applicative del tuo dominio in senso stretto, sia all'accesso al database, fino ad un layer per generare l’html che sarà renderizzato dal cliente senza ulteriore processamento.
In questa ottica, gli skill necessari sono principalmente quelli di backend e molto probabilmente potrai far sviluppare sia la parte client sia la parte server alla stessa figura (o alle stesse figure), risparmiando in termini di costi e gestione delle persone con un team più uniforme: tieni conto però che la User Interface sarà sviluppata da sviluppatori non specializzati, con una peggiore qualità finale.

Analizziamo ora l’impatto sul team delle SPA.

Le Single Page Application richiedono skill differenti rispetto allo sviluppo del backend in termini di linguaggi e framework da conoscere. A prima vista questo è sicuramente uno svantaggio perché devi avere nel tuo team sviluppatori che puoi usare solo per il frontend, ma se facciamo una analisi più approfondita può diventare una grossa opportunità ed un grosso vantaggio per te e per il tuo team.

Lascia che ti spieghi.

Una SPA può essere visto come un sistema separato ed indipendente che comunica con il server solo attraverso una interfaccia di comunicazione ben definita e chiara. Vista sotto questa ottica, il team di frontend e quello di backend possono mettersi d’accordo sulla definizione dello strato di API consumato dal client ed esposto dal server, e lavorare da quel momento in maniera separata ed indipendente all’interfaccia utente ed ai servizi, fino a riprendere a cooperare nella fase di integrazione.

Questo approccio ha il grosso vantaggio di confinare al minino i momenti in cui i due team hanno bisogno di lavorare a stretto contatto e possono sviluppare in modo indipendente aumentando la velocità di produzione del software.

Non è finita qui. Lo sviluppatore frontend, dal punto di vista della conoscenza di linguaggi, ha bisogno di padroneggiare (bene) i linguaggio html, css, javascript e il framework o l’ecosistema di librerie scelte per la tua interfaccia utente. Poiché sono tutte tecnologie che non vincolano in nessun modo la scelta del backend, lo sviluppatore frontend è una figura facilmente reperibili sul mercato perché specializzata.

Immagina lo scenario in cui sei in ritardo sullo sviluppo dell’interfaccia utente: in caso di necessità puoi scalare il team richiedendo temporaneamente al mercato degli sviluppatori per un breve periodo aumentando la velocità dello sviluppo del frontend. Grazie alla alta offerta di questa tipologia di figura e alla loro specializzazione puoi diminuire drasticamente costi e tempi per rendere produttive nuove persone nel team.

Sappiamo bene come i ritardi siano la maggior fonte di stress nella gestione di un progetto e sappiamo altrettanto bene come sia difficile e costoso reperire per brevi periodi le risorse giuste per accelerare la conclusione di un progetto: una scelta come quella che ti ho appena descritto può esserti estremamente utile per rispettare budget e tempi.

Ti dico di più. Se stai valutando lo sviluppo di un progetto che include una Single Page Application la separazione netta tra client e server ti permette di esternalizzare ad un team esterno specializzato in user experience ad alto impatto e sfruttando delle conoscenze che magari internamente non hai per avere un'applicazione molto più ricca e molto più funzionale.

SPA o Server Side Rendering?

Le Single Page Application offrono una esperienza d’uso dell’applicazione molto migliore per l’utente, di conseguenza - nonostante il maggiore effort che richiedono durante lo sviluppo - sono preferibili al Server Side Rendering in tutti i casi tranne quelli di applicazioni che devono essere indicizzati dai motori di ricerca.

Ma SPA di persè non è garanzia di migliore User Experience, anche per le Single Page Application devi fare uno studio approfondito dei tuoi utenti per poter disegnare l’interfaccia ottimizzata per il loro lavoro e solo successivamente definire le tecnologie da utilizzare.

Solo così potrai creare applicazioni web che non siano frustranti per te e i tuoi utenti.