Ultimamente ho provato Universal in un progetto Angular. Si tratta della risposta di Angular al concetto di Server Side Rendering (SSR), una tecnica utilizzata principalmente per scopi SEO, anche se in alcuni casi offre un vantaggio "percepito" in termini di prestazioni.
Quando si carica un sito web SSR, Angular esegue il rendering completo (o semi-completo) della pagina sul server, restituendo l'HTML che i motori di ricerca (e altri bot) possono indicizzare con maggiore efficacia.
Il termine "percepito" è utilizzato per esprimere il fatto che, poiché la pagina è solo semi-renderizzata, l'utente non è consapevole della visualizzazione iniziale dello schermo che di solito viene percepita durante l'utilizzo delle normali applicazioni Angular. A prescindere dalla mia opinione personale, questo metodo sembra offrire un'apertura dell'app più "completa" rispetto a quella di una normale applicazione Angular.
In apparenza tutto ciò sembra logico, ma in realtà, se dovessi fare una ricerca casuale su quante persone stanno adottando Angular Universal in un ambiente di produzione, difficilmente riusciresti a trovare molti esempi. Quasi tutti le guide in cui mi sono imbattuto, potrebbero essere considerati equivalenti al tutorial "Hello World"... Anche se non pretendo di essere un esperto di Angular Universal in quanto tale, mi sono sentito in dovere di andare oltre le offerte di tutorial di base per presentare vari aspetti che troppo spesso vengono tralasciati.
Il supporto della community è insufficente
La prima cosa che probabilmente impari quando si utilizza Universal è che quando la pagina è renderizzata sul server, non si ha accesso a un paio di paradigmi javascript veramente importanti. Ad esempio non è possibile accedere all'oggetto window, dal momento che questo si riferisce alla finestra del browser e non c'è uno quando si effettua il rendering lato server. Non è possibile accedere a cose come il local storage o qualsiasi memoria che possa esistere all'interno di una finestra del browser come sessione storage. Anche i cookie sono un problema per ovvie ragioni.
Angular consiglia di avvolgere le funzionalità che devono accedere a questi oggetti all'interno di un metodo chiamato isPlatformBrowser in modo che tu possa controllare se in quel momento stai facendo il rendering lato server o se lo stai facendo in un browser.
Che ne dici di una libreria di autenticazione che utilizza localStorage? Come MSAL libreria da Microsoft che consente alla tua applicazione javascript di interagire con Azure AD. Hanno un grande pacchetto Angular che rende l'autenticazione semplicissima. Ma ovviamente non esiste niente del genere e bisogna avvolgere tutto nei controlli del browser. Perché qualcuno dovrebbe sviluppare una simile libreria quando pochissime persone utilizzano Angular Universal?
E ho incontrato questo stesso problema tante volte. Anche solo le librerie che cercano di accedere all'oggetto della finestra (che deve essere abbastanza comune in javascript), esplodono completamente all'interno di Angular Universal. Naturalmente, è sempre possibile forkare il codice o cercare di aggiungere un controllo su isPlatformBrowser, ma il punto è che tutte quelle librerie che erano plug and play sul vostro progetto improvvisamente diventano complicatissime da integrare.
Lo sviluppo è estremamente lento
Ammettiamolo, la creazione di funzionalità per Angular Universal può essere veramente frustrante. Eseguendo "ng serve" su una semplice applicazione Angular si ottiene un'esperienza di sviluppo rapida, con funzionalità che si ricompilano in pochi secondi. Ma ho riscontrato che Angular Universal è l'esatto contrario: spesso la ricompilazione richiede quasi lo stesso tempo della creazione iniziale.
Il debug delle applicazioni Angular Universal è incredibilmente complicato e spesso frustrante. Tieni presente che è solo la richiesta *iniziale* che viene renderizzata lato server. Quando navighi nel sito, torni alla solita applicazione Angular lato client e tutto avviene nel browser. Ma i comuni strumenti di debug come console.log() sono difficili da seguire, perché se si tratta di una richiesta iniziale, il log viene scritto sul server, non nel browser. Tutti i log successivi saranno poi nella console del browser. Lo stesso vale per qualsiasi altra cosa tu possa usare per il debug. La richiesta iniziale è come il debug di una tipica applicazione Express, ma tutto il resto può essere debuggato dal lato client. Per uno sviluppatore alle prime armi questo approccio non è un compito facile.
La documentazione è inadeguata
E infine, la documentazione è terribile. Angular Universal ha una (1....) pagina di documentazione qui: https://angular.io/guide/universal. Finito. Non so quanto sia difficile fornire un esempio di un'app Angular Universal, ma non esiste.
A parte la documentazione ufficiale, in genere ci si affida ad altri esempi e post di blog che girano per il web e che non fanno altro che scalfire la superficie di ciò che Angular Universal è in grado di fare. Se trovi qualche ostacolo, sei praticamente da solo perché, da quello che ho visto, nessuno utilizza Angular Universal per scopi commerciali significativi (anche se sarei felice di essere smentito!).
Dovresti usare Angular Universal?
Per ora, credo fermamente nell'uso appropriato della tecnologia per lo scopo prefissato. Se hai bisogno di un rendering lato server, ti sconsiglio di utilizzare un framework JavaScript lato client per questo compito. Sebbene sia possibile convertire qualsiasi applicazione in Angular Universal, la gestione di progetti di grandi dimensioni si rivelerà difficile e ti rallenterà notevolmente. Ti renderai subito conto che, sebbene Universal possa essere un'interessante prova di concetto, non è all'altezza della fattibilità commerciale.
