RabbitMQ, Колба / Фастапи и веб-розетки

Question

Архитектура моей системы очень похожа на рисунок, приведенный в вопросе здесь . Основное различие между моей реализацией и опубликованным вопросом заключается в том, что я буду использовать fastapi / flask для веб-сервера (в python) и rabbitmq для обмена сообщениями.

Мой псевдокод высокого уровня ( использование fastAPI) выглядит следующим образом:

from fastapi import APIRouter
from starlette.responses import Response
router = APIRouter()

@router.post("/users/{message}")
async def provide_suggestions(message: str, response: Response):
    uuid = generate_uuid(message)
    message_dict = {"uuid": uuid, "data": message}.
    result = await post_message_to_rabbit_mq(message_dict)
    response.status_code = SOME_VALID_HTTP_RESPONSE_CODE # what would this be?

Вопрос 1: Каким будет код ответа HTTP? По сути, веб-сервер должен уведомить клиента, чтобы он вернулся через определенное время, и проверить результат (и затем вернуть предложения).

Как только веб-сервер отправляет сообщение через rabbitmq, рабочие генерируют соответствующие предложения на основе сообщения (путем поиска в базе данных). Это сообщение вместе с uuid будет отправлено обратно в другую очередь сообщений rabbitmq. Теперь веб-сервер становится потребителем.

Вопрос 2: Предполагая, что веб-сервер зарегистрирован в качестве потребителя для очереди сообщений на выходном пути, получит ли веб-сервер данные в отдельном потоке для очереди сообщений?

Вопрос 3: вместо ожидания другого HTTP-запроса от клиента на отправку предложений, может ли клиент и сервер асинхронно взаимодействовать через веб-сокеты ?

Answer 1

Чтобы ответить на ваши вопросы:

1: Согласно стандартам REST , код состояния 202, кажется, делает это здесь:

HTTP Status 202 указывает, что запрос был принят к обработке, но обработка не была завершена. Этот код состояния полезен, когда фактическая операция асинхронна по своей природе.

2: вы хотите, чтобы другой процесс в службе потреблял из очереди и обновлял базу данных локального сервера. Как правило, это будет не часть вашего веб-сервера fastapi, а отдельный процесс. Ваш веб-сервер fastapi мог бы затем запрашивать локальную базу данных, или у вас могла бы быть отдельная конечная точка на веб-сервере, которая может быть вызвана этим процессом при обновлении базы данных.

3: Если у вас есть клиентские утилиты что может иметь дело с соединением через websocket, то да. Смотри документацию к Фастапи здесь . В противном случае может быть лучше вернуть код состояния 202 при первом запросе, и клиент будет запрашивать веб-сервер каждые несколько секунд. Другой вариант - использовать URL обратного вызова, но это зависит от ситуации клиента.