Ciao, e benvenuto nell'ottava puntata della settantottesima stagione. Fin qui abbiamo pagato onestamente i costi del rendering lato server. Oggi le leve pratiche che lo rendono sostenibile, le due mosse che trasformano un rendering caro a ogni richiesta in qualcosa di economico su larga scala: tenere piatti pronti, e cucinare più vicino a chi guarda. Il titolo: il vassoio e la cucina di quartiere.
Il costo da attaccare. Cucinare a ogni richiesta è caro. Ogni persona che chiede fa cucinare alla cucina l'intero piatto da zero: esegui i componenti, prendi i dati, costruisci l'HTML. Mille persone, mille cotture. Su una pagina popolare, la cucina rifà la stessa cottura più e più volte. Due leve pratiche tagliano questo.
Leva uno: il vassoio pronto, cioè l'asse del tempo. Se tante persone vogliono lo stesso piatto, non cucinarlo fresco ogni volta: cucinalo una volta e tieni delle copie impiattate su un vassoio caldo, consegnandole all'istante. È la pagina resa, tenuta in cache. E questo apre l'asse del quando della prima puntata. Primo: cucinare in anticipo, per tutti. Se una pagina è uguale per tutti e cambia di rado, un articolo, una pagina di documentazione, cucinala una volta in fase di costruzione e servi la copia impiattata a tutti, per sempre, finché non ricostruisci. Il più veloce possibile, il più economico possibile: la cucina quasi non lavora al momento della richiesta. Secondo: cucinare su ordinazione. Se una pagina è diversa per ogni persona o deve essere fresca, un flusso personalizzato, un prezzo dal vivo, la cucini ogni volta. Il più caro, il più fresco. Terzo: ri-cuocere con una cadenza. La via di mezzo: servi una copia dal vassoio, ma la ri-cucini di tanto in tanto, ogni minuto, ogni ora, così non diventa mai troppo vecchia. Chi guarda ha la velocità istantanea del vassoio, e il contenuto non è mai più vecchio di un po'. Ottieni quasi la velocità dell'anticipo con un po' della freschezza dell'ordinazione.
Quindi quando cucino questa? ha tre risposte oneste, in anticipo, su ordinazione, o con una cadenza di aggiornamento, e scegliere per ogni pagina è gran parte del rendere sostenibile il rendering lato server. Qui torna la stagione sulla cache, con il suo problema difficile: quando il piatto cambia, devi buttare i vassoi ormai vecchi, e sapere esattamente quando è notoriamente scivoloso.
Leva due: la cucina di quartiere, cioè l'asse dello spazio. L'altro costo è la distanza. Se l'unica cucina centrale è lontana da chi guarda, un oceano in mezzo, perfino un piatto già pronto ci mette a viaggiare. Allora metti cucine satellite in tanti quartieri, vicino a chi guarda ovunque sia, e servi dalla più vicina. È rendere e tenere in cache ai bordi: fai girare il rendering, o almeno custodisci le pagine già pronte, in posti vicini alle persone in tutto il mondo, così il viaggio è corto. Cucine vicine tagliano il tempo di viaggio che nessuna velocità di cottura può aggiustare.
Come si combinano, ed è il quadro pratico. Mettile insieme e il rendering lato server diventa economico e veloce: cucina le pagine popolari in anticipo o con una cadenza, tieni le copie impiattate su vassoi caldi nelle cucine di quartiere vicino a ogni persona, e ricadi sul cucinare su ordinazione nella cucina centrale solo per le pagine davvero personali o davvero dal vivo. Così quasi tutte le richieste sono servite all'istante da un vassoio vicino, senza mai toccare la costosa cottura centrale. Il caro rendering a ogni richiesta diventa l'eccezione, non la regola.
I limiti onesti, per restare equilibrati. La parte difficile della cache è il rancido: servi dal vassoio troppo a lungo e chi guarda riceve notizie vecchie; butti i vassoi troppo in fretta e sei di nuovo a cucinare ogni volta. Le pagine personalizzate o sensibili non possono stare su un vassoio condiviso per niente, non puoi consegnare la pagina dell'account di una persona a un'altra. E la cucina di quartiere è più piccola, lontana dalla dispensa centrale, cioè dalla base di dati, quindi un rendering pieno di dati ai bordi ha il suo problema di viaggio. Le leve sono potenti esattamente dove il contenuto è condiviso e stabile; svaniscono dove è personale e dal vivo.
Voglio lasciarti con le due leve che rendono sostenibile il rendering lato server. La prima è il tempo: non cucinare la stessa pagina a ogni richiesta se puoi cucinarla una volta e servirla da un vassoio pronto, scegliendo per ogni pagina se cuocerla in anticipo, su ordinazione, o ri-cuocerla con una cadenza. La seconda è lo spazio: non cucinare sempre in una cucina centrale lontana se puoi tenere cucine di quartiere vicino a chi guarda. Insieme trasformano il costoso rendering a ogni richiesta nell'eccezione, non nella regola. La domanda pratica, per ogni pagina, è sempre la stessa: quanto spesso cambia, e per quante persone è uguale? Più è stabile e condivisa, più la servi da un vassoio vicino; più è viva e personale, più la cucini al momento.
Per oggi ci fermiamo qui. Abbiamo attaccato il costo del cucinare a ogni richiesta con due leve: il vassoio, cioè la cache, con le tre risposte al quando, in anticipo, su ordinazione, con una cadenza; e la cucina di quartiere, cioè i bordi, per tagliare la distanza. Le abbiamo combinate per rendere l'eccezione il rendering costoso, e detto i limiti, il rancido e le pagine personali. Nella prossima puntata: non tutto va servito caldo. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.