Ultimanete 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.
Quando parlo di prestazioni "percepite", mi riferisco al fatto che, essendo almeno semi-renderizzata, l'utente non vede un flash di una schermata vuota come accade normalmente con le normali app Angular. Personalmente non credo che restituisca la pagina completa più velocemente di una normale app Angular, ma la prima visualizzazione è più "completa" di quella di una normale app 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 imparerai quando utilizzi Universal è che durante il rendering della pagina sul server, non hai accesso a un paio di paradigmi JavaScript molto importanti. Ad esempio, non puoi accedere all'oggetto window, poiché si riferisce alla finestra del browser e questa non è disponibile durante il rendering lato server. Non è possibile accedere a elementi come il local storage o a qualsiasi altra memoria che potrebbe esistere all'interno di una finestra del browser, come la session storage. Anche i cookie presentano problematiche per ovvi motivi.
Angular suggerisce di avvolgere le funzionalità che necessitano di accedere a questi oggetti all'interno di un metodo chiamato isPlatformBrowser, così da poter verificare se si sta eseguendo il rendering lato server o nel browser.
Sarebbero utili librerie di autenticazione che utilizzano localStorage, ma ovviamente una cosa del genere non esiste e è necessario avvolgere tutto nei controlli del browser. Perché qualcuno dovrebbe sviluppare una simile libreria quando poche persone utilizzano Angular Universal?
Ho riscontrato lo stesso problema molte volte. Anche solo le librerie che cercano di accedere all'oggetto window (che deve essere abbastanza comune in JavaScript) si rompono completamente all'interno di Angular Universal. Naturalmente, è possibile fare il fork del codice o cercare di aggiungere un controllo su isPlatformBrowser, ma il punto è che tutte quelle librerie che erano plug and play nel tuo progetto diventano improvvisamente molto complicate 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.
