Комментарии 13
RPC — remote procedure call. В идеале из js должны вызываться асинхронные функции, которые под капотом будут вызваны на сервере, без дополнительных действий со стороны прикладного кода.
Такая реализация есть к примеру тут:
https://github.com/metarhia/jstp
Сам по себе socket.io как раз содержит всевозможные fallbacks, поэтому перестали использовать его пару лет назад, перейдя на JSTP/Firebase (он под капотом тоже работает на ws)
А что такое JSTP/Firebase. Поиск в google не даёт выдачу по этой фразе?
Да, но сам jstp можно использовать и без impress.
Firebase — https://firebase.google.com/docs/firestore вот такая штука, это не RPC, т.к. оно прикленно к данным, но с ним идут Firebase Functions, которые умеют вызваться по событиям возникающим в FireStore https://firebase.google.com/docs/firestore/extend-with-function.
Подход с firestore и тригерами мы используем в сервисе верификации емейлов http://mailcheck.co — но там для ускорения разработки использован еще и firebase auth и вообще все что только можно готовое.
Но Impress мы тоже использовалеи, чуть ранее на другом проекте Nodex, но увы его постигла участь многих блокчейн проетов, поэтому пощупать на нем JSTP в лайве сейчас не выйдет. Но мы были очень довольны скоростью и удобством разработки приложений для Impress, хотя как раз функционал масштабирования нам не пригодился на этом проекте.
Ну зачем в 2019м году создавать новую библиотеку на колбеках?
Почему бы вместо сигнатуры (socket, payload, callback) -> void не использовать (socket, payload) -> Promise? Вы же сами написали всем функциям зачем-то async. Почему не пошли дальше и не заменили return callback(...) на return ...?
Функциям прописан async просто осталось случайно от реального кода где идёт await на обращение к базе данных. Сейчас уберу.
А зачем в таком случае вообще нужна ваша библиотека? Кажется, у socket.io уже есть все необходимое...
Тот кто захочет использовать такую связку скорее всего столкнется как и я с необходимостью структурировать код. Я решил эту проблему разработкой роутера. У кого то возникнут другие идеи. В всяком случае это не большая задача и может быть легко разработана и протестирвана. В отличии от других задач возникающих при разработки библиотек работающих с веб-сокетами
Вторая страшилка, про бан на websocket со стороны провайдеров или админов корпоративных сетей — также необоснованный, так как сейчас все используют протокол https, и понять что открыто соединение websocket (не взломав https) невозможно.
Есть основания. Правда, этот способ обрубает почти все, кроме https. Сам встречал такое, что обрывается любое tcp-соединение, которое длится больше минуты.
Инструменты Node.js разработчика. Удаленный вызов процедур на веб-сокетах