Этот "фреймворк на три дтошки" мало того что тянет за собой парсер JSON в виде зависимости, так еще и накладывает определенные обязательства по разработке, одно из которых я описал выше.
Если у вас современная система, веб и популярный язык вроде Java/C# в JSON RPC нет никакого смысла — возьмите обычный REST, для которого JSON объекты лишь один из доступных типов данных.
Самый обычный REST позволит например часть данных брать из HTTP-заголовков, использовать все методы HTTP а один только POST, загрузку/скачивание бинарных файлов без цирка с сериализацией.
Зачем связывать себя по рукам и ногам жесткой схемой RPC просто так?
Иначе будет как у товарища выше по переписке, где он гоняет гигабайты данных через RPC протокол и жалуется на производительность.
Мне лично XML-RPC нужен в виде универсального инструмента для сложных и неадекватных условий, разумеется я не применяю его для всего вообще и например корпоративную разработку веду на самом обычном Java + Spring.
Если уж в описании самого протокола (цитату из которого я приводил выше) написано, что для запроса и ответа нужно формирование ID - тут никаких споров быть не может.
Вот для примера реализация JSON‑RPC на Java, в этом месте происходит чтение ID запроса, вот тут и ниже по коду он используется для формирования ответа.
Разумеется за все это отвечает фреймворк с реализацией JSON-RPC а не клиентский код, так что "Вручную не надо ничего парсить и хранить айди" действительно не надо - это сделают за вас и в обязательном порядке.
Нет одно время я очень плотно работал с DirectX -ом и с другими дИректами. Я точно знаю что версии интерфейсов имеют смысл
Объясняю: две разных версии DirectX это две разных не связанных между собой сущности - две физически разных и независимых друг от друга библиотеки. Т.е одну версию можно удалить и другая от этого не сломается.
Две версии API вебсервиса это на самом деле одна сущность — одна программа (если так будет понятней), внутри которой на одном из уровней обязательно происходит смешение.
Даже если за разные версии API отвечают физически разные сервисы — данные у них все равно будут общие: общая база, общие сервисы, общее файловое хранилище и тд.
Полное разделение версий одного сервиса вплоть до данных я на практике не видел ни разу.
Так что две версии API это на самом деле две головы одной и той же гидры, только вместо отрастания по-новой (как в сказке), отрубание одной приведет к падению всего сервиса.
Первое - и есть десериализация. Второе - сериализация. А то что примеры в публикации не содержат в запросах и ответах ни массивов, ни массивов структур - это уже точно не ко мне.
Не хочу уподобляться местным обитателям и придираться к точности терминов, но полагаю что под сериализацией/десериализацией XML подразумевалось использование как минимум DOM и какого-то механизма связывания с объектами языка - DTO, POJO и так далее.
Так вот всего этого тут нет, один только потоковый парсер.
"Массивы и массивы структур" были в тестах, но поскольку никаких проблем замечено не было — убрал.
Для C/C++ версий код был сильно объемнее, по очевидным причинам.
Тем более при использовании двунаправленного потокового gRPC и пакетной конвеерной обработки.
Двунаправленный потоковый вызов процедур? Вы фактически превратили атомарную по своей сути систему вызовов во что-то вроде видеострима. Полагаю следующим этапом придется добавлять какой-то контроль целостности данных, повторную отправку, докачку при обрыве и все прочие подобные радости.
А у нас запросы в Protobuf на несколько мегабайт с ответами на гигабайт - вполне себе обычны.
Не очень понимаю зачем все это было делать в рамках RPC протокола.
Если возникает большой объем передаваемых данных - существует вполне стандартный механизм для их передачи: через отдельную ссылку на скачивание.
В передаваемом ответе фигурирует лишь ссылка на скачивание, само скачивание клиент осуществляет отдельным запросом вне логики RPC.
Это вообщем-то стандартная практика даже для SOAP и REST.
В REST это было на порядок больше, так как в основном там массивы чисел.
Опять же не зная задачи могу ошибиться, но есть банальный работающий способ для такого: формируется текстовый файл с такими массивами чисел, который затем сжимается в архив и передается в виде бинарного файла.
Цифры сжимаются очень хорошо, на больших объемах будет существенный выигрыш.
С другой стороны происходит распаковка и чтение.
Если данных много то лучше формировать CSV с построчной разбивкой а не пытаться "сериализовать" все сразу и целиком.
В смысле что такое состояние нестыковки клиентского и сервисного интерфейсов в рамках одной системы (те когда вы контролируете и клиентскую и серверную сторону) должно трактоваться как серьезный системный сбой.
На практике это чаще всего будет означать что кто-то из участников процесса выложил не ту сборку или релиз оказался битым, а значит несовпадение сигнатуры вызова лишь последствия а не причина.
А если версии интерфейсов ввести например?
Если кратко любые версии интерфейсов не более чем иллюзия, не дающая никакой защиты от внутренних изменений.
Вот вам несколько выдержек из официальной спецификации на JSON, вдруг решите свой парсер написать.
Про юникод:
JSON syntax describes a sequence of Unicode code points. JSON also depends on Unicode in the hex numbers used in the \u escapement notation
Про цифры:
JSON is agnostic about the semantics of numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult. JSON instead offers only the representation of numbers that humans use: a sequence of digits.
Про совместимость:
It is expected that other standards will refer to this one, strictly adhering to the JSON syntax, while imposing semantics interpretation and restrictions on various encoding details. Such standards may require specific behaviours. JSON itself specifies no behaviour.
Так что JSON сложнее и объемнее чем кажется, причем любая его реализация фактически подразумевает undefined behavior, поскольку стандарт описывает и гарантирует лишь синтаксис.
Что касается упомянутого протокола JSON-RPC, то помимо описанных выше проблем есть еще вот такое:
All transfer types are single objects, serialized using JSON.[1] A request is a call to a specific method provided by a remote system. It can contain three members:
..
id - A string or non-fractional number used to match the response with the request that it is replying to.[2] This member may be omitted if no response should be returned.[3]
И ниже про обработку ответа:
The receiver of the request must reply with a valid response to all received requests. A response can contain the members mentioned below.
..
id - The id of the request it is responding to.
Получается что никакая реализация JSON-RPC не может быть stateless, поскольку эти самые id нужно где-то хранить.
Эта на первый взгляд мелочь обязательно всплывет при попытке масштабирования такого сервиса.
И это на фоне кучи умных слов и абревиатур. Если всё так просто то в чем же была сложность???
В чем сложность вызова удаленных процедур?
Сейчас расскажу.
Допустим у вас клиент и сервер, с которого вызываются процедуры написаны на разных технологиях, что чаще всего и бывает.
Один умеет работать с Unicode, другой нет.
В этом месте JSON по-хорошему заканчивается, поскольку по стандарту любая клиентская реализация JSON должна поддерживать юникод.
А еще есть различия в типах данных, когда у вас один технологический стек считает что строка это набор символов, а другой что строка это массив байт. Где-то есть отдельный булевый тип, где-то его нет и нужно передавать 1\0. Есть отличия в трактовке дат, меток времени и длинных чисел.
Именно из‑за такого количества сложностей большинство RPC фреймворков объемные и сложные — они скрывают все эти детали под капотом и вы просто не задумываетесь о них при работе.
До судного дня Х, когда они вылезают на поверхность.
Фишка XML-RPC как протокола как раз и заключается в том что он не пытается скрывать всю эту сложность, четко обозначая минимально поддерживаемый набор типов.
Поэтому он до сих пор жив и используется, хотя огромная корпорация пытается его задушить с 1998го года.
Уважаемый ptr128, в интернете давно существует большая проблема с валидацией публикуемых данных, тем более когда речь заходит о сложных технических вещах.
То что вы «нагуглили» это разумеется замечательно, но это не истина в первой инстанции.
Если вы заметили, половина данной статьи состоит из конкретных примеров реально работающего кода на разных языках — все это я на самом деле собрал и запустил.
По этой причине могу подтвердить что оно действительно работает на момент написания статьи.
Если вы в силах повторить подобное для gRPC — пишите статью, коллеги оценят.
P.S.
Я не выступаю против gRPC, да и против вас лично ничего не имею, просто не хочу скатывания разумной технической дискуссии в очередной бессмысленный срач.
Lisp, TCL, окружения Linux старше 15 лет, практически все коммерческие Unix, промавтоматика, встраиваемые системы, где как раз имеет смысл миниатюризация всех используемых библиотек. Устаревшие Windows.
Разумеется там будет компилятор, но только устаревший, у которого проблемы компиляции даже не находятся поисковиками.
Очень мало таких осталось )
Прикольная штука, а как насчет шейдеров и WebGl ?
Видимо вы еще просто не осознали насколько широко успел распространиться React :)
На сегодняшний день наверное каждый второй создаваемый лендинг будет на реакте, все крупные сайты из этого списка:
https://www.nationalgeographic.org/
https://www.codecademy.com/
https://bbc.com/
https://www.nytimes.com/
https://www.pwc.com/
уже на реакте, включая отдельные спецпроекты, которых там очень и очень много.
Каждый спецпроект — чаще всего тот самый лендинг, ныне это все отдельные приложения на реакте.
А вот например аггрегатор AI‑стартапов, каждый второй сайт компании — на реакте.
Так что реакта за последние годы стало прям очень много.
С ядром все довольно интересно: собирается оно только из-под MacOS, только фирменным закрытым компилятором и устанавливается тоже только в MacOS.
Со времен закрытия проекта Darwin не было даже попыток вставить это ядро в другое окружение, например от BSD.
В курсе, но UI там все также нет.
Справедливости ради C++ уже тоже далеко не тот что был в 90е, помимо появления библиотек вроде Boost развивается и сам стандарт.
Вот для примера код на современном C++ 17 одного сетевого фреймворка, который я портировал с Linux на FreeBSD в прошлом году.
Его объем вполне сопоставим с версией на С#.
Этот "фреймворк на три дтошки" мало того что тянет за собой парсер JSON в виде зависимости, так еще и накладывает определенные обязательства по разработке, одно из которых я описал выше.
Если у вас современная система, веб и популярный язык вроде Java/C# в JSON RPC нет никакого смысла — возьмите обычный REST, для которого JSON объекты лишь один из доступных типов данных.
Самый обычный REST позволит например часть данных брать из HTTP-заголовков, использовать все методы HTTP а один только POST, загрузку/скачивание бинарных файлов без цирка с сериализацией.
Зачем связывать себя по рукам и ногам жесткой схемой RPC просто так?
Иначе будет как у товарища выше по переписке, где он гоняет гигабайты данных через RPC протокол и жалуется на производительность.
Мне лично XML-RPC нужен в виде универсального инструмента для сложных и неадекватных условий, разумеется я не применяю его для всего вообще и например корпоративную разработку веду на самом обычном Java + Spring.
а вы статью точно прочитали?
Ссылка на википедию после всего описанного? Серьезно?
Вам правда что-ли какие-то там лайки важнее общения по делу?
Если уж в описании самого протокола (цитату из которого я приводил выше) написано, что для запроса и ответа нужно формирование ID - тут никаких споров быть не может.
Вот для примера реализация JSON‑RPC на Java, в этом месте происходит чтение ID запроса, вот тут и ниже по коду он используется для формирования ответа.
Разумеется за все это отвечает фреймворк с реализацией JSON-RPC а не клиентский код, так что "Вручную не надо ничего парсить и хранить айди" действительно не надо - это сделают за вас и в обязательном порядке.
Объясняю: две разных версии DirectX это две разных не связанных между собой сущности - две физически разных и независимых друг от друга библиотеки. Т.е одну версию можно удалить и другая от этого не сломается.
Две версии API вебсервиса это на самом деле одна сущность — одна программа (если так будет понятней), внутри которой на одном из уровней обязательно происходит смешение.
Даже если за разные версии API отвечают физически разные сервисы — данные у них все равно будут общие: общая база, общие сервисы, общее файловое хранилище и тд.
Полное разделение версий одного сервиса вплоть до данных я на практике не видел ни разу.
Так что две версии API это на самом деле две головы одной и той же гидры, только вместо отрастания по-новой (как в сказке), отрубание одной приведет к падению всего сервиса.
Не хочу уподобляться местным обитателям и придираться к точности терминов, но полагаю что под сериализацией/десериализацией XML подразумевалось использование как минимум DOM и какого-то механизма связывания с объектами языка - DTO, POJO и так далее.
Так вот всего этого тут нет, один только потоковый парсер.
"Массивы и массивы структур" были в тестах, но поскольку никаких проблем замечено не было — убрал.
Для C/C++ версий код был сильно объемнее, по очевидным причинам.
Двунаправленный потоковый вызов процедур? Вы фактически превратили атомарную по своей сути систему вызовов во что-то вроде видеострима. Полагаю следующим этапом придется добавлять какой-то контроль целостности данных, повторную отправку, докачку при обрыве и все прочие подобные радости.
Не очень понимаю зачем все это было делать в рамках RPC протокола.
Если возникает большой объем передаваемых данных - существует вполне стандартный механизм для их передачи: через отдельную ссылку на скачивание.
В передаваемом ответе фигурирует лишь ссылка на скачивание, само скачивание клиент осуществляет отдельным запросом вне логики RPC.
Это вообщем-то стандартная практика даже для SOAP и REST.
Опять же не зная задачи могу ошибиться, но есть банальный работающий способ для такого: формируется текстовый файл с такими массивами чисел, который затем сжимается в архив и передается в виде бинарного файла.
Цифры сжимаются очень хорошо, на больших объемах будет существенный выигрыш.
С другой стороны происходит распаковка и чтение.
Если данных много то лучше формировать CSV с построчной разбивкой а не пытаться "сериализовать" все сразу и целиком.
В смысле что такое состояние нестыковки клиентского и сервисного интерфейсов в рамках одной системы (те когда вы контролируете и клиентскую и серверную сторону) должно трактоваться как серьезный системный сбой.
На практике это чаще всего будет означать что кто-то из участников процесса выложил не ту сборку или релиз оказался битым, а значит несовпадение сигнатуры вызова лишь последствия а не причина.
Если кратко любые версии интерфейсов не более чем иллюзия, не дающая никакой защиты от внутренних изменений.
Если длинно то вот моя статья на эту тему.
Скорее всего вы описываете Web Services Discovery — это такая попытка создания «DNS для вебсервисов», с моей точки зрения не очень удачная.
Куда чаще проблема заключается не в устаревании списка методов, а в изменении их сигнатуры без предупреждения.
Разумеется только техническими средствами это не решить, такое считается за ошибку и работа останавливается.
Я вообще не понимаю причем тут сериализация, ее если что нет ни в моей реализации ни в большинстве использованных клиентских библиотек.
Там просто парсер XML-запроса и генерация ответа в виде строки.
И то и другое отлично ограничивается по используемым ресурсам.
Не знаю что у вас за случай, но очень сомневаюсь что причина лишь в одном только протоколе.
Вы бы тогда скорее снижением объема трафика хвастались - размеры передаваемых данных по бинарному протоколу разумеется заметно меньше.
Вот вам несколько выдержек из официальной спецификации на JSON, вдруг решите свой парсер написать.
Про юникод:
Про цифры:
Про совместимость:
Так что JSON сложнее и объемнее чем кажется, причем любая его реализация фактически подразумевает undefined behavior, поскольку стандарт описывает и гарантирует лишь синтаксис.
Что касается упомянутого протокола JSON-RPC, то помимо описанных выше проблем есть еще вот такое:
И ниже про обработку ответа:
Получается что никакая реализация JSON-RPC не может быть stateless, поскольку эти самые id нужно где-то хранить.
Эта на первый взгляд мелочь обязательно всплывет при попытке масштабирования такого сервиса.
Тогда тем более - столь великому мастеру не стоит отвлекаться на пустопорожнюю переписку, пусть занимается делом и пишет еще статьи )
В чем сложность вызова удаленных процедур?
Сейчас расскажу.
Допустим у вас клиент и сервер, с которого вызываются процедуры написаны на разных технологиях, что чаще всего и бывает.
Один умеет работать с Unicode, другой нет.
В этом месте JSON по-хорошему заканчивается, поскольку по стандарту любая клиентская реализация JSON должна поддерживать юникод.
А еще есть различия в типах данных, когда у вас один технологический стек считает что строка это набор символов, а другой что строка это массив байт. Где-то есть отдельный булевый тип, где-то его нет и нужно передавать 1\0. Есть отличия в трактовке дат, меток времени и длинных чисел.
Именно из‑за такого количества сложностей большинство RPC фреймворков объемные и сложные — они скрывают все эти детали под капотом и вы просто не задумываетесь о них при работе.
До судного дня Х, когда они вылезают на поверхность.
Фишка XML-RPC как протокола как раз и заключается в том что он не пытается скрывать всю эту сложность, четко обозначая минимально поддерживаемый набор типов.
Поэтому он до сих пор жив и используется, хотя огромная корпорация пытается его задушить с 1998го года.
Как-то так.
Уважаемый ptr128, в интернете давно существует большая проблема с валидацией публикуемых данных, тем более когда речь заходит о сложных технических вещах.
То что вы «нагуглили» это разумеется замечательно, но это не истина в первой инстанции.
Если вы заметили, половина данной статьи состоит из конкретных примеров реально работающего кода на разных языках — все это я на самом деле собрал и запустил.
По этой причине могу подтвердить что оно действительно работает на момент написания статьи.
Если вы в силах повторить подобное для gRPC — пишите статью, коллеги оценят.
P.S.
Я не выступаю против gRPC, да и против вас лично ничего не имею, просто не хочу скатывания разумной технической дискуссии в очередной бессмысленный срач.
Навскидку:
Lisp, TCL, окружения Linux старше 15 лет, практически все коммерческие Unix, промавтоматика, встраиваемые системы, где как раз имеет смысл миниатюризация всех используемых библиотек. Устаревшие Windows.
Разумеется там будет компилятор, но только устаревший, у которого проблемы компиляции даже не находятся поисковиками.