Здравствуйте, alex_public, Вы писали:
_>То, что на момент отправки первого сообщения, данных для следующих сообщений пока ещё нет.
И?
_>))) Обычно на эту тему рисуют такие картинки (кстати, там кажется тестировали даже на вашем родном .net'е) с разницей раз в 10:
_>
Ну, правильной подгонкой микробенчмарков можно получить произвольный результат.
_>И что мешает сделать тоже самое с gRPC? )
То, что в него не встроены такие вещи. Вам придётся вносить всё это в сигнатуру метода, ломая обратную совместимость с клиентами, которые не знают про delta encoding.
А в REST это встроено из коробки. Поэтому можно допиливать сервер, не переживая за то, что часть клиентов не умеют такие вещи.
С учётом разнообразных хидеров аналогом одного REST-ендпоинта будут несколько десятков сигнатур RPC-методов. Чего, естественно, никто не делает.
Вот вам, к примеру, delta encoding даже в голову не пришёл — значит, если дать вам спроектировать сервис на основе gRPC, вы ничего подобного в него не заложите.
_>Ну вот https://tinkoff.github.io/investAPI/ тебе реальный пример. )
Ну я и говорю — для роботов REST может и не подойти.
_>Ну так а если это условие задачи (в биржевой торговле так и есть), то что тогда? )))
Тогда биржа просто забивает на то, что клиент может лечь. Это — его проблемы. Так ведь? Нет задачи "гарантированно известить обо всех событиях".
_>Я же писал, что экондера нет. Да и не нужен он, т.к. на устройстве камера, поток от которой параллельно тоже идёт к пользователю (и тот глазами по картинке легко определяет нужное ему положение).
Угу. С задержкой в 500мс, да?
Простите, эта схема — неработоспособна.
_>Кстати, тут подумалось, что в рамках gRPC можно и поток данных от камеры сделать не параллельным где-то рядом, а прямо в рамках того же API (как stream кадров от сервера).
А то. Можно. Но это — патологически неустойчивый вариант. Пользоваться им будет крайне неудобно. В разы неудобнее, чем через REST.
В то время, как REST архитектура (не протокол, а архитектура) позволит им пользоваться даже без человека на приёмном конце.
_>Я правильно понимаю, что данный поток слов надо воспринимать как слив по данному примеру? )))
Можно и так воспринимать. Но правильнее будет, если вы примете как слив саму формулировку архитектурного решения, т.к. оно вряд ли решит задачу конечного потребителя.
_>С учётом наличия такой https://github.com/grpc-ecosystem/grpc-gateway штуки, мне кажется что выбор о базовой реализации должен быть однозначным. ))) Хотя конечно же по настоящему модные возможности (типа двунаправленных потоков) там отсутствуют — ну это цена за желание поддержки легаси (REST).
Пока что выглядит как попытка совместить недостатки обоих подходов.
