Al momento è in corso una riscrittura del sito con una nuova architettura però teniramo in considerazione anche altre possibili architetture con pro e contro.
Go + Vite JS – Questa è quella nuova già work in progress. È molto comoda in fase di development dato che supporta molto bene il live reload di tutto quanto.
In breve la frontend è generata con ViteJS e la backend è fatta tutta in Go con fiber come framework HTTP. Inoltre c'è del codice che permette di definire tutti gli entrypoint HTML per ViteJS direttamente una volta sola in Go.
Inoltre grazie a questa integrazione anche lo sviluppo è molto reattivo. L'unica cosa leggermente più complicata è per quanto riguarda le pagine dinamiche lato server.
Go + Astro – Magari si potrebbe fare un'architettura più stile JAM stack ovvero con una frontend completamente statica e la beckend in Go. In teoria in questo modo senza troppa integrazione tra le due parti dovrebbe già funzionare tutto abbastanza bene.
L'unica cosa è che questa architettura non ci permette di avere views generate attraverso template dal Go. In realtà questa potrebbe effettivamente essere una buona cosa e non una cosa a sfavore...
Go + htmx – Questa potrebbe essere interessante perché significherebbe avere un sito molto leggero dal punto di vista del js. Ed in particolare si potrebbe usare anche altro e non per forza htmx, ad esempio una cosa in house.
D'altra parte aumenterebbe il numero di round trip con il server per fare anche cose abbastanza semplici.
Ad esempio sarebbe meglio fare la ricerca utenti tutta in JS lato client e non parlando sempre con il server, specialmente per fare ricerche fuzzy in live.
Glossario:
views: quando un utente richiede una pagina in certi tipi di architetture di backend generalmente ci sono dei template (ad esempio scritti in: go template, handlebars, ejs, ...) che vengono renderizzati a delle pagine html e questi template sono chiamati "views".
Al momento è in corso una riscrittura del sito con una nuova architettura però teniramo in considerazione anche altre possibili architetture con pro e contro.
- Go + [Vite JS](https://vitejs.dev/) – Questa è quella nuova già _work in progress_. È molto comoda in fase di development dato che supporta molto bene il live reload di tutto quanto.
In breve la frontend è generata con ViteJS e la backend è fatta tutta in Go con fiber come framework HTTP. Inoltre c'è del codice che permette di definire tutti gli _entrypoint_ HTML per ViteJS direttamente una volta sola in Go.
Inoltre grazie a questa integrazione anche lo sviluppo è molto reattivo. L'unica cosa leggermente più complicata è per quanto riguarda le pagine dinamiche lato server.
- Go + [Astro](https://astro.build/) – Magari si potrebbe fare un'architettura più stile _JAM stack_ ovvero con una frontend completamente statica e la beckend in Go. In teoria in questo modo senza troppa integrazione tra le due parti dovrebbe già funzionare tutto abbastanza bene.
L'unica cosa è che questa architettura non ci permette di avere _views_ generate attraverso template dal Go. In realtà questa potrebbe effettivamente essere una buona cosa e non una cosa a sfavore...
- Go + [htmx](https://htmx.org/) – Questa potrebbe essere interessante perché significherebbe avere un sito molto leggero dal punto di vista del js. Ed in particolare si potrebbe usare anche altro e non per forza _htmx_, ad esempio una cosa [_in house_](https://git.phc.dm.unipi.it/phc/sito-credenziali/src/branch/main/_public/live-html.js).
D'altra parte aumenterebbe il numero di _round trip_ con il server per fare anche cose abbastanza semplici.
Ad esempio sarebbe meglio fare la ricerca utenti tutta in JS lato client e non parlando sempre con il server, specialmente per fare ricerche fuzzy in live.
**Glossario:**
- _views_: quando un utente richiede una pagina in certi tipi di architetture di backend generalmente ci sono dei template (ad esempio scritti in: go template, handlebars, ejs, ...) che vengono renderizzati a delle pagine html e questi template sono chiamati "views".
aziis98
added this to the v2.0 project 2 years ago
Al momento è in corso una riscrittura del sito con una nuova architettura però teniramo in considerazione anche altre possibili architetture con pro e contro.
Go + Vite JS – Questa è quella nuova già work in progress. È molto comoda in fase di development dato che supporta molto bene il live reload di tutto quanto.
In breve la frontend è generata con ViteJS e la backend è fatta tutta in Go con fiber come framework HTTP. Inoltre c'è del codice che permette di definire tutti gli entrypoint HTML per ViteJS direttamente una volta sola in Go.
Inoltre grazie a questa integrazione anche lo sviluppo è molto reattivo. L'unica cosa leggermente più complicata è per quanto riguarda le pagine dinamiche lato server.
Go + Astro – Magari si potrebbe fare un'architettura più stile JAM stack ovvero con una frontend completamente statica e la beckend in Go. In teoria in questo modo senza troppa integrazione tra le due parti dovrebbe già funzionare tutto abbastanza bene.
L'unica cosa è che questa architettura non ci permette di avere views generate attraverso template dal Go. In realtà questa potrebbe effettivamente essere una buona cosa e non una cosa a sfavore...
Go + htmx – Questa potrebbe essere interessante perché significherebbe avere un sito molto leggero dal punto di vista del js. Ed in particolare si potrebbe usare anche altro e non per forza htmx, ad esempio una cosa in house.
D'altra parte aumenterebbe il numero di round trip con il server per fare anche cose abbastanza semplici.
Ad esempio sarebbe meglio fare la ricerca utenti tutta in JS lato client e non parlando sempre con il server, specialmente per fare ricerche fuzzy in live.
Glossario:
Probabilmente faremo la cosa con Go + Astro