Ну я думаю идеально было бы на Go что то намутить. Если использовать либу и свою обертку делать.

пичалька ((
не мой стек

Намути на workerman'е))

в общем, перед отправкой в центрифугу сделала пинг на наличие соответствующего канала, если есть - отправляем сообщение через сокет, иначе сохраняю сообщение в хранилище, пользователь так и так зайдет на страницу и нет надобности ему слать по сокету, следовательно читаю сообщения из бд, в цикле их обрабатываем с последующей очисткой,
кейс готов ))

как правило не рекомендуют так делать, для presence detection (онлайн чел или оффлайн) можно подписаться на обновления ключей и трекать воркером отдельным в бэкграунде, если именно изменение статуса интересует. Но все что про "отправить что-то на сервер с гарантией доставки" - это все отдельно по http минуя центрифугу. Ее только для апдейтов с сервера на клиент юзать или там где надо в канал забродкастить и нет надобности в персистенсе.

Можно еще захерачить свой энджен, там вроде есть возможность ее расширять, но...

да я уже поняла, что вообще не обязательно пользователю слать через сокет, если он только зашел, просто сохраняем и выводим, вообще не пойму почему я так в этом кейсе зациклилась на ws ))

Там, кстати, внезапный апдейт центрифуги. Теперь это не только ws, но и нативные sse

да, я видела транспорты ))

Добрый день. Вопрос по дто опять :)
Насколько правильно засовывать целиком ентити в дто? Например для регистрации User в сервисе, прокидываем в него дто. У User есть Status. В дто можно сразу нужный статус закинуть или правильнее закинуть statusId, а в сервисе уже найти нужный статус по ид?

А статус это прям доменная сущность или просто строка вроде "зарегистрирован"/"активирован"?

в твоем примере почти уверена статусы имеют типы  активный/заблокирован, или т.п., соответственно лучше использовать стринговые значения статусов "active", "ban",  чтобы потом последующий код был читаемым, не 1,2,3, а "active", "ban", сами статусы в User хранить ввиде констант и отдельные методы setActive() , setBan() с присваиванием этих констант, в дто получается передается стринг где можно "assert choice" навеcить и валидировать.
Если используются статусы из бд как отдельный vo, то и передавай объектом Status с соответствующей типизацией

Статус это сущность

У этой сущности много полей или только одно строковое с названием?

Id, name, type

type - это код статуса, name - для отображения? Допускается ли что у статуса могут появиться другие дополнительные поля?

больше похоже на то, что ты неправильно выбрал способ хранения статусов, а не как их в дто передать

а почему не 1,2,3

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

ну Enum класс