React e i Server Components

Quando si parla di framework per lo sviluppo di applicazioni web moderne, una delle opzioni più diffuse e apprezzate è React. Di recente, il team di sviluppo ha mostrato in anteprima i Server Components, componenti che permettono agli sviluppatori di scrivere codice che sarà poi eseguito sul server, accelerando di conseguenza l'accesso ai dati e riducendo la quantità di codice che dovrà essere scaricato dal browser.

L'utilizzo di questo approccio, in determinati contesti, dovrebbe migliorare quindi le performance lato client. Ma a questo punto sorge una domanda: qual è la migliore prassi? Dovremmo fare in modo che le applicazioni eseguano la maggior parte del codice sul client, oppure sul server?

Client o server?

È una domanda a cui non è facile fornire una risposta precisa, ed è abbastanza plausibile prevedere che la scelta dipenderà anche dal modo in cui la tecnologia si evolverà nel tempo. D'altronde è proprio questo che abbiamo visto accadere nel tempo: le prime applicazioni web venivano eseguite principalmente sul server, ma le nuove connessioni più veloci, le maggiori possibilità offerte da JavaScript ed HTML5, e il nuovo hardware disponibile hanno spostato l'asticella della bilancia più verso il client.

L'arrivo di framework come React stesso, ma anche Angular o Vue, hanno poi reso più semplice la definizione di applicazioni web, a scapito però di un HTML più prolisso e meno bello.

L'ultimo trend è invece quello dei siti web statici, che utilizzano JavaScript per interrogare una serie di microservizi, caricando di volta in volta i contenuti dinamici. Ciò ha portato al fiorire di numerosi generatori di siti di questo tipo, quali Gatsby, Hugo e Next.js.

Il problema di siti e microservizi

Quest'ultimo scenario sembrerebbe proprio quello in cui l'uso dei Server Components potrebbe aiutare maggiormente. Immaginiamo, ad esempio, che un'applicazione richieda diverse query a database differenti, al fine di popolare opportunamente diversi componenti. Ciò può essere effettuato con un'unica chiamata, risultando però in una soluzione che, per quanto efficiente, non risulterebbe particolarmente pulita. Al contrario, se si scegliesse di far sì che ogni componente recuperi i dati necessari al suo funzionamento, si rischierebbe un forte impatto sulle prestazioni.

L'uso dei Server Components permette di risolvere il problema. Tutti i componenti di questo tipo, infatti, includono un file che viene eseguito via Node.js direttamente sul server, dove la latenza dovuta alla comunicazione con il DB è bassa e non impatta sulle prestazioni. Inoltre, le librerie React utilizzate per questi componenti non richiederebbero nemmeno di essere scaricate sul browser, con un grosso vantaggio prestazionale.

Va detto che l'uso dei Server Components non è da confondere con il rendering lato server, poiché quest'ultimo non produce una "traduzione" in HTML, bensì sfruttando un particolare formato, che sarà poi usato dal framework nell'aggiornamento dell'interfaccia utente in background.

Tra i numerosi vantaggi di questa soluzione, va menzionata la possibilità di accedere direttamente alle risorse di backend. A tale scopo, sono state introdotte nuove librerie, tra cui ad esempio react-pg, per l'accesso ad un database PostgreSQL, react-fs per lavorare con il file system, e react-fetch per effettuare chiamate verso API direttamente lato server.

Conclusioni

Oggi molti sviluppatori combinano React e altri framework JavaScript con applicazioni scritte per gestire la parte server (tipicamente sfruttando linguaggi diversi, come PHP o Java). I Server Components di React rendono invece quest'ultima tecnologia un'opzione potenzialmente full-stack. Sebbene questa tecnologia sia ancora in fase di sviluppo, il team sta lavorando insieme agli sviluppatori di Next.js, ed è quindi lecito aspettarsi novità significative a stretto giro.