Websocket или REST? А зачем выбирать?

[danial72]

Может не стоит изобретать велосипед и просто использовать grpc ?

[lesivOlexandr]

gRPC для браузера работает за счёт fetch и xhr, а не websocket. Безусловно, в gRPC есть свое область применения, но это не то, что я имел в виду под выполнением каждого действия и с помощью http-запросов, и websocket

[t38c3j]

Есть jsonrpc, можно в http и ws

[kaegoorn48]

Вебсокет поддерживается, наверное, всем чем можно, а если что-то не поддерживает, то реализовать поддержку можно без проблем, есть RFC 6455 и 8441 сел и написал.
GRPC это сильно монструозная штука, имеющая ряд недостатков:

• если вы разрабатываете публичный API, то gRPC не для вас, т.к. не gRPC не поддерживается рядом клиентов или же эта поддержка

• если вы пишите асинхронный однопоточный микросервис, то встраивание gRPC окажется большой проблемой. Нужно будет решать проблему с очередью сообщений, кроме того однопоточным ваш сервис уже не станет

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

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

• преимущество GRPC в части снижения оверхеда, основанное на предположении, что бинарная сериализация быстрее чем, например, jsonrpc, к сожалению, в данном случае не работает.

Но если ваш API не является публичным, работает в закрытом контуре, и используются многопоточные сервисы, то gRPC весьма хорош.

Почти все вышеперечисленные недостатки касаются также Apache Thrift

[lesivOlexandr]

GraphQL в браузере работает поверх обычных HTTP-запросов, хотя есть так же библиотеки GraphQL Over Websocket, которые делают по сути то же самое, что описано статье, но для GraphQL

[niyaho8778]

если я открываю несколько соединений к одно и тому же серверу через

var x = new websocker (подчеркиваю через new).

Мне в прошлый раз скзали что браузер автоматически объединяет (берет соседнее) соединение или это вранье ?

[lesivOlexandr]

Только что проверил, и при открытии соединений с помощью new WebSocket(url) в браузере в вкладке Networks их все показывает, как разные, поэтому вряд ли браузер их переиспользует

[return]

Держать постоянно открытый коннект — далеко не всегда хорошая и дешевая идея.

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

[xPomaHx]

Обычный http старше 1.0 и так постоянно держит открытый коннект, а может и не 1. Веб сокеты можно использовать лениво, если схема только запрос ответ, то можно клоузать соединение после использования или по таймауту если неактивно, потом открывать заново прямо из js.

[diomas]

Вроде основной смысл вебсокета в том, что вторая сторона (сервер) может так же пушить сообщения и не нужен постоянный пуллинг со стороны клиента (или хаки типа long-polling)

REST тут получается не пришей кобыле хвост

[lesivOlexandr]

UDP так-то тоже создавался для однонаправленных сообщений, но сейчас на нем базируется HTTP/3, который уже стандарт, который поддерживают все современные браузеры Google. К тому же для пересылки сообщений только от сервера к клиенту есть Server Sent Events, а WebSocket создавался для двунаправленного обмена сообщениями между клиентом и сервером

[splix]

Скажите, что вы думаете про HTTP2 в данном контексте?

[kaegoorn48]

RFC 8441

[splix]

Я имею ввиду что описанные проблемы судя по всему решены в HTTP/2. И соответсвенно вопрос про то насколько это все сейчас имеет смысл, или что мешает начать использовать HTTP/2.

[marsdenden]

Всему свое место. Ресту рестово, сокету сокетово. Отладка сокетов - тот еще квест

[feverqwe]

А почему вы считаете что keep alive не работает с обычными rest запросами?

[lesivOlexandr]

Потому что он не работает с HTTP/2, хотя не уверен насчет HTTP/3 и в первой версии таки работает

[feverqwe]

Оно не поддерживает keep-alive, но http2 переиспользует TCP соединение из коробки и поэтому не требуется заголовок.

[devoln]

Не вижу смысла в вебсокетах, когда повсеместно доступен HTTP/2 и возможность с его помощью легко реализовать server-sent events для подписки на события.