Skip to main content

Implementazione tra Core e Feature

🚧 BOZZA

In questa sezione è descrtta la implementazione tra moduli Core e moduli Feature.

🧠 Concetti chiave​

L’implementazione e la connessione tra il modulo core e i moduli feature che verrà implementata ha come obiettivi principali:

  • Gestire correttamente la creazione di entità presenti nei moduli feature partendo dal core
  • Definire i passaggi necessari lato frontend e backend per offrire all’utente una navigazione quanto più fluida possibile.

Uno dei problemi principali da risolvere riguarda la situazione in cui, partendo dal core, l’utente accede al dettaglio di un’entità che ancora non esiste nel modulo feature (ad esempio un contratto di appalto).
In questo scenario, la creazione dell’entità avviene nel modulo feature, mentre il modulo core registra la relazione tra la commessa (salvata nel core) e l’entità creata.

I passaggi che avvengono sono i seguenti:

  1. Modulo core → riceve la richiesta dell’utente e verifica che l’entità non esista. Poiché l’entità non è ancora presente, viene avviato il processo di creazione nel modulo feature.
  2. Modulo feature → viene creata la nuova entità.
  3. Modulo core → salva la relazione tra la commessa e l’entità creata.
  4. Redirect → una volta completata la creazione e la relazione, il frontend viene reindirizzato verso la pagina di dettaglio dell’entità, che appartiene al modulo feature.
  5. Modulo feature → il sistema recupera i dati dell’entità appena creata e li restituisce al frontend.
  6. Frontend → viene mostrata la pagina di dettaglio con le informazioni necessarie.

Sia il punto 2 (creazione), sia il punto 3 (registrazione), sia il punto 5 (recupero e restituzione dei dati) possono richiedere tempo, con il rischio di mostrare due loader distinti che spezzerebbero la continuità della navigazione.

Per risolvere questo problema, abbiamo scelto di utilizzare l’SSR (Server-Side Rendering). L’SSR consiste nel far generare la pagina dal server invece che dal client: il server esegue le operazioni necessarie (es. creazione dell’entità e recupero dei dati) e restituisce già al browser la pagina completa e pronta da mostrare all’utente, permettendo di mostrare un unico caricamento continuo, dal core fino al dettaglio nel feature, rendendo invisibili i passaggi intermedi.

Questo approccio è utile per la nostra idea perché:

  • Esperienza fluida → invece di due loader separati (uno sul core e uno sul feature), l’utente percepisce un unico caricamento, continuo e coerente.
  • Navigazione unificata → l’utente non nota lo “switch” tra core e feature: il passaggio avviene dietro le quinte ed è trasparente.
  • Prestazioni percepite migliori → il client riceve una pagina già renderizzata, riducendo i tempi di attesa e migliorando la percezione di velocità.
  • Coerenza architetturale → l’SSR permette di orchestrare i processi tra core e feature senza dover duplicare logiche di caricamento lato client.

Il risultato finale è una navigazione lineare e senza frizioni, dove la separazione tecnica tra core e feature rimane invisibile all’utente, che vive un’esperienza coerente all’interno del software.

Esempio di implementazione​

Un esempio concreto è la creazione di un Computo Metrico Commerciale, entità gestita dal modulo Template e Computi, ma che deve essere sempre collegata a una Commessa, entità invece gestita dal modulo core.

Il flusso è il seguente:

  1. Accesso dal modulo core: l’utente, partendo dal dettaglio di una commessa, richiede di visualizzare il computo metrico commerciale. Poiché questo non esiste ancora, il core avvia il processo di creazione.
  2. Creazione nel modulo Template e Computi: il backend del core richiede al modulo Template e Computi di creare un nuovo computo metrico commerciale. In questa fase viene generata l’entità all’interno del modulo feature.
  3. Registrazione relazione nel core: una volta creato il computo, il modulo core registra la relazione tra la commessa e il nuovo computo.
  4. Redirect al dettaglio: terminati i due passaggi precedenti, l’utente viene reindirizzato al dettaglio del computo, che risiede nel frontend del modulo Template e Computi.
  5. Recupero e visualizzazione dati: il modulo Template e Computi recupera i dati del nuovo computo e li restituisce al frontend, che mostra all’utente il dettaglio del computo appena creato.
  6. Gestione del caricamento con SSR: grazie all’SSR, tutti i passaggi appaiono come un unico caricamento continuo, evitando che l’utente veda più loader distinti e rendendo trasparente il passaggio tra core e feature.