Leo_Eldorado, мне видится реализация так:
1) Брокер сообщений (kafka/rabbit)
2) Микросервис gateway который принимает запросы (stateless)
3) Микросервис бизнес-логики который пишет в БД
Для веба лучше всего в таком кейсе подойдет веб-сокет или поллинг, поскольку мы не знаем заранее когда операция выполнится (бывают операции постоения отчетов которые могут длиться несколько часов).
Веб-клиент делает запрос на гейт, который в свою очередь формирует сообщение для брокера в определенную очередь и отсылает, в ответ клиенту приходит id сообщения статус которого нужно проверять (скажем через простой поллинг раз в 10 сек). Микросервис БЛ уже подписан на определенную очередь и просто обрабатывает сообщения все подряд, при поступлении очередного он делает все что нужно с БД и результат кладет в другую очередь. Далее можно идти по нескольким путям:
- gateway уже подписан на очередь результатов и вычитывает результат, хранит у себя в кэш какое-то время (выставляется ТТЛ), соответственно веб-клиенты при очередном цикле поллинга получат обновленный статус. Этот кейс подходит когда статус могут читать много клиентов и не нужно при первом обращении его удалять из кэша (тут кстати привет redis)
- gateway по запросу делает хук на очередь и читает с нужным id статус. Тут скорее всего при вычитывании сообщение удалится из очереди (хотя насколько помню как настроишь) и статус для других клиентов уже будет недоступен (или его опять же где-то хранить)
Leo_Eldorado, стоп, я говорю в терминах транзакций .net с сервером транзакций, он там умеет намного больше чем транзакции БД.
Если говорим в терминологии транзакций БД, то флоу такой:
1) Запрос на сервер
2) Перед коммитом/откатом сервер формирует и отправляет ответ
3) Клиент приняв ответ делает доп запрос на коммит/откат, вот его уже можем повторять несколько раз в случае обрыва связи, потому что он в очередном (повторном) случае вернет предыдущий результат (другими словами можно вызывать 10 раз коммит для одной и той же операции, он со 2го раза начнет отдавать то что выдал на 1м вызове)
Но это все жуткий геморрой, советую смотреть в сторону брокеров сообщений, учи что такое подписка на события и делай обработку фейла внутри одного микросервиса, и только в случае успеха/неуспеха шли на шину
Leo_Eldorado, не во всех случаях это возможно, давай допустим что у тебя есть вцф клиент и есть вцф сервер, ты с вцф клиента хочешь исполнять операцию. Сервер у тебя пишет в БД. Вот кейс когда это не будет работать:
1. Клиент отправил запрос
2. Сервер принял запрос и начал писать в БД
3. Клиент-сервер потеряли связь
4. К моменту когда сервер запишет в БД и захочет вернуть результат клиенту связь еще не будет восстановлена
5. Ответ на сервере теряется
6. Клиент восстанавливает связь
С точки зрения коммуникации и обработки бизнес-логики таких конкурирующих кейсов не один, для упрощения таких ситуаций придумали Pub/Sub и брокеров RabbitMQ, Kafka.
iluxa1810, pipe это уже новый стиль, я уже год на энгуляр не пишу, поэтому извиняй, pipe были введены чтобы tree shaking делать
но логика в целом такая что тебе надо построить цепочку и только в конце подписаться, в цепочки используй разные функции flatmap если нужно распаковать observable, switchmap если нужно предыдущий отменять (хорошо для веб запросов), просто map если возвращаешь необернутый объект
NogerbekNurzhan, может и в этом, там у разных БД по-разному, в доке вообще говорится о ":1,:2" поэтому сделай через `strings.Builder` циклом пробегить от 1 до длины и запиши строку значения
sim3x, спикер не приводит конкретный кейс когда нужно что-то делать с 6ю протоколами, пока что это вилами по воде. Повторюсь в реальных высоконагруженных проектах ни разу не приходилось этого делать.
sim3x, сложность с аяксом в том, что надо как-то или считать дифф на сервере (между старыми данными и новыми) при запросе с клиента или кэшировать (на какое-то короткое время) на сервере новые данные до первого обращения, но в этом случае нужно думать над сессионностью чтобы не вышло там что кто-то другой за тебя прочитал данные. имхо реализация на веб-сокетах в данном случае настолько проста, что займет меньше времени и ресурсов
1) Брокер сообщений (kafka/rabbit)
2) Микросервис gateway который принимает запросы (stateless)
3) Микросервис бизнес-логики который пишет в БД
Для веба лучше всего в таком кейсе подойдет веб-сокет или поллинг, поскольку мы не знаем заранее когда операция выполнится (бывают операции постоения отчетов которые могут длиться несколько часов).
Веб-клиент делает запрос на гейт, который в свою очередь формирует сообщение для брокера в определенную очередь и отсылает, в ответ клиенту приходит id сообщения статус которого нужно проверять (скажем через простой поллинг раз в 10 сек). Микросервис БЛ уже подписан на определенную очередь и просто обрабатывает сообщения все подряд, при поступлении очередного он делает все что нужно с БД и результат кладет в другую очередь. Далее можно идти по нескольким путям:
- gateway уже подписан на очередь результатов и вычитывает результат, хранит у себя в кэш какое-то время (выставляется ТТЛ), соответственно веб-клиенты при очередном цикле поллинга получат обновленный статус. Этот кейс подходит когда статус могут читать много клиентов и не нужно при первом обращении его удалять из кэша (тут кстати привет redis)
- gateway по запросу делает хук на очередь и читает с нужным id статус. Тут скорее всего при вычитывании сообщение удалится из очереди (хотя насколько помню как настроишь) и статус для других клиентов уже будет недоступен (или его опять же где-то хранить)