Ожидание новой записи в прочитанной модели, созданной проекцией в PROOPH

Question

Ожидание новой записи в прочитанной модели, созданной проекцией в PROOPH

Я пользуюсь prooph (https://github.com/prooph) поэтому у меня есть модель записи, где я храню события, как показано ниже (таблица агрегирования):

когда я запускаю проекцию в фоновом режиме, используя команду:

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

Я прочитал модель, как показано ниже:

Перед моим фоновым приложением у меня есть API отдыха, где я создаю событие:

CardWasAdded

через URL:

POST /cards

и я получаю код 201.

После этого я обновляю свой список через URL:

GET /cards

Проблема в том, что иногда это новое событие не обрабатывается проекцией.
Итак, вопрос:

Как решить эту проблему?

Стоит ли ждать 2 секунды или какое-то время? (Безобразный хак для меня).
Должен ли я обрабатывать событие после вставки — не использовать процесс проецирования в фоновом режиме?

0

cqrs event-sourcing php prooph

Решение

Другие решения

Спасибо, Роман, за ответ.

Наконец-то я признал тот факт, что чтение модели имеет задержку.

В моем остальных API, когда я POST новый ресурс, я возвращаю 201 и JSON с новым созданным Id и так далее.
Мое фронтальное приложение, основанное на ответе от нового ресурса POST (POST / карта), добавляет новую запись в таблицу данных в виде новой строки со значком «NEW».

Когда пользователь обновляет список, чтение модели готово (поскольку создание новой записи занимает менее 1 секунды).

В конце нет никакой разницы для пользователя, является ли запись от

POST / карты

или же

GET / карты

так пользовательский опыт в порядке.

0

Источник

Accepted Answer

Мой ответ не является конкретным, но вот некоторые стратегии, которые вы можете использовать в любой системе CQRS:

Просто примите тот факт, что модель чтения не является последовательной (ничего не делайте). Пример — когда я публикую что-то в Твиттере, я не могу сразу увидеть свое сообщение в потоке, и это нормально. Это появится там в конце концов.
Оптимистичное обновление пользовательского интерфейса. Просто обновите пользовательский интерфейс, как будто ваша команда прошла. Если нет — ничего страшного. Пример — как-то в твиттере. Вам не нужно ждать подтверждения. Если что-то вроде не удалось — его статус будет при следующем обновлении чтения модели.
Подождите в конечной точке API. Был вызван ваш API, вы вводите команду и ищите конкретное обновление модели чтения. Сбой по таймауту.
Подождите на уровне пользовательского интерфейса. Вы отправляете команду и отображаете некоторый элемент пользовательского интерфейса «Ожидание», пока ваш запрос не вернет то, что вы искали, или произойдет сбой по таймауту.

В стратегии 3 и 4 вы можете использовать какую-то серверную сигнализацию — сокеты или что-то вроде этого. Ваша прочитанная модель может подтвердить, что она обновлена.

3