Здравствуйте, alex_public, Вы писали:
NB>>я же пример приводил -- команды гет в одну сторону, другие в другую.
_>Да, прошу прощения, что пропустил это тогда, хотя ещё тогда должен был среагировать. Собственно реакция: _>А зачем собственно может понадобится подобная сомнительная балансировка?
там же написал, немодифицирующие запросы можно обрабатывать на зеркалах базы.
только не спрашивай, зачем
NB>>как ты это будешь в grpc делать?
_>Если мне вдруг всё же понадобится реализовывать подобное (крайне сомневаюсь в полезности подобной задачи), то я просто поделю весь сервис на две части (с мутабельными и иммутабельными функциями), разместив их соответственно по разным адресам (т.е. так весь gRPC сервис живёт на одном URL, а так будет на двух).
Здравствуйте, night beast, Вы писали:
_>>Если мне вдруг всё же понадобится реализовывать подобное (крайне сомневаюсь в полезности подобной задачи), то я просто поделю весь сервис на две части (с мутабельными и иммутабельными функциями), разместив их соответственно по разным адресам (т.е. так весь gRPC сервис живёт на одном URL, а так будет на двух). NB>то есть будешь колхозить, о чем и речь.
Так что там колхозить-то? gRPC можно балансировать классически: https://towardsdev.com/grpc-request-routing-header-based-aws-alb-9934c1b4c67e — в этом примере балансирование на основе заголовка, но можно и по префиксу имени метода.
Здравствуйте, alex_public, Вы писали: _>Ой, ну к чему эти глупые фантазии))) Двухсторонний канал банально невозможен в REST.
Формально — да, у нас любой запрос в REST является "атомарным". Делаем GET, рассчитываем на хидер Content-Length, вычитываем указанное количество байт, и только потом начинаем разбор.
Однако мы можем несколько отступить от строгих требований, и в ответ на GET получить поток структурированных фрагментов, которые мы будем разбирать, не дожидаясь окончания передачи.
То есть сервер отдаёт столько данных, сколько у него есть, но не закрывает соединение, а продолжает отправлять "сообщения" по мере поступления. Вот вам и "двусторонний" канал.
Более того — в случае внезапного обрыва соединения у клиента есть штатный способ запросить данные не с нуля, а с того байта, на котором произошёл обрыв.
Технологии COMET больше лет, чем AJAX. Кстати, не расскажете, как gRPC обрабатывает ситуацию обрыва соединения? Как клиенту получить остаток потока с того места, до которого он дочитал в прошлый раз?
_>Ну т.е. чтобы это заработало, это надо написать руками. Так и в gRPC тоже самое. В чём отличие то по твоему? )))
Конечно же в обратной совместимости, negotiation и graceful degradation.
_>Ну для начала здесь у нас как раз каноничный срез коллекции. Просто видимо ты запутался и не заметил, что тут у нас коллекцией является не массив с монотонным индексом (типа времени), а словарь (по всем инструментам). И соответственно срез описывается не интервалом "от и до", а полным перечислением ключей. _>Если же ты хотел именно банальный срез монотонного массива, то там прямо рядом лежит функция https://tinkoff.github.io/investAPI/marketdata/#getcandlesrequest с классическими параметрами среза from и to, возвращающая классический кусок массива.
Нет, я не хотел ни весь массив, ни монотонный срез.
Я хотел получить список элементов, изменённых с определённого момента времени. А вы путаете Range с Delta encoding.
Рекомендую прочитать RFC 3229, секцию 4.1, до наступления просветления.
Ну, и с чтением документации у вас некоторые проблемы. Метод https://tinkoff.github.io/investAPI/marketdata/#getcandlesrequest возвращает совсем не подмножество данных https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest, а вообще другие данные.
Что я ожидаю от delta-encoding применительно к https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest? Пустого массива, если с момента моего последнего запроса не изменилось ничего. Массива из одного элемента, если с момента моего прошлого запроса прыгнул курс доллара (а остальные инструменты остались неизменными), и так далее. Как видим, в теории RPC позволяет такое сделать — но это потребует сразу заложить всё в сигнатуре методов. Я не могу написать сервер, который реализует только часть задокументированного протокола.
Я не могу написать клиента, который договаривается с сервером в стиле "если умеешь — то отдай дельту; если не умеешь — отдай весь список".
Точнее, могу, но мне нужно обладать дьявольской предусмотрительностью. Нужно заранее спроектировать такую возможность и заложить её в сигнатуры. Нужно заранее спроектировать метод договорённостей, когда клиент запрашивает у сервера список тех методов, которые поддерживаются сервером, а сервер отвечает, типа "умею conditinal get, но не умею в ranges" и так далее. _>И теперь вот вопросик, а как тоже самое канонично описать в REST архитектуре? Просто идеологически тут явно должно быть GET, но при этом передавать массив строк в url как-то крайне печально... )))
Да ничего печального тут нет. Можно и список запихать в URL — в данном конкретном случае сколько там у нас реально инструментов торгуется на бирже? Тысяча? Полторы? Нет никаких проблем запихать хоть "все инструменты, кроме одного" напрямую в URL. В том числе и в компактном виде — сначала упаковав список в какой-нибудь околобинарный енкодинг, а потом в base64.
Потери производительности на "принудительную текстовость" будут пренебрежимо малы по сравнению с сетевыми задержками.
Можно реализовать это вторичными способами — например, сделав метод subscribe, который превращает список интересных нам инструментов в один идентификатор подписки, вслед за которым будут выполняться GET /subscriptions/####.
_>Ааа, ну т.е. "в рамках CRUD можно представить всё, что угодно", если это сложные задачи, а вот простые задачи с помощью CRUD плохо представляются... Понятно, понятно...
Да прекрасно они представляются при помощи CRUD. Трудности возникают тогда, когда у нас требования response time начинают доминировать над требованиями consistency.
Сложная задача — это когда у нас есть развесистая структура предметной области и развесистая логика на серверной стороне.
А мы говорим про задачу, ER-схема которой уместится на одном листочке школьной тетрадки.
_>Так надёжность или сложность? ) Я уже что-то запутался... )))
И надёжность, и сложность.
_>А особенно забавно это всё звучит с учётом того факта, что REST по сути является строгим подмножеством RPC.
Нет, не является. В REST введены концепции, которых в RPC просто нет, как класса. Нет понятия safety, нет понятия idempotence.
_>Тогда это был единственный интерфейс. А сейчас это официально старая версия, оставленная для совместимости и работающая через тот самый прокси.
_>Что-то ты сам себе противоречишь. В предыдущем сообщение же сам признал, что для данной задачи REST не особо подходит.
REST не особо подходит для задачи, где нужно передавать простые данные с минимальной задержкой, при этом потерями при передаче можно пренебречь.
При этом нужно быть очень аккуратным при проверке этих ограничений. К примеру, рассуждения о минимизации задержки бессмысленны, когда у нас клиент расположен в 200мс от сервера. Там накладные расходы на передачу парсинг HTTP-заголовков запроса в REST-подходе составляют единицы миллисекунд. А вот если мы ставим сервер в соседнюю стойку, то разница между 0мс для gRPC stream и 1ms REST request становится существенной.
Осторожность здесь важна для того, чтобы не принимать решение для 200мс ping times на основании рассуждений, которые справедливы для 0мс ping time.
_>Не обязательно в том же дата-центре. Но точно в каком-то дата-центре (а не на домашнем компьютере).
А вы думаете, что датацентр в Новосибирске будет сильно ближе к серверам NYSE по сравнению с домашним компьютером в Новосибирске?
Я вас разочарую: физику не обманешь. Тысяча километров — это тысяча километров, и тридцать хопов — это тридцать хопов.
_>У меня тут один старый сайтик есть, сохраняемый из ностальгических соображений. Он полностью статический. И теперь я кажется начинаю понимать, что он на самом деле сделан по архитектуре REST! Ну у него там есть разные URL'ы, к ним можно послать GET запросы и получить данные...
Отлично. Я вижу, у вас наступает просветление. Ещё немного, и вы узнаете, что Филдинг изобрёл REST как раз при проектировании HTTP.
То есть всё именно так — весь HTTP построен по идеологии REST, а вовсе не наоборот.
Просто сервер, который раздаёт по HTTP файловый контент, реализует REST "из коробки". Благодаря чему прекрасно работают такие решения, как CDN, forward & reverse proxy, а также зеркала сайтов.
А когда мы через HTTP выставляем не файлы, а приложения, то нужно немножечко постараться, чтобы не испортить прекрасную REST архитектуру своими корявыми руками (как это сделали, к примеру, авторы https://tinkoff.github.io/invest-openapi
_>Вообще, когда человек отвечает подобным образом на подобную задачу, то это может означать только одно из двух: _>1. Он абсолютно не компетентен как инженер (не понимает слов ТЗ и т.п.) _>2. Он вполне компетентен и всё понимает, но честный ответ на задачу демонстрирует его неправоту, поэтому он начинает вилять и менять ТЗ.
Считать ТЗ божьим словом, высеченным на скрижалях, могут себе позволить только джуны. Даже миддл начинает задаваться вопросом "а зачем мы это делаем?" и подвергать навязанные решения сомнению.
_>Забавно, у нас в приложение по сути являющемся RPC клиентом (причём не gRPC, а вообще самодельном на базе WebSocket) в браузере, кнопка back отлично работает. Может всё дело в кривизне рук? )))
Может быть. В принципе, можно и из SOAP изобразить более-менее приличное решение. Правда, там придётся переизобрести с нуля REST, и получить велосипедную его реализацию, не совместимую ни с чем.
Но лучше сразу проектировать приложение с учётом особенностей физической реальности — в частности, ненадёжности коммуникаций и ограниченности полосы пропускания.
_>Да я уже понял, что ты выставишь требование изменения железа по причине того, что оно плохо сочетается с любимой тобой программной архитектурой. Интересно, как тебя на работу принимали с такими подходами? ) Или ты там при приёме скрывал подобные замашки? )))
Меня обычно принимают на работу как раз для того, чтобы я предложил архитектурные решения, дающие нужный результат.
А не для того, чтобы "выставить в интернет протокол удалённого управления вертелкой камеры".
Потому, что далеко не всем очевидно, что надо задумываться не только о единственном позитивном сценарии, типа "один пользователь за бесконечно надёжным каналом с бесконечно большой полосой пропускания отправляет редкие команды", но и над всеми остальными сценариями, которые неизбежно возникнут в практической эксплуатации. Например — что делать, когда один пользователь жмёт "вправо", а другой — "влево".
Мои знания о том, как проектировать вот такие решения, неожиданно неплохо оплачиваются. Чего и вам желаю
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>Ну то есть, опять писать сразу нетленку без тестирования.
Да совершенно необязательно. В том-то и дело, что REST из коробки очень дружелюбен к развитию протоколов.
Вот мы сели, выписали минимально необходимый набор примитивов, с которыми будет работать клиент.
Сделали референс реализацию сервера. Может быть, сделали мок-сервер, который умеет что-то там отдавать.
Написали клиента в рамках этой минимальной спецификации, протестировали.
А затем, по мере обнаружения реальных эксплуатационных проблем, начинаем решать их по мере поступления.
Например видим, что у реальных клиентов возникают проблемы — мы отдаём им большие респонсы, а связь неустойчивая, и мало кто (кроме наших же локальных QA) ухитряется докачать эти гигабайты без обрыва.
Ок — говорим "давайте мы будем поддерживать ranges". Допиливаем сервер так, чтобы он поддерживал докачку.
Допиливаем клиента; тем, кто жалуется на обрывы, говорим "ставьте клиента версии 1.02 — он умеет докачивать оборванное".
При этом у нас наш сервер может быть раскатан не на все ендпоинты; клиентов мы не можем принудительно проапгрейдить всех — и всё прекрасно работает. Клиенты версии 1.0 работают с сервером версии 1.02, и клиенты версии 1.02 продолжают работать с серверами версии 1.0.
Обнаруживаем, что наши данные меняются локально, а пользователи выкачивают каждый раз по мегабайту? Допиливаем delta encoding на сервере, допиливаем его на клиенте, тестируем, публикуем.
И опять у нас полная взаимная совместимость.
Понимаем, что данные, которые мы отправляем, сильно избыточны? Прикручиваем gzip-компрессию.
И так далее, по списку.
C>>>Браузер тоже не поддерживает для всего. XMLHttpRequest его автоматически не умеет. Так что автоматически он будет только для ресурсов, которые включаются в HTML (т.е. изображения, скрипты, CSS). S>>И когда это XHR разучился использовать кэш браузера? В последний раз, как я этим интересовался, XHR работали точно так же, как и всё остальное. C>Не использует. fetch может использовать.
Странно. Я пытался подтверждение в интернете, но на стековерфлоу в основном обсуждается обратный вопрос — как заставить XHR перечитывать результат GET с сервера, а не из локального кэша.
Ладно, будет время — напилю какой-нибудь простой тест. C>При этом, ни один из известных мне небраузерных клиентов не поддерживает.
Это просто означает, что для тех клиентов такая проблема неактуальна. Ну, либо что их авторы плохо образованы, и тупо не знают возможностей используемого протокола. "Ну, а как вы хотели — 30 мегабайт это 30 мегабайт".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
NB>>то есть будешь колхозить, о чем и речь. C>Так что там колхозить-то? gRPC можно балансировать классически: https://towardsdev.com/grpc-request-routing-header-based-aws-alb-9934c1b4c67e — в этом примере балансирование на основе заголовка, но можно и по префиксу имени метода.
C>Но я бы явно разделил два endpoint'а.
вопрос не в том, можно или не можно это сделать.
вопрос в том что каждый будет это делать по-своему (или вообще не делать а потом, когда понадобится, судорожно все менять)
в отличие от РЕСТ, где это уже описано.
Здравствуйте, night beast, Вы писали:
C>>Так что там колхозить-то? gRPC можно балансировать классически: https://towardsdev.com/grpc-request-routing-header-based-aws-alb-9934c1b4c67e — в этом примере балансирование на основе заголовка, но можно и по префиксу имени метода. C>>Но я бы явно разделил два endpoint'а. NB>вопрос не в том, можно или не можно это сделать. NB>вопрос в том что каждый будет это делать по-своему (или вообще не делать а потом, когда понадобится, судорожно все менять) NB>в отличие от РЕСТ, где это уже описано.
Так и в REST оно тоже не "само" делается. Кто-то должен настроить маршрутизацию в зависимости от пути, причём правильно, чтобы это было прозрачно для клиентов.
Здравствуйте, Cyberax, Вы писали:
C>Так и в REST оно тоже не "само" делается. Кто-то должен настроить маршрутизацию в зависимости от пути, причём правильно, чтобы это было прозрачно для клиентов.
не в зависимости от пути а в зависимости от метода запроса, семантика которых (методов) четко прописана.
Здравствуйте, night beast, Вы писали:
C>>Так и в REST оно тоже не "само" делается. Кто-то должен настроить маршрутизацию в зависимости от пути, причём правильно, чтобы это было прозрачно для клиентов. NB>не в зависимости от пути а в зависимости от метода запроса, семантика которых (методов) четко прописана.
Да, в REST это более чётко прописано.
Но тем не менее, в REST нет способа указать гарантии целостности, например. Так что какой-то код может не работать, если GET после PUT будет перенаправляться на кластер, который не обеспечивает read-after-write. Всё равно нужно по обстоятельствам действовать, ровно как и в gRPC.
Здравствуйте, Sinclair, Вы писали:
_>>Ой, ну к чему эти глупые фантазии))) Двухсторонний канал банально невозможен в REST. S>Формально — да, у нас любой запрос в REST является "атомарным". Делаем GET, рассчитываем на хидер Content-Length, вычитываем указанное количество байт, и только потом начинаем разбор. S>Однако мы можем несколько отступить от строгих требований, и в ответ на GET получить поток структурированных фрагментов, которые мы будем разбирать, не дожидаясь окончания передачи. S>То есть сервер отдаёт столько данных, сколько у него есть, но не закрывает соединение, а продолжает отправлять "сообщения" по мере поступления. Вот вам и "двусторонний" канал. S>Более того — в случае внезапного обрыва соединения у клиента есть штатный способ запросить данные не с нуля, а с того байта, на котором произошёл обрыв. S>Технологии COMET больше лет, чем AJAX. Кстати, не расскажете, как gRPC обрабатывает ситуацию обрыва соединения? Как клиенту получить остаток потока с того места, до которого он дочитал в прошлый раз?
Вот зачем писать такой длинный текст, чтобы продемонстрировать подобную глупость? То, что ты описал — это даже не близко двухсторонний канал. Двухсторонний, это когда в рамках одного соединения и клиент и сервер могут в любой момент (в том числе даже и совпадающие) инициировать отсылку сообщения на противоположную сторону.
_>>Ну т.е. чтобы это заработало, это надо написать руками. Так и в gRPC тоже самое. В чём отличие то по твоему? ))) S>Конечно же в обратной совместимости, negotiation и graceful degradation.
Ты думаешь что использование английский слов как-то улучшает твою аргументацию? На самом деле это только показывает твоё слабое владение профессиональной терминологией.
_>>Если же ты хотел именно банальный срез монотонного массива, то там прямо рядом лежит функция https://tinkoff.github.io/investAPI/marketdata/#getcandlesrequest с классическими параметрами среза from и to, возвращающая классический кусок массива. S> S>Нет, я не хотел ни весь массив, ни монотонный срез. S>Я хотел получить список элементов, изменённых с определённого момента времени. А вы путаете Range с Delta encoding. S>Рекомендую прочитать RFC 3229, секцию 4.1, до наступления просветления.
Ты похоже меня каким-то теоретиком считаешь))) В то время как у меня там уже давно функционирует очень прибыльная система. Которая кстати недавно переписывалась (т.е. считай уже второе поколение) с Python на Rust и с REST на gRPC (это ортогонально друг другу, просто так совпало по времени), правда с сохранением всех нейросетевых алгоритмов.
S>Что я ожидаю от delta-encoding применительно к https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest? S>Пустого массива, если с момента моего последнего запроса не изменилось ничего. Массива из одного элемента, если с момента моего прошлого запроса прыгнул курс доллара (а остальные инструменты остались неизменными), и так далее. Как видим, в теории RPC позволяет такое сделать — но это потребует сразу заложить всё в сигнатуре методов. Я не могу написать сервер, который реализует только часть задокументированного протокола.
И будет этот метод всю свою жизнь использоваться только с передачей даты предыдущего запроса (от которого вычисляется дельта) в виде null. Потому что эта функция используется только для разового получения актуального среза данных. Для истории есть свои методы. А для оперативных данных свои (поток данных инициируемый сервером и там можешь считать что реально изменения присылаются).
Или быть может ты хочешь тут высказать идею о том, что непрерывный опрос в цикле — это лучше, чем ожидание сообщения об изменение с сервера? )))
_>>И теперь вот вопросик, а как тоже самое канонично описать в REST архитектуре? Просто идеологически тут явно должно быть GET, но при этом передавать массив строк в url как-то крайне печально... ))) S>Да ничего печального тут нет. Можно и список запихать в URL — в данном конкретном случае сколько там у нас реально инструментов торгуется на бирже? Тысяча? Полторы? Нет никаких проблем запихать хоть "все инструменты, кроме одного" напрямую в URL. В том числе и в компактном виде — сначала упаковав список в какой-нибудь околобинарный енкодинг, а потом в base64. S>Потери производительности на "принудительную текстовость" будут пренебрежимо малы по сравнению с сетевыми задержками. S>Можно реализовать это вторичными способами — например, сделав метод subscribe, который превращает список интересных нам инструментов в один идентификатор подписки, вслед за которым будут выполняться GET /subscriptions/####.
Вот, ты кажется уже начинаешь понимать как оно должно быть (в тинькоф api как раз подписка реализована, но подписка на поток от сервера!). Теперь ещё возможно дойдёшь до того, что непрерывный опрос в цикле — это очевидное зло и нагрузка впустую, и тогда сумеешь описать нормальную систему (выкинув REST), как раз как у тинькова.
_>>Ааа, ну т.е. "в рамках CRUD можно представить всё, что угодно", если это сложные задачи, а вот простые задачи с помощью CRUD плохо представляются... Понятно, понятно... S>Да прекрасно они представляются при помощи CRUD. Трудности возникают тогда, когда у нас требования response time начинают доминировать над требованиями consistency. S>Сложная задача — это когда у нас есть развесистая структура предметной области и развесистая логика на серверной стороне. S>А мы говорим про задачу, ER-схема которой уместится на одном листочке школьной тетрадки.
Я чувствую такими темпами мы дойдём до того, что REST полезен только в узкой области скучных энтерпрайзных игр в базы данных (и то не факт, с учётом распространения всех этих брокеров сообщений, спарков и т.п.), а в остальных областях бесполезен.
_>>А особенно забавно это всё звучит с учётом того факта, что REST по сути является строгим подмножеством RPC. S>Нет, не является. В REST введены концепции, которых в RPC просто нет, как класса. Нет понятия safety, нет понятия idempotence.
Вот ты смешной
Показываю на пальцах. Берём gRPC. Создаём там функции в полном соответствие с HTTP командами (GET, POST и т.д.). Явно передаём в качестве аргументов (опциональных конечно же) нужные HTTP заголовки. И договариваемся использовать эти функции по правилам REST. Что мы получим в итоге? Правильно, полноценный REST, реализованный поверх gRPC.
А теперь попробуй реализовать обратное. Т.е. создать произвольный gRPC API с помощью REST.
Теперь понятно кто тут является чьим подмножеством? )
_>>Что-то ты сам себе противоречишь. В предыдущем сообщение же сам признал, что для данной задачи REST не особо подходит. S>REST не особо подходит для задачи, где нужно передавать простые данные с минимальной задержкой, при этом потерями при передаче можно пренебречь.
Не подходит для этой задачи, и ещё для многих других. )))
S>При этом нужно быть очень аккуратным при проверке этих ограничений. К примеру, рассуждения о минимизации задержки бессмысленны, когда у нас клиент расположен в 200мс от сервера. Там накладные расходы на передачу парсинг HTTP-заголовков запроса в REST-подходе составляют единицы миллисекунд. А вот если мы ставим сервер в соседнюю стойку, то разница между 0мс для gRPC stream и 1ms REST request становится существенной. S>Осторожность здесь важна для того, чтобы не принимать решение для 200мс ping times на основании рассуждений, которые справедливы для 0мс ping time.
У тебя какое-то представление о современных сетях из прошлого века. У меня даже из дома пинг до тинькова 2 мс (и то это округление скорее всего).
_>>Вообще, когда человек отвечает подобным образом на подобную задачу, то это может означать только одно из двух: _>>1. Он абсолютно не компетентен как инженер (не понимает слов ТЗ и т.п.) _>>2. Он вполне компетентен и всё понимает, но честный ответ на задачу демонстрирует его неправоту, поэтому он начинает вилять и менять ТЗ. S> S>Считать ТЗ божьим словом, высеченным на скрижалях, могут себе позволить только джуны. Даже миддл начинает задаваться вопросом "а зачем мы это делаем?" и подвергать навязанные решения сомнению.
"зачем" решает бизнес! )
_>>Забавно, у нас в приложение по сути являющемся RPC клиентом (причём не gRPC, а вообще самодельном на базе WebSocket) в браузере, кнопка back отлично работает. Может всё дело в кривизне рук? ))) S>Может быть. В принципе, можно и из SOAP изобразить более-менее приличное решение. Правда, там придётся переизобрести с нуля REST, и получить велосипедную его реализацию, не совместимую ни с чем.
Какое ещё "переизобрести REST"? Просто в браузере есть API для полноценного управления историей (т.е. поведением кнопки back) и всё. И кстати к взаимодействию с сервером это вообще ортогонально на самом деле.
S>Но лучше сразу проектировать приложение с учётом особенностей физической реальности — в частности, ненадёжности коммуникаций и ограниченности полосы пропускания.
У gRPC со всем этим получше будет. )))
_>>Да я уже понял, что ты выставишь требование изменения железа по причине того, что оно плохо сочетается с любимой тобой программной архитектурой. Интересно, как тебя на работу принимали с такими подходами? ) Или ты там при приёме скрывал подобные замашки? ))) S>Меня обычно принимают на работу как раз для того, чтобы я предложил архитектурные решения, дающие нужный результат. S>А не для того, чтобы "выставить в интернет протокол удалённого управления вертелкой камеры".
Задача звучит так: есть готовая железка и ты должен запрограммировать для неё удалённый доступ. Ты уже продемонстрировал, что не смог справиться с этой задачей.
S>Потому, что далеко не всем очевидно, что надо задумываться не только о единственном позитивном сценарии, типа "один пользователь за бесконечно надёжным каналом с бесконечно большой полосой пропускания отправляет редкие команды", но и над всеми остальными сценариями, которые неизбежно возникнут в практической эксплуатации. Например — что делать, когда один пользователь жмёт "вправо", а другой — "влево".
Такие системы (управления) всегда монопользовательские!
S>Мои знания о том, как проектировать вот такие решения, неожиданно неплохо оплачиваются. Чего и вам желаю
Ты отлично продемонстрировал, что не имеешь ни малейшего представления о об обсуждаемых выше системах.
Здравствуйте, Cyberax, Вы писали:
C>gRPC — это всё-таки не CORBA.
Это совсем не CORBA, это тот же REST в котором докрутили бинарный протокол вместо JSON и больше автоматического контроля за схемой.
C>Потому API на gRPC проектируется по тем же принципам, что и для REST.
Вот именно. Поэтому заявление "Нюанс в том, что в данный момент основным подходом снова становится RPC. Правда теперь это уже RPC поверх HTTP/2 (gRPC)" выглядит странно.
Здравствуйте, alex_public, Вы писали:
_>Вообще, когда человек отвечает подобным образом на подобную задачу, то это может означать только одно из двух: _>1. Он абсолютно не компетентен как инженер (не понимает слов ТЗ и т.п.) _>2. Он вполне компетентен и всё понимает, но честный ответ на задачу демонстрирует его неправоту, поэтому он начинает вилять и менять ТЗ.
Как минимум есть третий вариант — некомпетентен тот, кто писал ТЗ.
Я вообще не очень понимаю как при современном положении дел может сложиться подобная ситуация. Если речь о продакте и тех требованиях, что он дает, то он не должен писать ничего про реализацию и протокол, он должен описать user story. Если же речь о том кто диздок пишет (аналитик, техлид, тимлид etc), то как раз он и обязан задавать подобные вопросы продакту, и некомпетентен он если такие вопросы не задает, всецело полагаясь на компетенцию продакта.
Здравствуйте, alex_public, Вы писали:
_>Вот зачем писать такой длинный текст, чтобы продемонстрировать подобную глупость? То, что ты описал — это даже не близко двухсторонний канал. Двухсторонний, это когда в рамках одного соединения и клиент и сервер могут в любой момент (в том числе даже и совпадающие) инициировать отсылку сообщения на противоположную сторону.
Формально это другой протокол, но по факту очень близок к HTTP и совместим с ним.
_>Показываю на пальцах. Берём gRPC. Создаём там функции в полном соответствие с HTTP командами (GET, POST и т.д.). Явно передаём в качестве аргументов (опциональных конечно же) нужные HTTP заголовки. И договариваемся использовать эти функции по правилам REST. Что мы получим в итоге? Правильно, полноценный REST, реализованный поверх gRPC.
Да. И именно так взрослые дядьки и делают. Но тут есть одна проблема. gRPC намного жестче контролирует схему. С одной стороны, это плюс, так как страхует нас от части ошибок. Но с другой стороны — минус — так как вопрос обратной совместимости, очень больной даже в REST, в gRPC становится просто адом. Поэтому, кстати, ведущие собаководы советуют использовать gRPC только для внутрикластерных коммуникаций.
Но даже и в этом случае есть засады. Например, gRPC херит все бенефиты от микросервисной архитектуры, так как бенефиты эти завязаны на крайне слабую связность сервисов между собой через REST протоколы. Как только уровень связности повышается за счет жесткости и специфичности протоколов — в полный рост встают ровно те проблемы, от которых микросервисы должны позволить уйти.
_>Теперь понятно кто тут является чьим подмножеством? )
Почему для тебя это так важно?
_>Задача звучит так: есть готовая железка и ты должен запрограммировать для неё удалённый доступ. Ты уже продемонстрировал, что не смог справиться с этой задачей.
Больше выглядит что не справился ты. Посылать удаленному устройству вот прям команды, которые шлют ему по UDB или чем он там подрублен — это смелое решение. Что будет, к примеру, происходить при сбое прохождения пакетов ты явно не задумывался.
Здравствуйте, Cyberax, Вы писали:
NB>>не в зависимости от пути а в зависимости от метода запроса, семантика которых (методов) четко прописана. C>Да, в REST это более чётко прописано.
И это самое главное отлдичие REST от кастомных протоколов поверх gRPC.
C>Но тем не менее, в REST нет способа указать гарантии целостности, например.
Что ты подразумеваешь под "способом указать гарантии целостности"?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Как минимум есть третий вариант — некомпетентен тот, кто писал ТЗ. НС>Я вообще не очень понимаю как при современном положении дел может сложиться подобная ситуация. Если речь о продакте и тех требованиях, что он дает, то он не должен писать ничего про реализацию и протокол, он должен описать user story. Если же речь о том кто диздок пишет (аналитик, техлид, тимлид etc), то как раз он и обязан задавать подобные вопросы продакту, и некомпетентен он если такие вопросы не задает, всецело полагаясь на компетенцию продакта.
Поскольку ты очевидно не имеешь ни малейшего представление о разработке для жезелок, то попробую пояснить тебе ситуацию на примере из твоей области. Вот представь себе, что тебя вызывает руководство и говорит, что пришёл заказчик у которого есть свой спарк-кластер и который хочет чтобы вы создали ему ПО, работающее на этом кластере и решающее такие-то задачи. И вот через некоторое время все собираются и ты представляешь свой проект: "значит первым делом выкидываем ваш спарк-кластер и заменяем его на мейнфреймы; это позволит реализовать дополнительную функциональность, которая, как я считаю, вам нужна".
Эх, представил себе такую сценку и лица всех присутствующих...
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Вот зачем писать такой длинный текст, чтобы продемонстрировать подобную глупость? То, что ты описал — это даже не близко двухсторонний канал. Двухсторонний, это когда в рамках одного соединения и клиент и сервер могут в любой момент (в том числе даже и совпадающие) инициировать отсылку сообщения на противоположную сторону. НС>https://en.wikipedia.org/wiki/WebSocket
Да, WebSocket — это пример полноценного двухстороннего протокола. И кстати все наши браузерные приложения пользуются исключительно им. Причём как раз в стиле gRPC, разве что формат сообщений задан не на языке Proto, а на языке Rust.
НС>Формально это другой протокол, но по факту очень близок к HTTP и совместим с ним.
Абсолютно не близок и не совместим (не считая возможности использования инфраструктуры http для себя). Ну и главное непонятно каким боком ты хочешь подсунуть WebSocket к REST?
_>>Показываю на пальцах. Берём gRPC. Создаём там функции в полном соответствие с HTTP командами (GET, POST и т.д.). Явно передаём в качестве аргументов (опциональных конечно же) нужные HTTP заголовки. И договариваемся использовать эти функции по правилам REST. Что мы получим в итоге? Правильно, полноценный REST, реализованный поверх gRPC. НС>Да. И именно так взрослые дядьки и делают. Но тут есть одна проблема. gRPC намного жестче контролирует схему. С одной стороны, это плюс, так как страхует нас от части ошибок. Но с другой стороны — минус — так как вопрос обратной совместимости, очень больной даже в REST, в gRPC становится просто адом. Поэтому, кстати, ведущие собаководы советуют использовать gRPC только для внутрикластерных коммуникаций.
О ужас! Интересно и какой же тогда магией такие ОС как Windows (в которых с формализацией API всё не менее жёстко) могут спокойно развиваться, сохраняя при этом обратную совместимости десятилетиями? ) Видимо где-то в индустрии есть некие скрытые сакральные знания, которые утеряны разработчиками всяких говносервисов... )))
НС>Но даже и в этом случае есть засады. Например, gRPC херит все бенефиты от микросервисной архитектуры, так как бенефиты эти завязаны на крайне слабую связность сервисов между собой через REST протоколы. Как только уровень связности повышается за счет жесткости и специфичности протоколов — в полный рост встают ровно те проблемы, от которых микросервисы должны позволить уйти.
Как раз наоборот, это решает проблемы связи микросервисов, поскольку переводит их на полностью автоматизированный уровень. После того, как авторы сервиса представляют его внешний API, все клиенты автоматически получают готовый и абсолютно корректный (т.к. сгенерированный, а не написанный руками человека) код.
_>>Теперь понятно кто тут является чьим подмножеством? ) НС>Почему для тебя это так важно?
Исключительно потому, что собеседник заявил обратное. А любой очевидный технический бред должен быть немедленно опровергнут.
_>>Задача звучит так: есть готовая железка и ты должен запрограммировать для неё удалённый доступ. Ты уже продемонстрировал, что не смог справиться с этой задачей. НС>Больше выглядит что не справился ты. Посылать удаленному устройству вот прям команды, которые шлют ему по UDB или чем он там подрублен — это смелое решение. Что будет, к примеру, происходить при сбое прохождения пакетов ты явно не задумывался.
Очевидно ничего не будет. На сервере просто ничего (сообщение то не дойдёт). А у клиента будет код ошибки, о котором при желание можно сообщить пользователю.
Здравствуйте, alex_public, Вы писали:
_>Вот зачем писать такой длинный текст, чтобы продемонстрировать подобную глупость? То, что ты описал — это даже не близко двухсторонний канал. Двухсторонний, это когда в рамках одного соединения и клиент и сервер могут в любой момент (в том числе даже и совпадающие) инициировать отсылку сообщения на противоположную сторону.
Ну, и в чём подвох?
_>Ты думаешь что использование английский слов как-то улучшает твою аргументацию? На самом деле это только показывает твоё слабое владение профессиональной терминологией.
Я думаю, что писать принятые англоязычные термины компактнее, чем разворачивать в "согласование используемых возможностей между клиентом и сервером" и "поэтапное усечение функциональности при неполной поддержке набора возможностей протокола".
_>Осталось теперь только понять зачем может понадобится подобное в биржевом API. )))
Точно так же, как и в любом другом — если мне нужен список текущих цен, то мне выгоден любой способ сокращения трафика — в частности, если меняются не все цены, то получение дельты экономит трафик.
_>Ты похоже меня каким-то теоретиком считаешь))) В то время как у меня там уже давно функционирует очень прибыльная система.
Я вас никем не считаю. Я просто читаю то, что вы пишете. Мне совершенно неважно, по какой причине вы не отличаете список текущих цен на инструменты от истории свечей — потому, что вы теоретик, или просто из-за невнимательности.
_>И будет этот метод всю свою жизнь использоваться только с передачей даты предыдущего запроса (от которого вычисляется дельта) в виде null. Потому что эта функция используется только для разового получения актуального среза данных. Для истории есть свои методы. А для оперативных данных свои (поток данных инициируемый сервером и там можешь считать что реально изменения присылаются).
Ну, ок, вместо дельты вы предлагаете получать поток обновлений. Это — неплохой вариант. _>Или быть может ты хочешь тут высказать идею о том, что непрерывный опрос в цикле — это лучше, чем ожидание сообщения об изменение с сервера? )))
Расскажите же мне, как ожидание сообщения будет работать после обрыва канала и восстановления подключения?
_>Вот, ты кажется уже начинаешь понимать как оно должно быть (в тинькоф api как раз подписка реализована, но подписка на поток от сервера!). Теперь ещё возможно дойдёшь до того, что непрерывный опрос в цикле — это очевидное зло и нагрузка впустую, и тогда сумеешь описать нормальную систему (выкинув REST), как раз как у тинькова.
Всё зависит от типа задачи. REST дружелюбен к любой топологии — в частности, я могу реализовать ресурс "история изменений", который будет бесконечным. Как число Pi.
Как мы уже обсудили выше, COMET никуда не делся. Более того — в отличие от gRPC, после обрыва я могу запросить историю изменений с того места, до которого я дочитал в прошлый раз.
_>Я чувствую такими темпами мы дойдём до того, что REST полезен только в узкой области скучных энтерпрайзных игр в базы данных (и то не факт, с учётом распространения всех этих брокеров сообщений, спарков и т.п.), а в остальных областях бесполезен.
_>А теперь попробуй реализовать обратное. Т.е. создать произвольный gRPC API с помощью REST.
А в чём проблема? Просто берём и заворачиваем всё, что угодно, в POST.
_>Не подходит для этой задачи, и ещё для многих других. )))
_>У тебя какое-то представление о современных сетях из прошлого века. У меня даже из дома пинг до тинькова 2 мс (и то это округление скорее всего).
Просто вам повезло с домом. У меня — 44мс. Физику не обманешь, и если у вас сервер расположен в 20000км от клиента, то нулевым пинг вы не сделаете никак.
_> "зачем" решает бизнес! )
Не бизнес, а продукт менеджмент.
_>Какое ещё "переизобрести REST"? Просто в браузере есть API для полноценного управления историей (т.е. поведением кнопки back) и всё. И кстати к взаимодействию с сервером это вообще ортогонально на самом деле.
Ну, можно и так, если сильно хочется.
_>У gRPC со всем этим получше будет. ))) Рассскажите, что делать при обрыве соединения, передающего stream?
_>Задача звучит так: есть готовая железка и ты должен запрограммировать для неё удалённый доступ. Ты уже продемонстрировал, что не смог справиться с этой задачей. Хорошо, что мне обычно ставят задачи вроде "увеличить продажи в таком-то сегменте в такое-то количество раз" или "сократить количество обращений в службу поддержки в месяц на единицу продаж".
_> Такие системы (управления) всегда монопользовательские!
Как вы собираетесь это обеспечить? _>Ты отлично продемонстрировал, что не имеешь ни малейшего представления о об обсуждаемых выше системах.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Поскольку ты очевидно не имеешь ни малейшего представление о разработке для жезелок, НС>Поскольку речь идет не о разработке железок, а о веб сервисах — с такими заявлениями сразу в лес.
Вообще то в дискуссии о ТЗ речь шла именно что о железке, причём вполне конкретной. И Sinclair требовал добавить к этой железке дополнительный аппаратный блок, чтобы соизволить взяться за написание простейшей программной части для неё. Видимо без этого данная простейшая задачка является нерешаемой для архитекторов с REST'ом головного мозга. )))
Здравствуйте, alex_public, Вы писали:
_>Вообще то в дискуссии о ТЗ речь шла именно что о железке, причём вполне конкретной. И Sinclair требовал добавить к этой железке дополнительный аппаратный блок
Ты как то крайне странно понял что он предлагал. Если удаленный протокол задан свыше, и там все так как ты описал — ну что ж, придется клиентам жрать кактус. ТОлько неясно при чем тут REST — в этой ситуации услуги аналитика и архитектора нам не нужны, все уже спроектировано.
Но топик то был не о такой ситуации, а о ситуации когда у нас есть возможность выбора между REST и RPC. Т.е. речь не о каком то аппаратном блоке, а о вполне себе программной начинке, а ты сейчас пытаешься подменить тему. Дескать, я тут придумал чисто аппаратное решение, где вы лохи, а значит я победил и прав во всем.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Вообще то в дискуссии о ТЗ речь шла именно что о железке, причём вполне конкретной. И Sinclair требовал добавить к этой железке дополнительный аппаратный блок НС>Ты как то крайне странно понял что он предлагал. Если удаленный протокол задан свыше, и там все так как ты описал — ну что ж, придется клиентам жрать кактус. ТОлько неясно при чем тут REST — в этой ситуации услуги аналитика и архитектора нам не нужны, все уже спроектировано. НС>Но топик то был не о такой ситуации, а о ситуации когда у нас есть возможность выбора между REST и RPC. Т.е. речь не о каком то аппаратном блоке, а о вполне себе программной начинке, а ты сейчас пытаешься подменить тему. Дескать, я тут придумал чисто аппаратное решение, где вы лохи, а значит я победил и прав во всем.
Что-то ты бредишь или не знаю чем читал нашу беседу. Задача была сформулирована мною предельно просто: есть некая конкретная железка с конкретными "кнопками" и надо приделать (любым программным способом, без каких-либо ограничений на протокол) к ней удалённое управление (чтобы грубо говоря нажимать эти кнопки дистанционно). Если что, могу кинуть ссылку именно на такую формулировку в дискуссии выше.
И мой оппонент откровенно слился при решений этой простейшей задачки. Причём слился он очевидно потому, что у него REST головного мозга, а данная задача не очень канонично ложится на эту архитектуру. Но естественно он не мог этого признать и начал тупо вилять, рассказывая о том что надо просто взять другую железку и вот для неё то он уж напишет как надо...
"зачем" решает бизнес! )
