Come gestisci una richiesta POST di un'applicazione web con il sourcing di eventi?

The event is raised and will be saved in the event store eventually.

Questo è sbagliato: l'evento dovrebbe essere scritto immediatamente nell'archivio degli eventi. Il caso limite di cui bisogna fare attenzione qui è che due scritture in conflitto vengono eseguite contemporaneamente: se una di queste scritture non riesce, il chiamante deve essere avvisato che il comando non è riuscito, rendendoli consapevoli del problema e consentendo loro di prendere in considerazione strategia appropriata.

Hai ragione a sapere che i modelli letti sono aggiornati alla fine, piuttosto che immediatamente, il che introduce alcune sfide.

What I am missing, please? It seems that there's something really simple here, but I cannot see how a web application can work with event sourcing. Are we relying on the event-sourcing being faster than the web application and assuming that the data will always be consistent before the user hits the next page? Wouldn't that be a bit risky during heavy system use?

Ci sono un paio di approcci da prendere. Uno è, come hai descritto POST-REDIRECT-GET. Ma diventiamo un po 'più intelligenti riguardo alla risorsa che è l'obiettivo del reindirizzamento. Anziché reindirizzare a un endpoint "ultimo" arbitrario, reindirizziamo invece a un endpoint in grado di identificare la posizione in cui dovremmo trovarci nel flusso di eventi

/foo?asOf={sequenceNumber}

Quindi quell'endpoint può bloccarsi, in attesa che l'evento si presenti, oppure può creare in modo proattivo una nuova rappresentazione della risorsa recuperando la cronologia dall'archivio degli eventi, o .... Ci sono molte variazioni , ma tutti iniziano dal pensare di essere specifici su dove nella storia si vuole creare la rappresentazione.

(A seconda delle esigenze, l'implementazione potrebbe restituire una rappresentazione, o potrebbe reindirizzare a una rappresentazione una volta che i risultati sono disponibili. Si potrebbe voler restituire una rappresentazione in quel punto esatto della cronologia, o in qualsiasi punto conveniente dopo .)

Un'altra alternativa è costruire una rappresentazione nel gestore POST. L'applicazione ha appena aggiornato correttamente il flusso di eventi, quindi ha tutti gli eventi nella cronologia fino a quel momento. È possibile passare tale cronologia a un bit di codice che sa come generare la vista (eventualmente leggendo in altre cronologie dal modello di scrittura o copie memorizzate nella cache dal modello letto).

Un altro approccio, utile in alcune circostanze, è quello di restituire gli eventi stessi e consentire al chiamante di ricostruire la vista che si aspettano. Questo approccio potrebbe avere senso se stessi scrivendo un'app per una sola pagina, lasci che l'app aggiorni la propria copia non autorevole del modello e lavori da lì.

Tutto si riduce davvero alla natura dei dati che stai presentando al tuo utente. Se è di natura transazionale e la coerenza è di fondamentale importanza, allora hai ragione: un modello alla fine coerente probabilmente non funzionerà. Tuttavia, se è accettabile che la natura dei dati sia latente, la coerenza finale funzionerà correttamente.

Ad esempio, pensa a un sistema bancario. Lo stato più recente dell'account di un utente e la cronologia delle transazioni è ovviamente molto importante. Pertanto, la coerenza finale è probabilmente qualcosa che non funzionerà. Tuttavia, i messaggi che risultano da transazioni consistenti possono essere qualcosa che è accettabile avere (una quantità accettabile di) latenza. Qualcosa del genere, forse un utente vuole essere avvisato ogni volta che è stata effettuata una transazione di oltre $ 100. Questo è qualcosa che potrebbe / essere ottenuto attraverso un'eventuale coerenza.

Quindi in risposta alla tua domanda, sì, i sistemi alla fine coerenti possono / funzionano perfettamente per un'applicazione web. Tutto dipende dai dati con cui hai a che fare.