Без цифр, фразы «в разы», ничем не подкрепляются.
Если вам удобно поддерживать protobuf, никто же вам не навязывает, что-либо другое :)
очень часто хочется ломать руки разработчикам
Хочется, если это делать бездумно. Если нам в какой-то момент времени Х потребовалось прямо сейчас получить специфическую отладочную информацию от сервиса — это бывает крайне удобно в условиях продакшна. И я не говорю, что это правильно или ещё чего, это действительно просто удобно. Разработчики часто балансируют вокруг данного слова выбирая, например, какие-либо фреймворки.
Насколько я понимаю ссылка на бенчмарки использует не совсем официальную библиотеку для javascript'а.
Могу ошибаться, конечно, но на сайте разработчика msgpack.org явно указано, что js порт работает только из под nodejs:
In the Browser
This library is compatible with Browserify.
If you want to use standalone, grab the file in the dist folder of this repo, and use in your own HTML page, the module will expose a msgpack5 global.
В вашем же примере используется форк 3х годичной давности github.com/creationix/msgpack-js-browser
Поэтому вполне возможно, что ситуация с javascript'ом также улучшилась.
Protobuf немного в другом ключе, там требуется явное описание структуры ваших данных, которые вы передаете от сервиса к сервису. Кроме того каждый тип вашего сообщения будет требовать отдельные .proto файлы, дабы всем этим управлять.
То есть фактически Protobuf «за занавесом» эмулирует полную передачу объекта и его восстановления в случае, если это возможно. Очень актуально в контексте передачи классов между C и Java, например, чтобы быть точно уверенным, что по обе стороны будет все ок. Кроме того, актуальность .proto файлов, естественно ложится на плечи разработчика. Тут, как говорится, дело вкуса. Если вам по вкусу жесткая типизация каждого сообщения в вашей системе — тогда да, бесспорно Protobuf является отличным выбором. Если вам по вкусу слабая типизации и возможность добавить новое поле в состав сообщения «на лету», как с JSON'ом, — тогда выбор будет в пользу MsgPack или его аналогов, как приводили примеры выше.
К сожалению, я не очень знаком с python'ом, но насколько я понимаю сейчас существует 2 реализации самой библиотеки для данного языка. Здесь есть немного устаревшие графики сравнения производительности за апрель 2014 wtanaka.com/node/8100 с библиотекой msgpack-python. В ней автор статьи утверждает, что как раз наоборот по тестам упаковки/распаковки она получается быстрее json'а за исключением упаковки словаря.
Также, если я правильно понимаю, разработчик который в данный момент поддерживает форк для пайтона и на библиотеку которого я ссылаюсь в статье u-msgpack-python утверждает: github.com/vsergeev/u-msgpack-python/issues/4
msgpack-python should be faster when used with its native library backend (it only falls back to pure Python when the library is unavailable). msgpack-python also supports a streaming unpacking mode and finer control over the unpacking process if you need them.
I'm not sure why msgpack-python is not listed on there — it always used to be. I think the author took it down temporarily to implement msgpack 2.0, but I would expect it to have been back up by now.
Думаю, можно попробовать тест с msgpack-python и получить совершенно другие цифры из-за её специфики реализации. Всего лишь предположение.
Также разработчику u-msgpack-python можно сообщить о ваших наблюдениях через тикет на гитхабе github.com/vsergeev/u-msgpack-python/issues
Думаю указав на это можно будет получить соответствующий патч, либо прояснить причину столь существенной просадки производительности по вашим тестам.
Наверно стоит уточнить, что под «стандартами сериализации» речь шла о структурах данных (массивы, объекты, встроенные типы и т.д.), которые можно сериализировать, т.к. похоже предыдущим комментом меня не поняли.
В плане стандартов сериализации, что все что у вас сериализировалось в json будет спокойно сериализироваться в бинарное представление за исключением указанных ограничений.
Под задачей понималось сериализация и десериализация сообщений. В этом аспекте никто не говорил о том, что JSON плохой формат или что-то ещё. У нас используется MsgPack именно для упаковки и передачи сообщения от сервиса к сервису. Раньше был обычный JSON, сменив его на MsgPack мы получили экономию по трафику, что является бесспорным плюсом о чем я и поведал в данном посте.
Думаю, что это как с линуксом, есть много дистрибутивов и каждому по душе что-то свое.
Насчет CBOR, отлично что написали — посмотрю, не знал раннее, но как вы заметили оба формата решают одну задачу.
Спасибо за ваш отзыв. Да, слышал / читал. Комментарии в коде появятся, обязательно :)
Выбор в пользу зендовский макросов был сделан исключительно потому что с ними уже был знаком раннее. В ядре php достаточно много расширений где можно что-то подсмотреть, а вот используется ли в продакшене PHP-CPP, к сожалению не владею информацией.
Коллеги, — ограничения будут всегда. С этим не нужно бороться, — это нужно принимать как факт. Точно также как солнце встает с утра — также и расширение любой практики имеет свои недостатки и ограничения. В ООП — мы будем ограничены архитектурными паттернами, либо паттернами проектирования, в функциональном тем, что в нужном месте не добавили функцию расширяющую возможность предыдущей, либо недостаточно подумали об имитации инкапсуляции. На уровне компиляторов, что ваши функции (в функциональном стиле), что ваши методы — выглядят одинаково — это инструкции процессору, все. С этой точки зрения был подан и предыдущий пост. Тем, кто этого не понял советую смотреть дальше, чем прочтение правил (парадигм) в глубь их реализаций.
ps: прошу заметить, что я не наезжаю на ООП и не защищаю функциональщину и прекрасно понимаю преимущества, а также недостатки данных парадигм;
И что, вы посмотрите, дальше?
Если для вас ООП парадигма является более понятной, чем функциональная это не значит, что последнее плохо.
По сути, без претензий и холиваров, чем инструкции:
class A { function b():String { return 'Hello world'; } } function A_b():String { return 'Hello world'; }
A a = new A(); A.b();
A_b();
отличаются друг от друга?
Тем, что в первом случае вы написали точку, а во втором нет?
Это всего лишь _способ_ группирования данных / логики. На вкус и цвет все фломастеры разные. Поэтому одна группа людей будет предпочитать выделить память, инициализировать объект — другая вызвать эту же функцию. Да в первом случае у вас будет контест по умолчанию (this) во втором вам его придется _явно_ передавать в _каждую_ функцию. Чисто визуально на этом различия заканчиваются. Далее все зависит от рук человека, который будет этот код писать. Ибо, что в классах вы можете написать бред запутав свою программу:
class A {
protected SomeClass someClass;
function b():void { this.c(); /* что-то ещё */ this.f(); } function c():void { this.f(); /* что-то ещё */ someClass.a(); } function d():void { } function f():void { someClass.d(); }
}
что в функциях. Ни с ООП, ни без него вы не застрахованны в том, что ваш код будет «понятным» кому-то ещё кроме вас.
Ни одна парадигма не является панацеей точно также как и не умело следуя парадигме можно писать трудно поддерживаемый код. Обсуждать это и холиварить бесполезно все зависит от типов мышления команды, которая данный код разрабатывает. Никто и никогда не заставит функциональщика писать в объектном стиле и наоборот. Потому как данные люди слепо следуют описанным правилам игры (парадигмам).
Если в проекте бездумно используют парадигмы только из слов крутости — это ставит под сомнение профпригодность команды. Любая парадигма либо методология это по факту банальная рекомендация по организации кода внутри вашей команды. Выбирайте то, что вам близко и что все одинаково понимают. Если в процессе работы над проектом перестает устраивать организация кода, становится запутанным для понимания — рефакторите его так, как считаете нужным исходя из выбранной парадигмы.
Интересно, а размер самого репозитория при столь большом количестве веток сильно разрастается?
Нет ли проблемы конечному разработчику банально все это выкачать в свое локальное окружение?
Да, верно — нужно для каждого действия спрашивать разрешение. А разрешено ли мне view или edit или delete.
Это базовые построения ACL и мне сложно представить, как можно проектировать иначе. В фреймворках озвученных мною в посте подобные принципы происходят за кулисами методов isAllow, например. Да и в любых системах основанных на списках доступа — вы получаете массив списков, как-то их храните, при запросе разрешения проходите по массиву и если находите соответствие — разрешаете или нет. На конечных, администраторских страницах, если вам нужно показать список доступных действий — вы можете уже предусмотреть вытяжку их напрямую из конфигурационного файла, ибо вы знаете что описали и для чего.
А что вы хотите этим сказать?
Вы задаете правила в конфиг файле. Что у вас там разрешено или запрещено. Далее по мере проверки прав в своем приложении вы спрашиваете, а разрешено ли мне --resource project:test:news
При условии, что вы задали правило для указанной роли, например, как project:*:news = allow
Вам соответственно утилита ответить access allow.
Если вопрос был в том, чтобы получить куда-то на клиента список всех *:news — нет, так нельзя. Утилита дает лишь ответ access allow или access denied, ибо она призвана делать проверку прав в соответствии с заданными шаблонами, не более.
и она заточена под .NET платформу?
Если вам удобно поддерживать protobuf, никто же вам не навязывает, что-либо другое :)
Хочется, если это делать бездумно. Если нам в какой-то момент времени Х потребовалось прямо сейчас получить специфическую отладочную информацию от сервиса — это бывает крайне удобно в условиях продакшна. И я не говорю, что это правильно или ещё чего, это действительно просто удобно. Разработчики часто балансируют вокруг данного слова выбирая, например, какие-либо фреймворки.
Могу ошибаться, конечно, но на сайте разработчика msgpack.org явно указано, что js порт работает только из под nodejs:
В вашем же примере используется форк 3х годичной давности github.com/creationix/msgpack-js-browser
Поэтому вполне возможно, что ситуация с javascript'ом также улучшилась.
То есть фактически Protobuf «за занавесом» эмулирует полную передачу объекта и его восстановления в случае, если это возможно. Очень актуально в контексте передачи классов между C и Java, например, чтобы быть точно уверенным, что по обе стороны будет все ок. Кроме того, актуальность .proto файлов, естественно ложится на плечи разработчика. Тут, как говорится, дело вкуса. Если вам по вкусу жесткая типизация каждого сообщения в вашей системе — тогда да, бесспорно Protobuf является отличным выбором. Если вам по вкусу слабая типизации и возможность добавить новое поле в состав сообщения «на лету», как с JSON'ом, — тогда выбор будет в пользу MsgPack или его аналогов, как приводили примеры выше.
Также, если я правильно понимаю, разработчик который в данный момент поддерживает форк для пайтона и на библиотеку которого я ссылаюсь в статье u-msgpack-python утверждает:
github.com/vsergeev/u-msgpack-python/issues/4
Думаю, можно попробовать тест с msgpack-python и получить совершенно другие цифры из-за её специфики реализации. Всего лишь предположение.
Также разработчику u-msgpack-python можно сообщить о ваших наблюдениях через тикет на гитхабе github.com/vsergeev/u-msgpack-python/issues
Думаю указав на это можно будет получить соответствующий патч, либо прояснить причину столь существенной просадки производительности по вашим тестам.
Насчет CBOR, отлично что написали — посмотрю, не знал раннее, но как вы заметили оба формата решают одну задачу.
Выбор в пользу зендовский макросов был сделан исключительно потому что с ними уже был знаком раннее. В ядре php достаточно много расширений где можно что-то подсмотреть, а вот используется ли в продакшене PHP-CPP, к сожалению не владею информацией.
Тесты проводились на версии PHP 5.4.4-14+deb7u9 и boost 1.49
ps: прошу заметить, что я не наезжаю на ООП и не защищаю функциональщину и прекрасно понимаю преимущества, а также недостатки данных парадигм;
Если для вас ООП парадигма является более понятной, чем функциональная это не значит, что последнее плохо.
По сути, без претензий и холиваров, чем инструкции:
class A { function b():String { return 'Hello world'; } }function A_b():String { return 'Hello world'; }A a = new A();A.b();A_b();отличаются друг от друга?
Тем, что в первом случае вы написали точку, а во втором нет?
Это всего лишь _способ_ группирования данных / логики. На вкус и цвет все фломастеры разные. Поэтому одна группа людей будет предпочитать выделить память, инициализировать объект — другая вызвать эту же функцию. Да в первом случае у вас будет контест по умолчанию (this) во втором вам его придется _явно_ передавать в _каждую_ функцию. Чисто визуально на этом различия заканчиваются. Далее все зависит от рук человека, который будет этот код писать. Ибо, что в классах вы можете написать бред запутав свою программу:
class A {protected SomeClass someClass;function b():void { this.c(); /* что-то ещё */ this.f(); }function c():void { this.f(); /* что-то ещё */ someClass.a(); }function d():void { }function f():void { someClass.d(); }}что в функциях. Ни с ООП, ни без него вы не застрахованны в том, что ваш код будет «понятным» кому-то ещё кроме вас.
Если в проекте бездумно используют парадигмы только из слов крутости — это ставит под сомнение профпригодность команды. Любая парадигма либо методология это по факту банальная рекомендация по организации кода внутри вашей команды. Выбирайте то, что вам близко и что все одинаково понимают. Если в процессе работы над проектом перестает устраивать организация кода, становится запутанным для понимания — рефакторите его так, как считаете нужным исходя из выбранной парадигмы.
Нет ли проблемы конечному разработчику банально все это выкачать в свое локальное окружение?
Это базовые построения ACL и мне сложно представить, как можно проектировать иначе. В фреймворках озвученных мною в посте подобные принципы происходят за кулисами методов isAllow, например. Да и в любых системах основанных на списках доступа — вы получаете массив списков, как-то их храните, при запросе разрешения проходите по массиву и если находите соответствие — разрешаете или нет. На конечных, администраторских страницах, если вам нужно показать список доступных действий — вы можете уже предусмотреть вытяжку их напрямую из конфигурационного файла, ибо вы знаете что описали и для чего.
Вы задаете правила в конфиг файле. Что у вас там разрешено или запрещено. Далее по мере проверки прав в своем приложении вы спрашиваете, а разрешено ли мне --resource project:test:news
При условии, что вы задали правило для указанной роли, например, как project:*:news = allow
Вам соответственно утилита ответить access allow.
Если вопрос был в том, чтобы получить куда-то на клиента список всех *:news — нет, так нельзя. Утилита дает лишь ответ access allow или access denied, ибо она призвана делать проверку прав в соответствии с заданными шаблонами, не более.