Здравствуйте, Sinclair, Вы писали:

_>>То, что на момент отправки первого сообщения, данных для следующих сообщений пока ещё нет.
S>И?

Что и? В gPRC это возможно в рамках одного соединения, а в REST нет.

_>>И что мешает сделать тоже самое с gRPC? )
S>То, что в него не встроены такие вещи. Вам придётся вносить всё это в сигнатуру метода, ломая обратную совместимость с клиентами, которые не знают про delta encoding.
S>А в REST это встроено из коробки. Поэтому можно допиливать сервер, не переживая за то, что часть клиентов не умеют такие вещи.

Так встроено или надо допиливать сервер?

S>С учётом разнообразных хидеров аналогом одного REST-ендпоинта будут несколько десятков сигнатур RPC-методов. Чего, естественно, никто не делает.

Бредим? )

S>Вот вам, к примеру, delta encoding даже в голову не пришёл — значит, если дать вам спроектировать сервис на основе gRPC, вы ничего подобного в него не заложите.

Ты вот это сейчас серьёзно? ) Ты считаешь, что при запросе коллекции данных никому не придёт в голову указывать в запросе её срез и все будут возвращать только коллекцию целиком? )))

_>>Ну вот https://tinkoff.github.io/investAPI/ тебе реальный пример. )
S>Ну я и говорю — для роботов REST может и не подойти.

Ой, т.е. оказывается уже целая большая область обнаружилась, где REST сливает RPC? А кто же у нас вот только что писал:

Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл. В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.

И вот уже "неожиданно" оказывается что не "во всех случаях"? )))

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

_>>Ну так а если это условие задачи (в биржевой торговле так и есть), то что тогда? )))
S>Тогда биржа просто забивает на то, что клиент может лечь. Это — его проблемы. Так ведь? Нет задачи "гарантированно известить обо всех событиях".

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

_>>Я же писал, что экондера нет. Да и не нужен он, т.к. на устройстве камера, поток от которой параллельно тоже идёт к пользователю (и тот глазами по картинке легко определяет нужное ему положение).
S>Угу. С задержкой в 500мс, да?

И? В чём проблема то?

S>Простите, эта схема — неработоспособна.

Да я смотрю ты и в этой области специалист.

_>>Кстати, тут подумалось, что в рамках gRPC можно и поток данных от камеры сделать не параллельным где-то рядом, а прямо в рамках того же API (как stream кадров от сервера).
S>А то. Можно. Но это — патологически неустойчивый вариант. Пользоваться им будет крайне неудобно. В разы неудобнее, чем через REST.

Оу, видеопоток через REST... Это прямо максимально интересно становится.

S>В то время, как REST архитектура (не протокол, а архитектура) позволит им пользоваться даже без человека на приёмном конце.

Эээ что? ) Весь смысл всего это в том, чтобы человек пейзажики смотрел...

_>>Я правильно понимаю, что данный поток слов надо воспринимать как слив по данному примеру? )))
S>Можно и так воспринимать. Но правильнее будет, если вы примете как слив саму формулировку архитектурного решения, т.к. оно вряд ли решит задачу конечного потребителя.

Какого ещё архитектурного решения? У тебя есть физическая железка с заданными параметрами (условно двумя кнопками влево/вправо и кнопкой включения камеры, возвращающей поток кадров) и надо приделать к ней удалённый доступ. Архитектуру можешь плодить какую хочешь. Но ты уже показал, что в рамках REST подхода ты можешь только слиться с невнятными оправданиями.

_>>С учётом наличия такой https://github.com/grpc-ecosystem/grpc-gateway штуки, мне кажется что выбор о базовой реализации должен быть однозначным. ))) Хотя конечно же по настоящему модные возможности (типа двунаправленных потоков) там отсутствуют — ну это цена за желание поддержки легаси (REST).
S> Пока что выглядит как попытка совместить недостатки обоих подходов.

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

Здравствуйте, Sinclair, Вы писали:

_>>То, что на момент отправки первого сообщения, данных для следующих сообщений пока ещё нет.
S>И?

Что и? В gPRC это возможно в рамках одного соединения, а в REST нет.

_>>И что мешает сделать тоже самое с gRPC? )
S>То, что в него не встроены такие вещи. Вам придётся вносить всё это в сигнатуру метода, ломая обратную совместимость с клиентами, которые не знают про delta encoding.
S>А в REST это встроено из коробки. Поэтому можно допиливать сервер, не переживая за то, что часть клиентов не умеют такие вещи.

Так встроено или надо допиливать сервер?

S>С учётом разнообразных хидеров аналогом одного REST-ендпоинта будут несколько десятков сигнатур RPC-методов. Чего, естественно, никто не делает.

Бредим? )

S>Вот вам, к примеру, delta encoding даже в голову не пришёл — значит, если дать вам спроектировать сервис на основе gRPC, вы ничего подобного в него не заложите.

Ты вот это сейчас серьёзно? ) Ты считаешь, что при запросе коллекции данных никому не придёт в голову указывать в запросе её срез и все будут возвращать только коллекцию целиком? )))

_>>Ну вот https://tinkoff.github.io/investAPI/ тебе реальный пример. )
S>Ну я и говорю — для роботов REST может и не подойти.

Ой, т.е. оказывается уже целая большая область обнаружилась, где REST сливает RPC? А кто же у нас вот только что писал:

Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл. В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.

И вот уже "неожиданно" оказывается что не "во всех случаях"? )))

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

Да, кстати, у ребят в указанном примере ещё год назад был REST интерфейс (OpenAPI и всё такое)... )))

_>>Ну так а если это условие задачи (в биржевой торговле так и есть), то что тогда? )))
S>Тогда биржа просто забивает на то, что клиент может лечь. Это — его проблемы. Так ведь? Нет задачи "гарантированно известить обо всех событиях".

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

_>>Я же писал, что экондера нет. Да и не нужен он, т.к. на устройстве камера, поток от которой параллельно тоже идёт к пользователю (и тот глазами по картинке легко определяет нужное ему положение).
S>Угу. С задержкой в 500мс, да?

И? В чём проблема то?

S>Простите, эта схема — неработоспособна.

Да я смотрю ты и в этой области специалист.

_>>Кстати, тут подумалось, что в рамках gRPC можно и поток данных от камеры сделать не параллельным где-то рядом, а прямо в рамках того же API (как stream кадров от сервера).
S>А то. Можно. Но это — патологически неустойчивый вариант. Пользоваться им будет крайне неудобно. В разы неудобнее, чем через REST.

Оу, видеопоток через REST... Это прямо максимально интересно становится.

S>В то время, как REST архитектура (не протокол, а архитектура) позволит им пользоваться даже без человека на приёмном конце.

Эээ что? ) Весь смысл всего это в том, чтобы человек пейзажики смотрел...

_>>Я правильно понимаю, что данный поток слов надо воспринимать как слив по данному примеру? )))
S>Можно и так воспринимать. Но правильнее будет, если вы примете как слив саму формулировку архитектурного решения, т.к. оно вряд ли решит задачу конечного потребителя.

Какого ещё архитектурного решения? У тебя есть физическая железка с заданными параметрами (условно двумя кнопками влево/вправо и кнопкой включения камеры, возвращающей поток кадров) и надо приделать к ней удалённый доступ. Архитектуру можешь плодить какую хочешь. Но ты уже показал, что в рамках REST подхода ты можешь только слиться с невнятными оправданиями.

_>>С учётом наличия такой https://github.com/grpc-ecosystem/grpc-gateway штуки, мне кажется что выбор о базовой реализации должен быть однозначным. ))) Хотя конечно же по настоящему модные возможности (типа двунаправленных потоков) там отсутствуют — ну это цена за желание поддержки легаси (REST).
S> Пока что выглядит как попытка совместить недостатки обоих подходов.

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