Server Side Rendering (Universal)

Abbiamo già parlato della SPA e di come questo tipo di web app migliori l’esperienza dell’utente: rendendo la navigazione più fluida, fornendo un feedback su tempi di caricamento e migliorando l’interazione. Tuttavia questo approccio presenta anche delle limitazioni, principalmente dovute alle dimensioni del caricamento iniziale, ma anche al fatto che l’applicazione viene completamente renderizzata lato client e dunque non è possibile nemmeno vedere la prima pagina senza prima aver scaricato ed eseguito il codice JavaScript necessario.

Per superare queste limitazioni i vari framework frontend si sono dotati di logiche di server side rendering, cioè di generazione della prima pagina visitata a backend, per poi riprendere l’esecuzione della SPA a frontend in un secondo momento. In questo modo migliora anche il rapporto che la nostra web app avrà con i motori di ricerca, che sono così capaci di leggere il contenuto delle nostre pagine senza dover eseguire localmente alcun codice JavaScript.

Il SSR può essere incluso nella nostra app Angular nel momento stesso di creazione del progetto, semplicemente rispondendo yes quando richiesto dalla CLI; questa feature può essere abilitata in qualunque momento usando la CLI:

ng add @angular/ssr

Su questa feature di Angular non c’è molto da dire in termini di sviluppo: non si tratta di qualcosa che il framework mette a disposizione per implementare delle funzionalità applicative, ma più di una caratteristica tecnica delle applicazioni prodotte, della quale dobbiamo tenere conto se non vogliamo incappare in problematiche ad essa annesse.

Iniziamo elencando i file interessati:

• server.ts inizializza un’istanza di Express.js e la configura per servire la prima pagina già renderizzata;
• main.server.ts serve semplicemente ad indicare qual è il componente di avvio (AppComponent) e la configurazione;
• app.config.server.ts è un omologo di app.config.ts che contiene soltanto la parte di configurazione dedicata al SSR.

Questi file non necessitano di modifiche o customizzazioni a meno di esigenze specifiche, ma ovviamente avendo a disposizione un’istanza completa di Express.js possiamo andare ad aggiungere routing lato server, gli endpoint di una web API, tutto quello che vogliamo.

In realtà abbiamo già visto anche come evitare di incappare in problemi quando si creano dei componenti che devono essere eseguibili potenzialmente sia lato client, sia lato server: negli esempi precedenti abbiamo implementato logiche client usando lo speciale hook afterNextRender; ebbene attraverso questo hook possiamo avere accesso alle API del browser con la certezza che queste API non verranno mai chiamate durante il render della pagina a backend.

Usando afterNextRender possiamo accedere a localStorage come abbiamo già visto, ma anche a tutte le API esposte dal browser che fanno direttamente riferimento al dispositivo che esegue l’applicazione, come window, document, navigator or location.