запрос, бек обрабатывает и записывает в базу и выдает ответ, здесь все понятно.
front -> back -> db
front <- back <- db
как это все через раббит сделать?
front -> back -> rabbit -> worker -> db
как получить ответ во фронте?
front 'create item' -> back 'transaction' -> db 'ok' or 'fail' -> back 'ok' or 'fail' -> front
front 'create item' -> back 'create item msg' -> rabbit 'msg' -> worker 'transaction' -> db 'ok' or 'fail' -> ? front
Надо начать с того, зачем тут рэббит
ну например погуглить request-reply паттерн. вы так "масштабируетесь" что ли ? бэк шлет в воркер, задает в сообщении очередь куда отвечать. ну и ждет ответ. worker записывает в базу и шлет ответ обратно в бэк. но в целом да, вам точно нужен брокер тут ?
"бэк шлет в воркер, задает в сообщении очередь куда отвечать. ну и ждет ответ. worker записывает в базу и шлет ответ обратно в бэк." вот дальше с бека на фронт как получить ответ
Фронт тогда должен быть подключен через websocket, а бек соответственно отвечать ему туда. Похоже ты используешь паттерн под названием CQRS, если кто будет говорить, что ты изобретаешь фигню
типа нагрузку на базу уменшить
казалось бы как ? собирать в батч запросы и собсно батч-инсерт/апдейт ?
При чем тут CQRS? 😏
А что с ней не так в данный момент?
Ты точно не уменьшь нагрузку.
тогда подумайте сразу об интересных сайд-эффектах. что делать если батч обломается, например. все запросы отбивать как неуспешные ?
Как в этом поможет рэббит?
Ну мне сказали инсерты сделать через рэббит чтоб нагрузку на базу не создавать, ну я сделал, потом ответ на фронт захотели и вот здесь я застрял, да я тоже здесь не очень понимаю как рэббит поможет
если в батч собираешь - наверное поможет. если какая-то плюс-минус реальная наргрузка. лучше раз в секунду сделать батч запрос на 500 вставок, чем 500 отдельных, условно.
Обсуждают сегодня