SSR in produzione senza trasformarlo in un single point of failure
Timeout, fallback, processi Node e Docker: come rendere il rendering server-side un miglioramento e non un rischio.
L'SSR migliora il primo rendering, ma introduce anche un nuovo processo nell'architettura. Se quel processo diventa indispensabile per servire qualsiasi pagina, abbiamo semplicemente spostato il problema.
SSR deve essere degradabile
La regola che ho scelto è semplice: se il renderer server-side non è disponibile, il sito deve continuare a funzionare con il rendering client-side.
Questo cambia il modo in cui si progetta l'integrazione. SSR diventa un enhancement, non un requisito assoluto.
Il timeout è una feature
Una chiamata interna al renderer Node senza timeout adeguato può rallentare ogni pagina pubblica quando il processo è bloccato.
Meglio fallire velocemente e tornare al CSR che tenere una richiesta aperta per molti secondi.
Il timeout va quindi scelto pensando all'esperienza dell'utente, non soltanto alla tolleranza tecnica del client HTTP.
Il processo SSR
In produzione il renderer deve partire insieme all'applicazione ma avere un ciclo di vita controllato.
Ci sono varie opzioni:
- process manager dedicato;
- supervisor;
- sidecar separato;
- processo secondario avviato dall'entrypoint del container.
La scelta dipende dall'infrastruttura, ma l'obiettivo resta lo stesso: il processo deve poter ripartire senza trascinare giù l'app principale.
Limitare l'esposizione
Se il renderer serve esclusivamente per comunicazioni interne all'applicazione, non ha motivo di ascoltare su tutte le interfacce disponibili.
Ridurre la superficie di rete è una misura semplice: il servizio SSR dovrebbe essere raggiungibile soltanto da ciò che ne ha realmente bisogno.
La build Docker fa parte del test
Una build SSR che funziona sulla macchina di sviluppo non garantisce nulla sulla produzione.
Il container finale può avere un insieme di dipendenze molto più ridotto. Per questo la build reale dell'immagine deve diventare parte della verifica.
È il modo più rapido per scoprire alias mancanti, dipendenze disponibili soltanto in sviluppo o bundle non completamente autosufficienti.
Il fallback va testato
Non basta scrivere un catch. Bisogna simulare un renderer lento o irraggiungibile e verificare che:
- la risposta arrivi comunque;
- il tempo massimo resti accettabile;
- la pagina possa essere completata dal browser;
- l'errore SSR non diventi un errore applicativo.
Conclusione
Una buona implementazione SSR non è quella che funziona quando tutto è perfetto. È quella che fallisce bene.
Il renderer server-side deve migliorare SEO e first render, senza diventare un nuovo punto critico che può rendere indisponibile l'intera applicazione.