Я ищу наилучшую практику при подключении веб-приложения (например, одностраничного приложения React) с бэкэндом, основанным исключительно на событиях (микросервисы, ActiveMQ, например).

Когда я выполняю GET-вызов из React (который является ответом на запрос), как мне получить ответ, учитывая, что все бэкэнд-сервисы основаны на событиях?

Мои мысли:

  1. Выполнить команду GET
  2. Иметь службу контроллера REST в бэкэнде (запрос-ответ), которая запускает событие и возвращает ответ, что все прошло нормально
  3. На стороне клиента сигнал ловится, но ничего не происходит, просто продолжайте загружаться
  4. Событие тем временем обрабатывается в бэкэнде, который запускает другое «ответное» событие, когда выполнено, к которому (используя липкость или подобный подход) тот же контроллер REST слушает
  5. Контроллер отправляет фактический ответ в браузер, используя веб-сокеты (или аналогичные)
  6. Браузер получает ответ, отображает результаты

Я знаю, что есть обходные пути, но я ищу лучшее решение на основе событий.

0
Horatiu Jeflea 15 Авг 2019 в 19:17

2 ответа

Лучший ответ

Выполнить команду GET

Это верно

Иметь службу контроллера REST в бэкэнде (запрос-ответ), которая запускает событие и возвращает ответ, что все прошло нормально

Да, и вы должны вернуть ссылочный идентификатор, который клиент может использовать для отслеживания прогресса.

На стороне клиента сигнал ловится, но ничего не происходит, просто продолжайте загружаться

Смотря как. Если вы хотите, чтобы клиент подождал, продолжайте показывать загрузку. Если это длительный процесс, вы не можете заблокировать пользователя и отправить уведомление позже, когда это будет сделано.

Событие тем временем обрабатывается в бэкэнде, который запускает другое «ответное» событие, когда оно выполнено, на которое (используя липкость или подобный подход) тот же контроллер REST слушает

В отделенной архитектуре все вещи асинхронны. Значит огонь и забудь. Когда вы возвращаете ссылочный идентификатор клиенту, контроллер готов, вы ничего не можете заблокировать. Клиент будет использовать этот идентификатор для проверки прогресса (кеш / БД и т. Д.). Если вы идете по пути веб-сокета, то возможный контроллер может уведомить об этом при изменении состояния.

У вас уже есть понимание, поэтому оно действительно зависит от рабочего процесса, который вы пытаетесь создать.

3
Imran Arshad 16 Авг 2019 в 03:10

Вы можете пойти по этому пути:

  1. Серверный «процессор» подписывается на очередь заданий
  2. Выполнить команду GET
  3. Контроллер REST подписывается на новую очередь, используя идентификатор клиента. Публикует событие (которое содержит идентификатор клиента) в очередь заданий процессора. Возвращает ОК клиенту.
  4. Внутренний «процессор» завершает работу и публикует завершенное событие в очередь, указанную идентификатором клиента.
  5. Контроллер REST получает завершенное событие и удаляет очередь (больше не нужна). Возвращает ответ клиенту, используя websocket.
1
Edward 16 Авг 2019 в 03:55