Комментарии 12
идея любопытная, кажется тут можно еще покопать в сторону использования более шустрых реализаций (допустим uws или что-то на wasm), или grpc тот же.
В библиотеке также хотелось бы иметь возможность аборта по айдишнику (клиент передумал и ему не нужен ответ).
Честно говоря, я плохо представляю где могла бы понадобиться отмена запроса, но сделать такое легко учитывая структуру
abort(waitId) {
const err = new Error("Request abortion");
this._awaitMessages[waitId]?.reject(err):
return err:
} Надеюсь, я правильно понял что должна делать функция..
не совсем).
Допустим есть какой-то список данных выводимый на клиенте. И есть ендпоинт который отдает эти данные на сервере.
Построение этого списка не моментальное. Серверу тоже нужно сходить в другие сервисы и/или БД внутри кластера, чтобы собрать этот список и отдать это пользователю. У списка предусмотрена фильтрация, пользователь передает параметры фильтрации - сервер фильтрует список при построении.
При отмене запроса не только клиент должен перестать ожидать ответ на свой же запрос, но и сервер должен перестать делать какие-то вычисления по нему. Если у сервера в этот момент для выполнения этого запроса есть активные запросы в другие сервисы - он тоже должен их прервать дабы не расходовать ресурсы впустую.
Получается если клиент выбрал фильтры, а через секунду выбрал другие фильтры, то первый запрос отменится, а второй будет выполнен.
Примерно такой может быть контекст у отмены запроса. Надеюсь понятно описал.
Ну можно например два подключения к серверу делать, управляющее и с данными... Если управляющее отваливается или по нему приходит запрос на отмену, сервер спокойно перестает обрабатывать запрос и дропает соединение с данными. Это так, навскидку придумалось, не могу сказать, можно ли так на вебсокете сделать.
uWS хорош, но там только серверная часть
Реально лучше, очень полезная штука
Полезный хелпер.
Ещё в клиент было бы здорово добавить что-то простое для обработки дисконнекта и колбэков по коннекту/дисконнекту, и цикличного реконнекта, с настройками пауз и количеством попыток.
В идеале, чтобы просто было в пару строк видеть состояние соединения (я обычно делаю индикатор красный/зеленый где-то в углу) и "растущую" паузу попыток реконнекта. Тогда вообще не нужно будет заморачиваться по WS, только ваша либа и все.
waitId стоит делать через UUID - и быстро, и гарантировано не пересекается с другими, WS все же для систем где много сообщений / клиентов, а значит примитивный Date.now не лучшее решение
Стоит еще адаптировать библиотеку (и вопрос, будет ли она актуальна?) к нативной реализации Ws клиента в следующих версиях ноды
Я процентов на 90 уверен, что она будет актуальна. Всё, что использует AsyncSocket это ивенты connect и message, а так-же метод send. Если это всё в следующих версия меняться не будет (как минимум интерфейс использования), то он останется актуальным.
Да и в ином случае, я скорее всего просто запатчу AsyncSocket
WS, но лучше