SSR in Angular

Spiegare il server-side rendering in modo facile? Ci pensa Soumaya Erradi, che in questo articolo spiega quali sono le ultime novità in Angular che non solo supportano questa modalità di lavoro, ma che prevedono l’adozione di funzionalità come l’hydration.

Il rendering lato server (SSR) è diventato fondamentale nello sviluppo frontend, come riflesso di una tendenza verso l’ottimizzazione delle applicazioni web in termini di prestazioni, accessibilità ed esperienza utente. La capacità di SSR di fornire pagine HTML pre-renderizzate dal server migliora i tempi di caricamento iniziale, cruciali per gli utenti su reti o dispositivi più lenti. Ciò migliora l’esperienza dell’utente e riduce la frequenza di rimbalzo.

Cosa vedrai

• Angular Universal
  • Installa Angular Universal
• Hydration
  • Configurazione
• Angular 17
• Angular 18+
• Conclusione

Il SSR potenzia la SEO rendendo i contenuti più facili da scansionare e indicizzare per i motori di ricerca, portando a una migliore visibilità e a un posizionamento più elevato.

Garantendo un’esperienza utente veloce, affidabile e coerente su diversi dispositivi e condizioni di rete, SSR migliora il coinvolgimento e la fidelizzazione. Rende inoltre il Web più inclusivo, in particolare per gli utenti con un supporto JavaScript limitato. SSR ottimizza l’utilizzo delle risorse spostando il rendering dal client al server, migliorando le prestazioni e consentendo una gestione efficiente delle risorse. Le pagine renderizzate lato server possono essere facilmente memorizzate nella cache, migliorando i tempi di caricamento e riducendo il carico del server.

SSR migliora la sicurezza elaborando dati sensibili sul server, mitigando i rischi associati al rendering lato client. Questa elaborazione lato server aiuta a prevenire attacchi che sfruttano le vulnerabilità lato client. Nonostante l’evoluzione degli standard web e delle aspettative degli utenti, l’SSR rimane essenziale per offrire esperienze web veloci, fluide e sicure, garantendo che i contenuti vengano distribuiti in modo rapido e affidabile su tutti i dispositivi e condizioni di rete. Storia di SSR e Angular

All’inizio, lo sviluppo web dipendeva fortemente dalle tecnologie lato server come PHP, Java, Ruby e ASP.NET per il rendering dei contenuti. Il rendering lato server (SSR) era l’obiettivo principale in quest’epoca, poiché il rendering lato client non era comune.

Tuttavia, circa un decennio dopo, la tendenza si è spostata drasticamente verso il rendering lato client. Framework e librerie per applicazioni a pagina singola (SPA) come AngularJS sono diventati popolari e SSR sembrava essere una cosa del passato. Durante questo periodo la maggior parte delle attività di rendering lato client venivano gestite da applicazioni JavaScript.

Angular, lanciato nel 2010 come AngularJS, è stato creato in quest’era incentrata sulle SPA. Sebbene il team di Angular abbia menzionato l’esplorazione iniziale delle capacità SSR, alla fine ha rinunciato a questi sforzi. Ritenevano che il miglioramento delle prestazioni lato client potesse soddisfare le esigenze tradizionali di SSR, in particolare SEO e prestazioni di caricamento iniziale.

Nonostante lo scetticismo iniziale, l’importanza della SSR è riemersa. SSR è stato introdotto tramite Angular Universal soprattutto per la sua importanza per le prestazioni e il SEO.

Angular Universal

Jeff Whelpley ha sviluppato Angular Universal per abilitare il rendering lato server. Le applicazioni Angular possono migliorare i tempi di caricamento iniziale, il SEO e le prestazioni generali eseguendo il rendering sul server e inviando pagine completamente renderizzate al client.

Per implementare SSR in un’applicazione Angular utilizzando Angular Universal, segui questi passaggi:

Installa Angular Universal

ng add @nguniversal/express-engine

Questo comando configura Angular Universal con un server Express.

La CLI Angular crea i file necessari, inclusi main.server.ts e server.ts.

// main.server.ts

import { enableProdMode } from '@angular/core';
import { environment } from './environments/environment';
import { AppServerModule } from './app/app.server.module';
import { ngExpressEngine } from '@nguniversal/express-engine';
import { provideClientHydration } from '@angular/platform-server';

if (environment.production) {
enableProdMode();
}

export { AppServerModule } from './app/app.server.module';

export { renderModuleFactory } from '@angular/platform-server';

// server.ts
import 'zone.js/node';
import { ngExpressEngine } from '@nguniversal/express-engine';
import * as express from 'express';
import { join } from 'path';

import { AppServerModule } from './src/main.server';
import { APP_BASE_HREF } from '@angular/common';
import { existsSync } from 'fs';

export function app(): express.Express {
    const server = express();
    const distFolder = join(process.cwd(), 'dist/your-project-name/browser');
    const indexHtml = existsSync(join(distFolder, 'index.original.html')) ? 'index.original.html' : 'index';

    server.engine('html', ngExpressEngine({
        bootstrap: AppServerModule,
    }));

    server.set('view engine', 'html');
    server.set('views', distFolder);

    server.get('*.*', express.static(distFolder, {
        maxAge: '1y'
    }));

    server.get('*', (req, res) => {
        res.render(indexHtml, { req });
    });

    return server;
}

function run(): void {
    const port = process.env.PORT || 4000;

    const server = app();
    server.listen(port, () => {
        console.log(`Node Express server listening on http://localhost:${port}`);
    });
}

declare const __non_webpack_require__: NodeRequire;
const mainModule = __non_webpack_require__.main;
const moduleFilename = mainModule && mainModule.filename || '';
if (moduleFilename === __filename || moduleFilename.includes('iisnode')) {
    run();
}

export * from './src/main.server';

Crea un file app.server.module.ts per includere moduli specifici del server come di seguito, e hai fatto!

import { NgModule } from '@angular/core';
import { ServerModule } from '@angular/platform-server';
import { AppModule } from './app.module';
import { AppComponent } from './app.component';

@NgModule({
imports: [
AppModule,
ServerModule,
],
bootstrap: [AppComponent],
})
export class AppServerModule {}

Hydration

L’SSR è stato notevolmente migliorato con il rilascio di Angular 16, in particolare con l’arrivo del concetto di hydration. Quando SSR veniva utilizzato dalle applicazioni Angular, il server inviava una pagina HTML completamente renderizzata al client. Questo codice HTML renderizzato dal server verrebbe distrutto da Angular e ri-renderizzato sul lato client, con quindi un calo prestazionale.

Con l’introduzione dell’hydration in Angular 16, il client può riutilizzare l’HTML generato dal server invece di scartarlo e generarlo nuovamente. Riducendo il processo di rendering ridondante, si migliorano le prestazioni e la velocità delle applicazioni Angular.

È facile implementare l’hydration in Angular 16: questa può essere abilitata per chi sviluppa fornendo una configurazione specifica all’interno dell’applicazione Angular.

Configurazione

Nella tua applicazione Angular, aggiungi il provider provideClientHydration per abilitare l’hydration.

import { provideClientHydration } from '@angular/platform-server';

providers: [
provideClientHydration(),
// ...
]

Angular 17

Le funzionalità di rendering lato server (SSR) e hydration lato client sono state ulteriormente migliorate dal team di Angular con il rilascio di Angular 17. Questi aggiornamenti riflettono un impegno continuo nell’ottimizzazione delle prestazioni, nel miglioramento dell’esperienza di sviluppo e nel garantire che Angular rimanga un framework robusto per applicazioni web moderne.

La stabilizzazione e il miglioramento dell’hydration, in particolare, sono una delle caratteristiche principali di Angular 17. Nelle versioni precedenti, sebbene l’SSR e l’hydration di base fossero supportati, non erano completamente ottimizzati per l’uso in produzione. Angular 17 ha risolto questi problemi, garantendo che l’hydration sia stabile e affidabile per gli ambienti di produzione.

Questa funzionalità in Angular 17 garantisce che l’HTML pre-renderizzato dal server non venga “scartato” quando raggiunge il client. Invece, l’applicazione Angular lato client può riutilizzare questo HTML allegando i diversi gestori di eventi e reidratando il contenuto dinamico senza eseguire nuovamente il rendering del tutto.

Angular 17 ha inoltre semplificato il processo di creazione della SSR. In precedenza, chi sviluppa doveva installare e configurare Angular Universal separatamente. Angular 17 ha portato Angular Universal direttamente nella CLI Angular, semplificando il processo di configurazione. SSR può essere abilitato utilizzando un unico comando, il che lo rende più accessibile e più facile da implementare.

Per creare un’applicazione abilitata SSR fin dall’inizio, è possibile utilizzare il seguente comando:

ng new my-app --ssr

Se SSR non era stato abilitato inizialmente, può essere aggiunto a un progetto esistente con il comando:

ng add @angular/ssr

Questi comandi configurano le dipendenze e i file necessari, come server.tse main.server.ts, automaticamente, riducendo la configurazione manuale richiesta nelle versioni precedenti.

Angular 18+

Angular 18 introduce miglioramenti significativi nel rendering lato server (SSR) e nell’idratazione, concentrandosi sull’ottimizzazione delle prestazioni e su una migliore esperienza.

• Supporto all’internazionalizzazione : Angular 18 ora include il supporto dell’anteprima per sviluppatori per l’internazionalizzazione all’interno di SSR, risolvendo i problemi precedenti. chi sviluppa può abilitare questa funzionalità utilizzando withInternationalizationSupport nel provider provideClientHydration.
• Riproduzione dell’evento : La nuova funzionalità di riproduzione degli eventi registra le interazioni dell’utente, come clic e doppi clic, durante la fase di idratazione e le riproduce una volta completata l’idratazione. Ciò garantisce un’esperienza utente più fluida e può essere abilitato nel provider provideClientHydration con withEventReplay.
• Miglioramenti nel package di Angular Material : I passaggi iniziali verso l’integrazione dei componenti Angular Material con SSR sono inclusi in questa versione. Sebbene siano ancora in anteprima, queste funzionalità sembrano promettenti per il pieno supporto negli aggiornamenti futuri.

Conclusione

Angular 17 ha segnato progressi significativi nell’SSR e nell’hydration, integrando Angular Universal nella CLI principale e stabilizzando l’idratazione. Guardando al futuro, sicuramente Angular 18+ continuerà a migliorare queste funzionalità, concentrandosi su prestazioni migliorate, Develeoper Experience e funzionalità del framework ampliate. Questi progressi garantiscono che Angular rimanga un framework leader per la creazione di applicazioni web dinamiche e ad alte prestazioni, soddisfacendo le esigenze in evoluzione sia di chi sviluppa, che di chi lo utilizza.

Post originale su [dev.to](https://dev.to/soumayaerradi/angular-ssr-in-2024-42cl)