Реализация API на вебсокетах

Я не про возможно/невозможно реализовать, я про простоту и универсальность. Классический случай головной боли с голыми событиями - поиск с динамической подгрузкой.

Обилие макак от кодинга привело к появлению всевозможных синхронных оберток

после того как появятся корутины вместе с асинками/эвейтами в C++20 он станет языком для макак и ты начнешь программировать на ASSемблере?

а ведь так хотелось на твой сайт зайти...

а ведь так хотелось на твой сайт зайти...

И это все эмоции, которые у тебя вызывает заставка на сайте?
Это ведь не государственная блокировка, а заставка, которая генерится именно на этом самом сайте и имеет прямое отношение к владельцам домена.

Это твой пыхтон пыхтит как умеет. Возьми нормальный сервер.

речь про то что fetch из браузера порождает несколько соединений

про ограничение в 2000 символов на длинну request uri я не упоминал. в это ограничение я еще никогда не упирался.

ограничение зависит от конкретного web сервера и то что не упирался не значит что не упрешься, а не определенности не место в надежных программах. нам же не нужны undefined behavior?

Нет, на самом деле он просто пишет несвязный бред. Как и обычно.

все по делу он написал, Keep-Alive не дает асинхронности

И где я это писал?
Вообще что за бред ты несешь? Какой Keep-Alive и асинхронность?

http подразумевает формат запрос-ответ, те нам необходимо дожидаться ответа на запрос. при помощи же json rpc мы можем накидывать серверу запросов и асинхронно получать на них ответы

Вызов отменяет асинхронщину. Иначе это не вызов, а посылка сообщения с явным ожиданием ответа.

И какие проблемы на сервере не вызывать этот метод сразу, а поставить его например в приоритетную очередь? Признайте уже что JSON RPC асинхронный протокол.

Да пусть хоть сто. Не браузер разруливает кип-алайф.

Да пусть хоть сто.

Вот на сто запросов будут порождены сто коннектов, а в случае с websocket это не так. Об этом вам и объяснял ТС.

Эта асинхронность лишь кажущаяся и видится только на стороне клиента, но всё зависит от сервера, на какой запрос ответить первее или сколько надо данных перелопатить или может ещё куда обратиться и дождаться ответа, чтобы ответить.

естественно и от сервера и от клиента. ТС не хочет на каждый запрос пораждать коннект, а также хочет асинхронности - логично использовать что-то типа json rpc поверх websocket - сам такое юзаю.

будут порождены сто коннектов

Нет, если используется кип-алайв (для хттп1.0) или хттп1.1

Ты мне опять бред с твинка пишешь?

при помощи же json rpc мы можем накидывать серверу запросов и асинхронно получать на них ответы

Не нужно распространять свои маняфантазии на спеку.
К тому же нам не нужно rpc, для этого подойдет и CQRS, где команда возвращает идентификатор.

Юзай. Но не рекламируй это говно как «новейшее» лекарство от обсуждаемой проблемы.

Нет, если используется кип-алайв

да согласен, но делая запрос мы вынуждены ждать ответ на него - нет асинхронности

Не нужно распространять свои маняфантазии на спеку.

какие фанатазии? в HTTP мы не можем посылать запрос до тех пор пока не получили ответ на предыдущий (даже если у вас keep alive), в JSON RPC - можем

К тому же нам не нужно rpc, для этого подойдет и CQRS, где команда возвращает идентификатор.

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

в HTTP мы не можем посылать запрос до тех пор пока не получили ответ на предыдущий

Что мне помешает, а? JSON RPC over HTTP работает так же.

нет асинхронности

Её и не было. Она только у тебя в голове, только в контексте клиента.

А, ну-ка:

На бекенде страничка при каждом обращении выдаёт циферки от 1 до 20 без привязки к конкретному клиенту, т.е. где-то надо хранить предыдущее значение.

А теперь открывай вкладку и быстро жми F5 от 1 до 20 раз. Совпадёт ли кол-во нажатий на F5 и выведенная циферка?

HTTP pipelining

Что мне помешает, а? JSON RPC over HTTP работает так же.

Так это уже JSON RPC, а не REST

Совпадёт ли кол-во нажатий на F5 и выведенная циферка?

Совпадет и что с того?

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

HTTP pipelining

это http2 only и как там с обработкой обрыва коннекта?

Совпадет

Нет ))

Нет ))

если ситуация гонки будет устранена локом то совпадет, да это и не важно, не для этого это нужно

И какие проблемы на сервере не вызывать этот метод сразу, а поставить его например в приоритетную очередь?

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

Признайте уже что JSON RPC асинхронный протокол.

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

Если ты повесишь лок — плакала твоя асинхронность.

Кста, это нихрена не ситуация гонки. Сервер ответит на все отправленные запросы. А вот клиент (конкретно тут — браузер) что там первым примет, то и покажет.

А теперь скажи, при отсутствии лока данных на бекенде, будет ли вести себя браузер так же, если использовать фетч, аякс, вебсокеты?

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

офигенно, где язык и где протокол? можно и на brain fuck что угодно написать, мы говорим о том что уже сделано.

в rest подобное не предусмотрено и ответы синхронны поэтому это синхронный протокол, а в JSON RPC предусмотрено и ответы асинхронны поэтому это асинхронный протокол вот и все.

Если ты повесишь лок — плакала твоя асинхронность.

лок вешается в REST, а в JSON RPC не вешается

в JSON RPC лок не вешается

Значит там АД, не имеющий никакого отношения к актуальности и целостности данных.

Кста, это нихрена не ситуация гонки. Сервер ответит на все отправленные запросы. А вот клиент (конкретно тут — браузер) что там первым примет, то и покажет.

о чем вообще речь? о множестве клиентов?

А теперь скажи, при отсутствии лока данных на бекенде, будет ли вести себя браузер так же, если использовать фетч, аякс, вебсокеты?

максимально мутный и вопрос. фетч и аякс это HTTP

Значит там АД, не имеющий никакого отношения к актуальности и целостности данных.

почитайте уже что такое JSON RPC

о множестве клиентов

Не сливай, это про одного клиента.

фетч и аякс это HTTP

Отлично. Значит там точно жопа. Что насчет вебсокетов?

Херня, которая думает что она асинхронна.

Не сливай, это про одного клиента.

что за манеры милейший? если речь про одного клиента то что значит «клиент (конкретно тут — браузер) что там первым примет, то и покажет»? Через HTTP клиент примет то на что делал запрос. Делал запрос на очередное значение вашего глобального счетчика значит его и получит.

Что насчет вебсокетов?

вопрос сначала конкретней сформулируйте

Херня, которая думает что она асинхронна.

вы это гуглу с его gRPC скажите

значит его и получит

Нет!

вопрос сначала конкретней сформулируйте

Реализация вебсокетов в браузерах так же подвержена рассинхронизации порядка запрос-ответ?

Нет!

сформилируйте значит о чем вы говорите

Реализация вебсокетов в браузерах так же подвержена рассинхронизации порядка запрос-ответ?

в websocket вы не лочитесь на функции send() вы просто отправляете запросы и ловите ответы в onmessage. fetch в HTTP то-же конечно возвращает promise и может быть типа асинхронно на клиенте

особенно интересно в такой схеме гонять неидемпотентные запросы ).

Еще недостаток REST (RESTful) - это то что данные предлагается получать методом GET, а он неможет иметь тела, поэтому приходится параметры из QueryString цеплять, приводить к нужным типам (некоторые драйверы баз данных типа того же asyncpg не приводят автоматически строки к нужным типам).

Это еще не значит, что POST невозможен. Не забывайте, что максимально разумная допустимая длина урла около 1 Kb - больше можно, но не все клиенты поддерживают. Так что странно, что POST нельзя.

Я сделал это выше.

Я сделал это выше.

значит моего мозга не хватает понять вашу гениальность

офигенно, где язык и где протокол?

Шта?

можно и на brain fuck что угодно написать, мы говорим о том что уже сделано.

Я говорю о том, что такое RPC и поче му он в принципе синхронный.

в websocket вы не лочитесь на функции send() вы просто отправляете запросы и ловите ответы в onmessage. fetch в HTTP то-же конечно возвращает promise и может быть типа асинхронно на клиенте

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

Могу ли я повесить onmessage (onresponse? лол) на конкретное сообщение в вебсокет? (подсказка: нет)

И я не говорю что это плохо.

Если человек хочет именно rpc, то пусть занимается запоминанием requestId и всем таким прочим, это его время, это его право.

Если человек не слышал про конечные автоматы и не понимает как пользоваться асинхронными сообщениями, то это его проблемы.

ЗЫ: велосипед на капче как бы намекает

И я не говорю что это плохо.

Прежде всего вся эта асинхроность нужна для backend

он в принципе синхронный.

черное это белое, белое это черное. ok. вам можно.