Этот пост зацепил моё внимание заявленной темой — но по прочтению у меня сложилось впечатление, что с логикой изложения что-то не то. Задал вопрос автору в каментах и продублирую его здесь.
Юрий Куприянов ведет довольно интересный для меня канал, но иногда возникает ощущение что логика сохраняется в локальных утверждениях, но цельность всего поста будто бы чуток «троит» 😈
===
Всю статью будто бы пронизывает трудноуловимый сбой в логике повествования. Прошу прощения у автора, возможно я неверно интерпретировал некоторые утверждения в заметке.
(1) В заголовке постулируется тема по передаче данных от сервера к клиенту по инициативе сервера; к концу статьи множество понятий сваливается в кучу, включая event-driven архитектуру и логику принятия решений на уровне приложения.
Возможно я ошибаюсь, но решение о том, вокруг чего «устроены сообщения», должен принять проектировщик при проектировании системы, а не «приложение на уровне логики».
(2) Мне кажется неверно постулировать использование «оберток» GraphQL и gRPC вокруг коммуникационных протоколов по причине того, что «сложно разобраться» с этими самыми коммуникационными протоколами HTTP/* и WebSocket.
Создавались GraphQL и gRPC чтобы решить вполне конкретные проблемы:
GraphQL — язык запросов, чтобы решить проблему поставки рекурсивных данных в условиях узких каналов передачи данных;
gRPC — фреймворк, чтобы связать большое количество микросервисов написанных на разных языках в корпоративном контуре, используя преимущества протоколов SPDY, HTTP/2 и QUIC.
Выбор в пользу технологии должен делаться системно, с рассмотрением решаемых проблем и с учетом архитектуры информационных систем. Не потому, что технология сложная.
(3)
REST предлагался Филдингом как концепция «самоописываемого состояния гипермедиа» в условиях «анархического масштабирования сети». Основная идея состояла в том, что клиент может добраться до любого узла графа API, начав от корня и следуя ссылкам HATEOAS. В целом можно почитать комментарий Филдинга здесь или разбор диссертации Филдинга здесь.
Как архитектурный стиль REST API может стать более или менее технологическим? Да, REST вовсе не требует использования HTTP для имплементации. Но в чём именно может выражаться меньшая технологичность этого стиля?
Тот же вопрос применим и к RPC.
Буду признателен за содержательные ответы или критику.
===
Юрий обещал ответить содержательно. Записал в книжку душных напоминаний 😯
Юрий Куприянов ведет довольно интересный для меня канал, но иногда возникает ощущение что логика сохраняется в локальных утверждениях, но цельность всего поста будто бы чуток «троит» 😈
===
Всю статью будто бы пронизывает трудноуловимый сбой в логике повествования. Прошу прощения у автора, возможно я неверно интерпретировал некоторые утверждения в заметке.
(1) В заголовке постулируется тема по передаче данных от сервера к клиенту по инициативе сервера; к концу статьи множество понятий сваливается в кучу, включая event-driven архитектуру и логику принятия решений на уровне приложения.
Возможно я ошибаюсь, но решение о том, вокруг чего «устроены сообщения», должен принять проектировщик при проектировании системы, а не «приложение на уровне логики».
(2) Мне кажется неверно постулировать использование «оберток» GraphQL и gRPC вокруг коммуникационных протоколов по причине того, что «сложно разобраться» с этими самыми коммуникационными протоколами HTTP/* и WebSocket.
Создавались GraphQL и gRPC чтобы решить вполне конкретные проблемы:
GraphQL — язык запросов, чтобы решить проблему поставки рекурсивных данных в условиях узких каналов передачи данных;
gRPC — фреймворк, чтобы связать большое количество микросервисов написанных на разных языках в корпоративном контуре, используя преимущества протоколов SPDY, HTTP/2 и QUIC.
Выбор в пользу технологии должен делаться системно, с рассмотрением решаемых проблем и с учетом архитектуры информационных систем. Не потому, что технология сложная.
(3)
«кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими»
REST предлагался Филдингом как концепция «самоописываемого состояния гипермедиа» в условиях «анархического масштабирования сети». Основная идея состояла в том, что клиент может добраться до любого узла графа API, начав от корня и следуя ссылкам HATEOAS. В целом можно почитать комментарий Филдинга здесь или разбор диссертации Филдинга здесь.
Как архитектурный стиль REST API может стать более или менее технологическим? Да, REST вовсе не требует использования HTTP для имплементации. Но в чём именно может выражаться меньшая технологичность этого стиля?
Тот же вопрос применим и к RPC.
Буду признателен за содержательные ответы или критику.
===
Юрий обещал ответить содержательно. Записал в книжку душных напоминаний 😯