Nelle nostre divagazioni su CQRS di qualche tempo fa abbiamo parlato di eventualmente consistente ma non ci siamo addentrati nelle implicazioni tecniche che eventualmente consistente porta con se. Qualche, più di qualche, divagazione tecnica la approfondisco sul mio blog in inglese parlando di Jason che è un toolkit che ho scritto per eliminare dai pensieri dello sviluppatore tutta la parte infrastrutturale.
In uno scenario come il seguente però abbiamo un piccolo problema nel momento in cui la parte di de-normalizzazione è asincrona:
Supponendo una Single Page Application in cui i comandi arrivano via HTTP avete il seguente flusso:
- Invio del comando in POST;
- Ricezione del comando e gestione dello stesso da parte del back-end;
- Broadcast dell’evento;
- Invio della risposta HTTP-200;
- De-normalizzazione;
Oppure “peggio” ancora in caso di gestione asincrona anche dei comandi:
- Invio del comando in POST;
- Ricezione del comando e dispatch dello stesso su una coda;
- Invio della risposta HTTP-202;
- Ricezione del comando e gestione dello stesso da parte del back-end;
- Broadcast dell’evento;
- De-normalizzazione;
In entrambi i casi quello che per il client determina che la richiesta è stata portata a termine è l’evento non il fatto che il comando sia stato completato, come ad esempio nel primo caso, perché dal punto di vista del client non è detto che tutto quello che si aspetta di trovare sia ancora pronto o che la semplice esecuzione del comando inviato abbia effettivamente portato a termine il tutto.
La domanda a questo punto è: deve per forza essere asincrono?
La risposta ovviamente è no, nulla è per forza :-), ma renderlo sincrono introduce un interessante violazione di un principio base: un evento è nel passato e immutabile, pubblicato da un publisher nel totale disinteresse dei subscriber.
“nel totale disinteresse dei subscriber” è la parte importante.
Il rischio è quello di “infilare” gli handler di un evento nello stesso processo/thread di chi pubblica quell’evento facendo si una cosa totalmente fuori dal controllo di chi pubblica abbia conseguenze incontrollabili e imprevedibili proprio su di lui.
Nelle prossime puntate:
- CQRS: “C” come “Conversation Id”;
- CQRS: “N” come “notifiche”;