Torniamo a noi e prima di chiudere il discorso tecniche di recupero dei dati cerchiamo di dare una risposta al commento di Raffaele.
Commento che sottolinea che mi sono dimenticato di una cosa di cui ho parlato al compleanno di UGI e evidenzia come sia fondamentale la storia che vogliamo raccontare, storia che nel caso di questi post su UI Composition non è abbastanza ben definita, piuttosto, si sta trasformando mano a mano che li scrivo.
Ciao Mauro, leggo con piacere questa serie ma la domanda mi sorge spontanea.
In questo caso, non avrebbe senso esporti in GET una Projection, magari un bel DTO che rappresenta la tua riga template di dati da visualizzare?
Sbagliato?
No. Come ho già detto più volte quando si parla di architettura, in particolare, non ci sono scelte giuste o scelte sbagliate. Le scelte sono da calare in un contesto e in base al contesto possiamo fare valutazioni.
Se ho ben compreso il commento di Raffaele, nel caso sono più che lieto di essere smentito, possiamo rappresentare la cosa in questo modo:
Il diagramma li sopra funziona alla perfeziona, ma:
- Ci obbliga ad introdurre un attore che non ha nulla a che con il business ma ha solo un ruolo tecnico, alla fine è una sorta di enorme cache;
- Introduce un “single point of failure” obbligandoci a rendere quell’elemento altamente disponibile, cosa non necessariamente semplice;
- Ci obbliga ad abbracciare il concetto di consistenza eventuale;
- Ci impone di introdurre nuova infrastruttura per capire come “sincronizzare” i dati;
- Complica un po’ le cose quando le strutture dati evolvono perché dobbiamo introdurre trasformazioni da qualche parte nel processo di sincronizzazione;
Sono tutti ma che ovviamente non sono bloccanti, dobbiamo però comprenderli e valutarli nel nostro contesto. Non sono a priori sbagliati. Uno solo è particolarmente rognoso a mio modo di vedere.
Consistenza eventuale
La consistenza eventuale è in alcuni scenari probabilmente un male necessario, ma se possiamo evitare il problema tout court è decisamente meglio. Diciamo che abbiamo fatto i compiti a casa e:
- la in mezzo ci abbiamo messo un bel cluster di Elastic Search, nel caso leggere:
- Abbiamo trovato un modo per sincronizzare i dati dai servizi verso Elastic Search
- Il nostro client legge le projection presenti in Elastic Search
- Siamo stati fighi e le projection ci dicono anche quando sono state aggiornate l’ultima volta
Cosa non sappiamo?
Non sappiamo se la sorgente ha un’informazione più aggiornata e se quello che vediamo noi sia quindi l’ultima informazione disponibile o meno. Abbiamo quindi necessariamente a che fare con dati definiti stale con poche, o nessuna, informazioni per aiutarci a gestire lo scenario.
Infine se diamo un’occhiata a come abbiamo ipotizzato i nostri servizi:
- SAP, interno
- Interno / API e hosting condivisi (o condivisibili)g
- terze parti
Ci scontriamo con il dettaglio che tutti i servizi devono poter dialogare con il “robo” centrale, cosa sicuramente fattibile ma anche in questo caso è necessario valutare bene se il gioco vale la candela.
Services UI Composition
Ecco perché in molte realtà si sta cominciando ad affrontare il problema partendo da un angolo diverso, chiedendosi se non sia possibile eliminare in toto i possibili problemi di cui sopra spostandosi verso un approccio come il seguente:
Questa serie di post mira a approfondire questo secondo approccio, evidenziando pro e contro perché ovviamente non è tutto oro quel che luccica. Le realtà che fino ad oggi ho supportato in questo approccio sono “scappate” da quello precedente perché al crescere intrinseco dei sistemi e delle realtà stesse l’approccio di prima stava cominciando a vacillare.
Post in questa serie:
Piccolo spazio pubblicità:
Tratterò di questi temi in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.