andreykaTтакая тема, мопед не мой, не надо критиковать решение )) можно просто сказать что так не делается. но... в общем задача.
есть некий вебсервис. есть некий фронтовый клиент. по ресту клиент дергает сервера и достает какие-то объекты или наборы объектов по краду. тут всё просто и обыденно.

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

как это сделать? надо как то сказать фронту что надо передёрнуть гет что-нибудь там сущность.
как сказать фронту что надо дергать? выбрано решение - сигнализировать по вебсокету. что такая то сущность обновлена.
сказано-сделано -- обновились сведения шлем по вебсокету всем клиентам что они обновились, а клиенты решают - передергивать им по ресту дату или нет.

и всё бы ничего, но возникает ряд вопросов - насколько данный подход верен? может лучше по вебсокету вообще тогда уж ВСЁ отдавать? или отдавать только обновленные поля? (но тут много эвристики). или вообще всё не так?

в описанном виде выше оно работает. тут две проблемы - по-хорошему надо сделать механизм чтоб бэк всегда слал что-то фронту когда обновляется любой набор данных. это проблема один. как ее решить - тут в принципе всё ясно. и тут выходит другая проблема - допустим у меня сотня юзеров сидит с сотней клиентов. и тут у меня случайно так обновилось что-то циклически 100 раз (ну скажем, десять сущностей по 10 раз), далее у меня на фронт сотне юзеров улетает каждому по 100 сокетмесаджей.. или 10 000 меседжей выплёвывает краткосрочно мой бэк.
и если гипотетически у ста юзеров открыты окошки показывающие те самые сущности назад на бэк возвращается запросы в количестве от 100 и до 10 000 единовременно.
бэк сам себя убил.

можно конечно же подумать о микрооптимизациях, одна проблема минимизируется тем что скажем, наверняка у всех все сущности ожидаться к показу не будут.

и вторая как то трекать на бэке на слое отсылки сокетсообщений на предмет какие юзеры какие сокетсообщения ожидают (типа у меня открыто окно А и поэтому мне не надо получать сокетмеседж об обновлении таблицы Б). но это выглядит как-то черезчур уж сложно, хоть и интересно )) и мне кажется тут должен быть какой то простой вариант. люди же как то пишут интерактивные приложения? или там вообще весь обмен идет по сокетам, а-ля графкьюэль, без всяких этих ваших старомодных рестов?
если у тебя реализованы websocket то правильнее сразу по ним и передавать изменения.

andreykaT,
зачем дергать по рест, когда можно сразу передать по websocket?

andreykaTвадя, или ты предлагаешь кусочек передать по ресту, следом мне в приложении выстроить параллельный слой, куда клиент будет регаться по вебсокету говоря что он по ресту дернул какой-нибудь ресурс и типа "подписывается" на слушание этого ресурса и кусочки обновлений мне слать ему по вебсокету а клиент потом эти кусочки будет собирать в одно целое и показывать юзеру?

нееее. спсииибо.
ну где-то так, только как ни крути у тебя получится так. потому что это будет самое простое, хотя это и грозит переписыванием кода...
а какие проблемы проблемы на клиенте собрать и вставить? и что за клиент? браузер? тогда всё просто.

andreykaT,
самое трудное ты уже сделал - внедрил websocket. остальное уже намного проще

Petro123вадячто это будет самое простое, хотя это и грозит переписыванием кода..
вадя,
учись компромиссам))
я не против компромиссов, просто мне кажется, что тс придет к ws, но мне интересно к чему тс придет на самом деле.

andreykaT,
мещанина - возможно это кажется. использовать термин «мигнпльный слой» возможно и делает существующее логичным. и на самом деле возможно это так. но если глобально - это выглядит как заплатка. против аргумента «не разрещат» спорить трудно. но когда 5n*m юзеров - это хороший аргумент. у тебя есть несколько вариантов и они все имеют право на существование. но у них разная цена - выбор за тобой.