У меня СБ в свое время было против http/2 )

есть прокси, которые его деградируют. как WebSocket деградирует в LongPooling в Socket.IO автоматом.

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

Это какие? И при этом стриминг отвалиться же.

Так это от сериализатора в json зависит )
Но gzip упакует их все равно

(Впрочем, жалко, что нельзя иметь общий словарь на всю сессию...)

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

Это которые по сути из него http rpc с json делают. Не уверен что там JSON-RPC v2 именно, надо глянуть. Но это сильная деградация.

В смысле "не тот". О чем договоримся, то и будет. Или ты про OpenApi?

Это да, JSON-RPC тоже жуткий стандарт...

Возвращаясь к этому.

1. Эту таблицу можно пошардить, да и писатель тут только 1(тот, кто слушает топик с событиями по клиенту "клиент подключился", "клиент отключился", "клиент пошёл поспать". Паблишер вообще может вычитать её целиком и так же слушать обновления из топика.
2.  Откуда нагрузка, если там чистой воды чтение? Опять же, можно пошардить по клиентам.
3. А что сложного? Просто послать то, что клиент ещё не ack'нул.

насколько я пмоню не совсем. алгоритм gzip расчитан на потоковую обработку и могёт находить дубликаты повторяющихся данных только в очень ограниченном размере блока - 32кб вроде. т.е. в здровой портянки с множестом одинаковых значений он будет не так хорош как грпс

я про JSON Schema.

У него есть свои прелести. Например его библиотеки-реализации весят меньше rest-роутеров. Или его библиотеки часто абстрагированы от транспорта и могут работать с UDP, чистым TCP или WebSocket. Еще Payload этого стандарта можно использовать для очень простых MQ.

почему? довольно простая и минималистичная штука.

А что пояснять? :)  Вот есть json и поди разбери его {"userData": [ "Ivan", 33, {"updated": 1618563464 } ] }  

Если трафик жалко - есть msgpack(и хочется без схемы).

1. Ну, никогда не бывает "ровно одного писателя", иначе при его падении все встанет. Все-таки всегда минимум два сервиса такими вещами занимаются. Ну и у тебя еще и появился топик событий по клиентам (и точно будут паузы между "подключился и забрал сообщения" и "клиент попал в таблицу онлайна" с потерей событий)
2. Пошардить не всегда можно, так как раз список событий в базе - то удобно ее сделать общей и добавлять события в бизнес-транзакциях. Ну и чтение не дает нагрузки только если из памяти, а тут все-таки не совсем про это.
3. Эээ, у тебя было 2ws, стало 3 - что делать с событиями уже в очереди? Как клиентов перераспределяем?

Почему? Он прост как палка и не привязан к транспорту. Реализовать самому можно за вечер

Ну, REST level 1 очень прост в реализации, даже проще RPC
А REST level 2 не нужен

ну такое, каноничный REST годен только для крудов и не для чего более. RPC гораздо более гибкая парадигма