Una delle cose su cui ho stressato molto a Codemotion durante il workshop “Microservices development deep dive” e forse ancora di più nella maratona di 50 minuti all’evento KLab è quanto sia rischioso, in un sistema distribuito, condividere dati:
All’aumentare della condivisione perdiamo facilità di evoluzione.
La ricerca sembra essere uno di quegli argomenti/requisiti che può essere risolto solo ed esclusivamente con un calderone unico in buttare dentro tutto ciò che è cercabile.
Ma è veramente così?
Quando Google arrivò ed educò gli utenti che una ricerca poteva essere semplice e non necessariamente un incubo
Una parte del mondo esultò, una piccola parte (noi dev) cominciò a cercare spigoli di marmo su cui sbattere la fronte.
Cercare può essere molto complesso
Di primo acchito quando pensiamo ad un sistema distribuito e cerchiamo di immaginare la ricerca in tale modello pensiamo immediatamente di avere compreso cosa sia un ossimoro. Ma probabilmente non è proprio così.
Se state cercando una spedizione andrete da che gestisce le spedizioni, se state cercando un semi-lavorato probabilmente dal magazzino, se siete interessati a tutto ciò che ha a che fare con il cliente “Mauro” andrete dal CRM e poi con l’ID di Mauro da tutti gli altri.
Più complesso ovviamente se siete alla ricerca di tutto ciò che ha a che fare con “Mauro”, e gli ordini spediti il cui peso di spedizione sia compreso da X e Y. Distribuire questo secondo tipo di ricerca diventa un po’ più complesso, non impossibile, ma sicuramente più complesso.
Se in più ci mettete che magari volete paginare e ordinare ecco che le cose si fanno rognose, perché ad esempio paginazione distribuita è un simpatico incubo.
Andiamo con ordine
Prendiamo come esempio la ricerca di Amazon:
(il porta banana è il nostro esempio preferito :P)
Ci sono tante cose affascinanti che si possono dedurre (o ipotizzare) da come sono strutturati i risultati.
La prima domanda che ci possiamo fare è: chi è responsabile di quella ricerca?
Nel modello che abbiamo usato fino ad oggi in questa serie: Marketing.
Quindi Marketing inietta nella UI composta il form di ricerca:
A fronte di una richiesta Marketing riceve:
- il testo della query: portabanana
- l’ID della categoria, diciamo in questo caso <null> che identifica nessuna categoria specifica
Marketing fa la sua bella query full text, con qualsivoglia tecnologia volete e ritorna la lista di ID che soddisfano la ricerca. La visualizzazione dei risultati si risolve facile, è un caso comune di UI Composition.
Meno ovvio sembrano essere le facet sul lato sinistro:
La prima informazione che troviamo è l’elenco delle categorie che corrispondono ai risultati della ricerca.
Questa è abbastanza facile da fare anche client-side sempre seguendo le regole di UI Composition: Marketing torna come risultato della ricerca gli ID dei prodotti, e per ogni prodotto l’ID della categoria.
A questo punto ci basta una distinct sulla lista degli ID delle categorie per avere le informazioni necessarie per comporre quella parte di UI.
In maniera molto smile possiamo risolvere anche il resto:
Mandiamo a Shipping e CustomerCare gli ID dei risultati e loro si preoccuperanno di fare i loro ragionamenti per produrre quelle facet.
La domanda ovvia a questo punto potrebbe essere:
ma cosa c’è di male a buttare tutto in un bel robo fatto con Elastic Search?
E la risposta sarebbe: nulla, non c’è nulla di sbagliato.
La cosa sbagliata è pensare che l’unica soluzione sia buttare tutto in un robo fatto con Elastic Search.
Come abbiamo già detto quando avete a che fare con un sistema veramente distribuito la condivisione delle informazioni vi si può ritorcere contro molto rapidamente e quando succede fa molto male.
Quindi una buona domanda da farsi è: ma voglio veramente un sistema distribuito? O sto pensando prima al mio ego e poi ai requisiti?
Fino ad ora siamo quindi riusciti a soddisfare il requisito ricerca senza introdurre un sistema centralizzato.
Ma è sempre così?
C’è un ultimo elemento su quella pagina che potrebbe farci dire che alcune cose vanno centralizzate in qualche modo:
Le informazioni necessarie per cambiare l’ordinamento vengono da servizi diversi, e questo comporta che per ordinare i risultati l’interazione tra i vari servizi sia un po’ complessa, forse un po’ troppo.
Lo scopo di questo post era dimostrare che non è strettamente necessario condividere informazioni neanche per cercare. Con i prossimi due post sul team SOA/Services UI Composition affronteremo invece due scenari in cui le informazioni in qualche modo devono essere condivise tra servizi diversi nello stesso sistema.
Post in questa serie: