LINUX.ORG.RU

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

 ,


0

2

Для работы с API я предлагаю использовать JSON RPC поверх вебсокетов. Зачем так делать? - Это экономия ресурсов сервера, причем нехилая. Как работает обычное веб-приложение через REST API? - Оно с помощью JavaScript, используя функцию fetch либо инстанс XMLHttpRequest, посылает запросы. На каждый запрос создается новое соединение и после получения данных, оно закрывается. Для клиента 2/3 времени от выполнения запроса уходит на установку соединения с сервером. Сервер же для каждого соединения порождает процесс, подпроцесс либо тред в зависимости от программной реализации. Таким образом выигрывают клиент и сервер. Для ускорения работы можно использовать балансировку через nginx: `создать количество_процессоров * 2 + 1` воркеров и распределять запросы между ними.

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

Я сейчас занимаюсь только тем что штампую SPA. Так вот у меня все равно уведомления через веб сокеты работают. Зачем мне сранный REST?

Наброски, сделанные за пару часов:

Исходники

Вообщем, хочу услышать мнения.

★★

Ответ на: комментарий от quester

зачем в JSON RPC идентификаторы по вашему?

Ооо, в JSON-RPC есть идентификаторы запросов, кто бы мог подумать. Наверное, в Sun RPC их не было.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ооо, микроскоп создан для забивания гвоздей, попробуйте опровергнуть что это не так!

quester ★★
()
Ответ на: комментарий от quester

Да, они именно затем. И?

микроскоп создан для забивания гвоздей, попробуйте опровергнуть что это не так!

Зачем? Я просто сделаю утверждение: микроскоп не был создан для забивания гвоздей. Согласен ты с эти или нет, меня не волнует.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от tailgunner

они затем что ответ может следовать не после запроса и нам нужно ловить ответ по id, что это как не асинхронное выполнение?

quester ★★
()
Ответ на: комментарий от tailgunner

вы как раз делаете обратное утверждение, можете забивать, другие будут микроскоп использовать как микроскоп, а JSON RPC как асинхронный протокол

quester ★★
()
Ответ на: комментарий от quester

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

Это с какой стороны нужно смотреть? И какие из этого напрашиваются выводы? Не нужно?

anonymous
()
Ответ на: комментарий от tailgunner

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

REST подразумевает немедленный/синхронный ответ на только что пришедший запрос, без постановок в очередь, а JSON RPC подразумевает очередь и отложенный/асинхронный ответ

quester ★★
()
Ответ на: комментарий от quester

Я просто сделаю утверждение: микроскоп не был создан для забивания гвоздей. Согласен ты с эти или нет, меня не волнует.

вы как раз делаете обратное утверждение

Ты лжешь.

другие будут микроскоп использовать как микроскоп, а JSON RPC как асинхронный протокол

Не вопрос. Любой сетевой протокол можно использовать как асинхронный. Правда, он при этом перестает быть RPC: https://searchmicroservices.techtarget.com/definition/Remote-Procedure-Call-RPC

REST подразумевает немедленный/синхронный ответ на только что пришедший запрос, без постановок в очередь

Это не REST подразумевает, а лично ты. Ничто не мешает поставить REST-запрос в очередь (как оно всегда и делается).

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от anonymous

Не нужно?

как раз нужно что и доказывает google с его gRPC

quester ★★
()
Ответ на: комментарий от tailgunner

Ничто не мешает поставить REST-запрос в очередь (как оно всегда и делается).

«Ты лжешь.» Делается так только когда внедряют что-то типа JSON RPC/gRPC и делают временный wrapper для старых тупых клиентов.

quester ★★
()
Последнее исправление: quester (всего исправлений: 1)
Ответ на: комментарий от quester

Ничто не мешает поставить REST-запрос в очередь (как оно всегда и делается).

«Ты лжешь.

Нет. Ты просто плохо понимаешь, как работает сервер и ОС.

tailgunner ★★★★★
()
Ответ на: комментарий от quester

я чувствую до вашего уровня просветления мне еще слава богу далеко

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

постараюсь держаться от него подальше и вести здоровый образ жизни. так для чего же в JSON RPC идентификаторы? ошибка в протоколе? шизофазия?

quester ★★
()
Ответ на: комментарий от quester

так для чего же в JSON RPC идентификаторы?

Полагаю, что для того же, что и XID-ы в Sun RPC.

Ссылку хоть почитай

Эту что ли? goo.gl/1WLn5q

Реализация API на вебсокетах (комментарий)

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Полагаю, что для того же

Вообщем можете использовать асинхронный протокол как синхронный. Смысла дальше обсуждать это не вижу.

quester ★★
()
Ответ на: комментарий от tailgunner

Не вопрос. Любой сетевой протокол можно использовать как асинхронный. Правда, он при этом перестает быть RPC

Пока ты это не написал то формально был прав, а вот теперь опустился на уровень анонимуса.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Не вопрос. Любой сетевой протокол можно использовать как асинхронный. Правда, он при этом перестает быть RPC

Пока ты это не написал то формально был прав

Формально, я и остался прав. Ну или объясни, в чем именно я перестал быть прав.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Любой сетевой протокол можно использовать как асинхронный.

Погугли синхронные сетевые протоколы. Убедись что некоторые нельзя использовать как асинхронные.

или (скорее в исключающем смысле)

Правда, он при этом перестает быть RPC

Не перестанет, достаточно найти пункт асинхронные вызовы в спеках на упомянутый тобой же Сан-РПЦ или же великую и ужасную КОБРУ. Лично я не помню чтобы РПЦ в общем смысле декларировал запрет на асинхронный вызов. По умолчанию блок вызывающего потока (спасибо буковкам ПЦ) вроде как подразумевается (неявно!), но если начать копать спеки на какие-либо реализации РПЦ, они таки довольно часто определяют асинхронные вызовы.

При чем если спеки некоторых протоколов явно запрещают асинхронщину, то в рпц таких явных запретов нет.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Погугли синхронные сетевые протоколы.

Гугл не выдает ничего релевантного. Назови имена протоколов.

Убедись что некоторые нельзя использовать как асинхронные.

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

Не перестанет, достаточно найти пункт асинхронные вызовы в спеках на упомянутый тобой же Сан-РПЦ

Что-то не нахожу. в https://tools.ietf.org/html/rfc5531 Но там есть:

«The caller first sends a call message to the server process and waits (blocks) for a reply message. The call message includes the procedure's parameters, and the reply message includes the procedure's results. Once the reply message is received, the results of the procedure are extracted, and the caller's execution is resumed.»

КОБРУ

Это типа шутка? КОРБА. Там асинхронные вызовы перестали быть процедурными вызовами, получающими аргументы и возвращающими значения, и стали постановкой запроса в очередь.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Назови имена

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

не нахожу

Прочитай 2 абзаца вниз. Там прямым текстом.

КОРБА

Она самая. Можешь погуглить ami for ccm. Они вроде бы везде называют это не procedure call а method invocation, но суть то не меняется.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Например sldc

А, понятно. Но это протоколы звена передачи данных, как тогда говорили. Не то, что понимается под сетвыми протоколами и не то, что я имел в виду.

Прочитай 2 абзаца вниз. Там прямым текстом.

Там сказано о реализации сервера.

Они вроде бы везде называют это не procedure call а method invocation, но суть то не меняется.

Суть меняется от того, что это перестало быть вызовом.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

не то, что я имел в виду

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

реализации сервера

ладно процитирую

In this model, only one of the two processes is active at any given time. However, this model is only given as an example. The ONC RPC protocol makes no restrictions on the concurrency model implemented, and others are possible. For example, an implementation may choose to have RPC calls be asynchronous so that the client may do useful work while waiting for the reply from the server. Another possibility is to have the server create a separate task to process an incoming call so that the original server can be free to receive other requests.

Тут явным образом указано что извращения допустимы с обеих сторон.

перестало быть вызовом

Вики:

In computing, the Java Remote Method Invocation (Java RMI) is a Java API that performs remote method invocation, the object-oriented equivalent of remote procedure calls (RPC)

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

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Это то понятно, но разве от этого sldc перестал быть сетевым?

SDLC. Он никогда и не был сетевым. Это протокол звена передачи данных.

Тут явным образом указано что извращения допустимы с обеих сторон.

Реализация API на вебсокетах (комментарий)

the Java Remote Method Invocation (Java RMI) is a Java API that performs remote method invocation, the object-oriented equivalent of remote procedure calls (RPC)
Ну блин, ну назвали иначе

Я не знаком с RMI. А причем он здесь? Мое «перестало быть вызовом» относилось к CORBA.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Кобра это рми, рми это такой рпц с объектами. Поэтому в доках вместо пц написано ми, хотя фактически разговор о пц. Таки я не понял почему у тебя кобра не рпц?

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

ya-betmen ★★★★★
()
Ответ на: комментарий от tailgunner

я этот наводящий вопрос еще до него задавал. логика должна была подсказать для того чтобы знать на какой запрос пришел ответ. а так верно большинство реализаций rpc(поверх хттп) синхронны, там даже есть отстуления от стандарта когда не нужен айдишник запроса. никто и не запрещает свою реализацию сделать. для питона, например, удобно использовать что-то типа {«method»:"...",«args»:[],«kwargs»:{}}. а так да у моего способа много недостатков. основной, что пхпмакаки не смогут сделать клиента для работы с моей апишкой.

tz4678 ★★
() автор топика
Ответ на: комментарий от ya-betmen

Кобра это рми

Кобра - это змея. Я знаю, что такое CORBA, но практически ничего не знаю об RMI. Аругменты об RMI я не понимаю.

Поясни как синхронность процедурного вызова влияет на синхронность протокола?

Если тебе так будет понятнее, RPC - это способ использования протокола. Протокол может быть любым.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Аругменты об RMI я не понимаю.

Ладно отложим рми в сторону. Смотрим спеки на разные рпц, без рми.

RPC - это способ использования протокола. Протокол может быть любым.

Ок в общем согласен, но тогда не ясно что ты имеешь против асинхронного рпц? Рпц это абстрактная логика взаимодействия компонентов через сеть. И если конкретная реализация этого рпц содержит в спеке указания на возможность асинхронных вызовов этот протокол всё равно остаётся рпц и вызов этот остается пц, т.к. в данном случае пц довольно растяжимое понятие. Не?

ЗЫ, я прекрасно понимаю чем именно ты тролил анонимуса, но блин не стоит настолько увлекаться.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

но тогда не ясно что ты имеешь против асинхронного рпц?

Приведи определение «асинхронного RPC». Если не общепринятое, то хотя бы то, которым ты пользуешься.

Рпц это абстрактная логика взаимодействия компонентов через сеть.

Эта «абстрактная логика» включает в себя _вызов_ - т.е. неделимую операцию передачи аргументов и возврата результатов. Неделимую с точки зрения пользователя RPC - «под капотом» может быть что угодно.

P.S. и кто такой анонимус, которого я троллил - регистрант, известный как «Царь»?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Эта «абстрактная логика» включает в себя _вызов_ - т.е. неделимую операцию передачи аргументов и возврата результатов.

Кажется нашёл камень преткновения. Если я при вызове метода (локального) верну не результат а указатель но место, где он через некоторое время появится ты будешь считать это вызовом или уже нет?

регистрант, известный как «Царь»?

Я думал quester это anoninous, попутал значит.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Если я при вызове метода (локального) верну не результат а указатель но место, где он через некоторое время появится ты будешь считать это вызовом или уже нет?

Нет, потому что вызов еше не завершен (и нельзя просто вернуть «указатель на место», но это техническая деталь).

tailgunner ★★★★★
()
Ответ на: комментарий от ya-betmen

Когда результат гарантированно появляется к завершению оператора вызова, без усилий со стороны пользователя - это вызов, иначе это обмен сообщениями (поверх которого, естественно, может быть реализован вызов).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

без усилий со стороны пользователя - это вызов, иначе это обмен сообщениями

В смысле усилий со стороны пользователя? Если апи/фрейморк/компилятор скрывает от пользователя ожидание появления данных это вызов?

поверх которого, естественно, может быть реализован вызов

Значит всё таки вызов?

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

В смысле усилий со стороны пользователя? Если апи/фрейморк/компилятор скрывает от пользователя ожидание появления данных это вызов?

Для пользователя - да, это вызов.

поверх которого, естественно, может быть реализован вызов

Значит всё таки вызов?

Нет.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Считаешь ли ты достаточным для сохранения названия рпц чтобы вызов был «вызовом для пользователя»?

ya-betmen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.