Комментарии 20
Может не стоит изобретать велосипед и просто использовать grpc ?
Вебсокет поддерживается, наверное, всем чем можно, а если что-то не поддерживает, то реализовать поддержку можно без проблем, есть RFC 6455 и 8441 сел и написал.
GRPC это сильно монструозная штука, имеющая ряд недостатков:
если вы разрабатываете публичный API, то gRPC не для вас, т.к. не gRPC не поддерживается рядом клиентов или же эта поддержка
если вы пишите асинхронный однопоточный микросервис, то встраивание gRPC окажется большой проблемой. Нужно будет решать проблему с очередью сообщений, кроме того однопоточным ваш сервис уже не станет
нужно решать проблему балансировки. Конечно современные прокси-сервисы поддерживают grpc, но в любом случае это добавляет геморроя
если вам нужен нестандартный сериализатор, то это тоже большая проблема
преимущество GRPC в части снижения оверхеда, основанное на предположении, что бинарная сериализация быстрее чем, например, jsonrpc, к сожалению, в данном случае не работает.
Но если ваш API не является публичным, работает в закрытом контуре, и используются многопоточные сервисы, то gRPC весьма хорош.
Почти все вышеперечисленные недостатки касаются также Apache Thrift
если я открываю несколько соединений к одно и тому же серверу через
var x = new websocker (подчеркиваю через new).
Мне в прошлый раз скзали что браузер автоматически объединяет (берет соседнее) соединение или это вранье ?
new WebSocket(url) в браузере в вкладке Networks их все показывает, как разные, поэтому вряд ли браузер их переиспользует
Держать постоянно открытый коннект — далеко не всегда хорошая и дешевая идея.
Ну и опять же, у обычного http тоже есть плюшки, например, браузерное кеширование
Вроде основной смысл вебсокета в том, что вторая сторона (сервер) может так же пушить сообщения и не нужен постоянный пуллинг со стороны клиента (или хаки типа long-polling)
REST тут получается не пришей кобыле хвост
Скажите, что вы думаете про HTTP2 в данном контексте?
Всему свое место. Ресту рестово, сокету сокетово. Отладка сокетов - тот еще квест
А почему вы считаете что keep alive не работает с обычными rest запросами?
Не вижу смысла в вебсокетах, когда повсеместно доступен HTTP/2 и возможность с его помощью легко реализовать server-sent events для подписки на события.
Websocket или REST? А зачем выбирать?