2

I use prooph(https://github.com/prooph) so I have my write model, where I store events like below(aggregate table):

Write model

when I run projection in background using command:

php bin/console event-store:projection:run card_projection

I have read model like below:

Read model

In front of my background application I have rest API, where I create event:

CardWasAdded

through url:

POST /cards

and I receive code 201.

After that I refresh my list through url:

GET /cards

The issue is that sometimes this new event is not processed by projection. So the question is:

How to manage that issue?

  1. Should I wait 2 sec or some time?(ugly hack for me).
  2. Should I process event after is inserted - not use projection process in background?
Arkowsky
  • 851
  • 7
  • 19
  • Perfect answer by @RomanEremin. In prooph's example app you find strategy 1 applied, see [here](https://github.com/prooph/proophessor-do/blob/master/templates/action/user-todo-list.phtml#L11) The app itself accepts the fact that a read model update can take longer. In such a case it informs the user and kindly asks to refresh the page. – Alexander Miertsch Sep 06 '18 at 16:14

2 Answers2

6

My answer is not prooph specific, but here are some strategies you may use in any CQRS system:

  1. Just accept the fact read-model is not imeediately consistent (do nothing). Example - when I post something to Twitter, i may not immediately see my post in the stream and this is ok. It will appear there eventually.
  2. Optimistic UI update. Just update UI as if your command went through. If not - not a big deal. Example - Like something on Twitter. You don't need to wait for confirmation. If somehow like failed - its status will come with next read model refresh.
  3. Wait at the API endpoint. Your API was called, you issue a command, and look for particular read model update to happen. Fail on timeout.
  4. Wait at UI level. You send a command and display some "Waiting" UI element until your query returns what you are looking for, or fail on timeout.

With strategy 3 and 4 you may use some kind of server signaling - sockets or something like this. Your read model might be able to confirm it was updated.

Roman Eremin
  • 1,431
  • 8
  • 10
1

Thank you Roman for your answer.

Finally I accepted fact that read model has delay.

In my rest api when I POST new resource I return 201 and json with new created Id and so on. My front application, based on response from POST new resource(POST /card), add new record to data table as new row, with "NEW" badge.

When user refresh the list, read model is ready(because building new record takes under 1 sec).

At the end there is no difference for user whether record is from

POST /cards

or

GET /cards

so user experience is fine.

Arkowsky
  • 851
  • 7
  • 19