SubText, il motore che fa girare questo e tanti altri blog non è mai stato eccelso ma ha sempre fatto il suo sporco lavoro e lo ha fatto spesso e volentieri bene. L’ultimo aggiornamento l’ha invece trasformato in un robo pressoché schifoso. La sensazione, perché in tutta sincerità non ho idea di come funzioni, è che i dati che la parte di front-end vede arrivano da ElasticSearch (o da una cache), mentre quello che la parte di back-end vede arriva da un database relazionale, o qualcosa di simile. Sembra quindi una sorta di implementazione di CQRS.

Ecco lasciatemi dire che questo è esattamente come non deve essere implementato CQRS, mi spingerei anche verso il: che diavolo di senso c’è nell’usare CQRS per un blog.

La consistenza eventuale tra quello che vede il front-end e quello che vede il back-end è di minuti, spesso decine di minuti. Qui sopra un post, che secondo la UI di front-end non ha commenti, mentre secondo quella di back-end ne ha ben due, è passato un tempo interminabile prima che i commenti comparissero anche lato front-end. E forzare la ricostruzione degli indici di ElasticSearch non è servito a nulla, il che mi fa pensare che non sia in modalità pull.

Lasciamo perdere poi chicche come la seguente, lato back-end post duplicati, che dopo un po’ scompaiono.

Perché in stile CQRS?

Questa è la domanda vera, che senso ha applicare CQRS ad un blog engine. Un blog engine è un generatore statico di contenuti, scrivo una volta, difficilmente modifico, leggo un’infinità di volte. Il rapporto letture/scritture è tremendamente a favore delle letture, l’unica cosa su cui c’è interazione sono i commenti, che nell’implementazione di SubText attuale sono complementi inutilizzabile per avere qualsivoglia sorta di interazione.

Il giro corretto dovrebbe essere:

• scrivo
• pubblico un contenuto statico
• commento
• cerco nei contenuti del blog

Considerando che i commenti sono solo testo, e non sono ne threaded ne ricercabili/indicizzati, cosa c’è di male nello schiaffarli piatti in una schifosa tabella relazione e leggerli da li. Se i contenuti sono statici per definizione non impattano sul DB, possono essere messi in cache pressoché all’infinito, l’unica cosa da caricare dal db sono i commenti.

Se proprio voglio cercare, allora si che posso far macinare il testo dei post ad ElasticSearch a indicizzare lo slug del post stesso.

La menata è che così come è non soddisfa ne chi scrive, men che meno chi legge.

Jekyll FTW