лично я не знаю лучше варианта, чем предложил. а ты?

упрощеного говоря так и есть. только эта прослойка эта правильно написанная абстракция и ты можешь заменить на ws или написать свой сервер

а зачем вам rpc поверх websocket ? включите keep-alive на http уровне и будет так же работать

batch проектировать проще в RPC, чем в REST стиле

Есть rpc-websockets, но он зачем-то в зависимостях Бабель рантайм тянет. Поэтому лично я бы потратил бы пару часов и прикрутил бы обычный модуль для парсинга json rpc к ws и дело в шляпе

Вообще не так.

ну по http не обязательно только через rest сообщения передавать, можно просто в post запросе передавать все, как это реализовано в graphql

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

какой из этих вариантов ты предпочел увидеть на проекте который тебе может придти на поддержку?

Первый. Ибо связать жсонрпц с вебсокетами довольно просто и достаточно почитать всего 2 доки (вебсокетов и жсонрпц), нежели читать здоровую доку непонятного фреймворка и пытаться туда выкрутить то, для чего он вообще не предназначен.

Это о предпосылках появления nest.js?

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

Я не предлагаю писать библиотеку. Я предлагаю взять готовую либу жсонрпц и засунуть ее в хендлер месседжа готовой библиотеки ws.

окей

вообще не так что ?
на сетевом уровне http и websocket являются tcp сессией, отличие лишь в том что в случае с websocket сервер может отправлять запросы без запроса со стороны клиента, но это не укладывается в парадигму rpc , это уже pub-sub

Длина сесси абсолютно другая. Парсинг хедеров и прочий оверхед типа аторизций и т.п. в вебсокетах происходит единоразово. Абсолютно иной лоадбалансинг и масштабирование.
Поэтому у хттп с вебсокетами из общего только TCP, остальное все абсолютно разное

в контексте rpc, это не играет никакой роли, оверхед на поддержание сессии (память/cpu) гораздо выше чем на повторную авторизацию, плюс теперь все проблемы с менеджментом сессий ложатся на плечи разработчика, для request-response проще и дешевле использовать http
ps: возможно есть кейсы где это нужно, но мне кажется что автор вопроса не совсем понимает во что вписывается, ws это большой гиморой особенно если нужно скейлится и основной юзкейс для него пуш уведомления.

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

Какая проблема со скейлом?