Боюсь, что возможности, близкие к нотации вызова в jsonex – тэги YAML, все-таки выходят за пределы JSON-нотации и выглядят достаточно чужеродно на ее фоне. При этом нотация вызова гибче, чем тэги. Ну и любой валидный JSON-документ точно также является валидным jsonex-документом, как и YAML-документом. Насчет библиотек могу только порадоваться за YAML, но и он когда-то начинал на фоне их отсутствия.
Такой велосипед на первый взгляд требует уйму времени на поддержку (баго фикс, въезжание новых разработчиков в особенности фреймворка).
Это можно сказать о любом фреймворке.
Но возьмите, к примеру batch-запросы Facebook Graph API. Они устроены довольно сложно. С точки зрения клиента, jsonex даже проще, при том, что возможностей у него больше. На серверной стороне batch-запросы Facebook тоже устроены непросто, поверьте. Может, чуточку проще, чем движок arc, но не принципиально. При том, что arc опять же умеет больше.
При этом Facebook не претендует на универсальность подхода в своем batch API. Если вам понадобится использовать batch-запросы другой системы – придется начать с нуля. Если вы захотите реализовать batch-запросы у себя на серверной стороне – нет хорошего способа это сделать. Вы можете мимикрировать под Facebook (и подстраваться под все их изменения) или придумать свой подход – в любом случае решение будет достаточно уникальным.
При этом мы говорим только о batch-запросах, не затрагивая других тем. jsonex решает задачу batch-запросов, а также ряд других задач. При этом в качестве решения берется очень простое расширение всем знакомого JSON. Если ваша система «говорит на jsonex», в ней уже есть batch-запросы, кастомные типы данных и прочие плюшки. И вы можете общаться с любой системой, поддерживающей jsonex не внося изменений в подходы к построению запросов и обработке данных.
Далее по вашим вопросам.
Зачем нужны batch-запросы? В самом элементарном случае мы можем сделать RESTful api для каждого из запросов, параллельность выполнения чанков можем гарантировать на стороне клиента.
Во-первых, клиент (браузер) очень плохо гарантирует параллельность выполнения чанков. Число одновременных подключений к одному домену ограничено. SPDY или его аналог когда-нибудь решит эту проблему, но пока она есть.
Но даже если бы ее не было. Часто вам нужно получить одни данные, а затем на их основе получить другие. В этом случае запросы не параллелятся. Чтобы вытащить друзей ваших друзей, вам придется сделать два последовательных запроса. Либо добавить в API специальный вызов для вытаскивания друзей друзей (а также кучу других вызовов, вытаскивающих прочие комбинации зависимых данных, которые вам могут понадобиться). Альтернативное решение – batch-запросы с поддержкой зависимых вызовов. Как в том же Facebook Graph API, или как в jsonex.
Что за юз кейс для выполнения на клиенте произвольного кода? Почему бы не использовать некий eval валидного js-кода на стороне сервера хотя бы?
jsonex не позволяет выполнять произвльный код, ни на клиенте, ни на сервере. Только заранее определенные обработчики, смысл которых, равно как и возможные параметры, должен быть явно прописан в API. В случае jsonex ваши обработчики и есть API, включающее как возможные серверные вызовы, так и спецификацию нестандартных типов данных.
Я правильно понимаю, что схемы нет в проекте? Ну то есть если мы отправляем объект типа Person в одном запросе на сервер может прийти поле с именем dateOfBirth, а во втором birthDate? Если есть, то почему мы железно должны указывать тип данных например Date, а не определять его по схеме?
Если у вас есть схема данных с четко прописанными типами, конечно, вы можете ее использовать. Это не даст вам других возможностей jsonex, но с типами данных все будет хорошо )
И конечно же, отсутствие формального описания схемы данных вовсе не дает вам право отдавать дату рождения то как dateOfBirth, то как birthDate – в пределах серверного кода вы ведь так не делаете, не смотря на всю эту динамическую типизацию? Здесь ровно то же самое.
jsonex позволяет вам не иметь схемы данных. А если она есть – отделить валидацию согласно схеме данных от парсинга. В случае обработки JSON вам придется прямо во время валидации интерпретировать данные согласно схеме, чтобы ту же банальную дату, переданную в виде строки, превратить в объект даты и подставить в нужное место. Если вы этого не сделаете, вас будет ждать сюрприз в качестве строки в поле, в котором ожидается дата. Вам понадобится хитрый валидатор, который умеет не только проверять корректность данных, но и модифицировать их согласно схеме. По моему опыту, многие за неимением такого валидатора разбирают пришедшие данные вручную, независимо от наличия или отсутствия схемы.
jsonex отдаст вам готовые объекты. Хотите – валидируйте после, хотите – прямо в обрабочиках. Хотите – не валидируйте. Вся явная чушь все равно должна быть отсеяна обработчиками во имя принципов безопасности.
Пока это в первую очередь концепция, к которой я сам отношусь осторожно. После того, как появится первый проект, активно использующий jsonex для клиент-серверного взаимодействия, появится новая статья, из которой будет понятно, оправдались ли радужные надежды и какие проблемы возникли при столкновении с реальностью.
Первоочередная цель этой статьи – поделиться идеей с теми, кто решает похожие задачи. Идея может оказаться полезной, а отзывы будут бесценными. В конце концов, при проектировании я думаю в первую очередь о своих собственных задачах и могу упустить что-то важное.
Как можно заметить по выбору хабов, jsonex ориентирован в первую очередь на веб-разработку и JS. Он выглядит очень естественно для JS-разработчиков, а в случае использования JS на стороне сервера, один и тот же код обработчиков можно использовать с обеих сторон.
Будет ли jsonex широко использоваться – вопрос истории. А документация будет )
Разумеется, я думал в первую очередь о своих задачах и нуждах )
Но тем более интересно – что же хотелось бы улучшить вам?
Соглашусь, что ничего концептуально нового тут нет – «нотация вызова» широко используется в языках программирования. Но чтобы увидеть ее ценность применительно к формату данных, потребовалась долгая дорога.
В отличие от YAML, очень развесистого формата с много-много-страничной спецификацией, jsonex является тривиальным расширением простейшего JSON, спецификация которого занимает одну страницу. При этом jsonex легко расширяем, имеет родственный JS синтаксис и позволяет конструировать сложные запросы к серверу в тех же терминах, что и обычные данные. Полагаю, это может оказаться полезным.
Совершенно верно. В дополнение к сказанному ниже, хочу также заметить, что jsonex лишь вносит дополнительную ясность в сложных случаях. Если вы используете нестандартные типы данных, конечно же вам нужно описать их в документации API. Например, вы можете указать, что нотация Date() означает дату и имеет своим единственным аргументом дату в таком-то формате.
В случае необходимости использовать даты в JSON, вам пришлось бы делать приписку к каждому полю, содержащему дату, указывая, в каком она формате, либо делать где-то пометку, что все даты передаются в формате таком-то и надеяться, что все обратят на эту надпись внимание и никто ничего не напутает. Если даты – ваша единственная проблема, это еще куда не шло. При большем разнообразии типов запутаться еще проще.
К сожалению, любой достаточно гибкий и мощный инструмент будет грозить быдлокодерством. В том числе и сам JS.
Если приложение большое, то скорее всего есть модели на клиенте, никто не мешает сделать так new Person(jsonData) и внутри уже в черном ящике приводим данные к нужному виду, зачем усложнять общение с сервером?!
Насчет черного ящика – верно, но для поддержки любых типов данных за пределами набора, предоставляемого JSON, придется либо держать схему с явно прописанными типами полей, либо городить странные конструкции. Именно этого хотелось бы избежать. Конечно, если схема уже есть – никаких проблем, используйте схему.
Что касается «усложнения» общения с сервером – если вам не нужны batch-запросы, вы не используете типов данных за пределами поддерживаемых в JSON или для всего уже есть схема, которая тщательно поддерживается, если вам не нужна возможность делать API доступным как по HTTP, так и по веб-сокетам, а то и по каким-то еще протоколам, то конечно, не надо ничего усложнять. Но если вам нужны какие-то из этих возможностей – jsonex дает их все разом, простым и согласованным способом. То, над реализацией чего вы могли бы ломать голову, становится уже решенной задачей.
Ведь эти данные мы не сможем использовать нигде больше — в них логика! Т.е. Public api такрй делать нельзя
Никто вас не заставляет засовывать логику в данные. В данных вида Date('1991-01-01') не больше логики, чем в <date>1991-01-01</date> – нотации вызова можно считать своего рода тэгами, данные остаются данными. То, что парсер трактует Date() как вызов некой функции – всего лишь деталь реализации, позволяющая сделать парсер простым и расширяемым.
Конечно же, с помощью jsonex можно делать публичный API. Главное, чтобы клиенты понимали тот набор «тэгов», которым вы оперируете. Но это верно для любого API – та часть данных, которую клиент не может интерпретировать, будет ему бесполезна. В jsonex вы можете отбрасывать все незнакомые нотации вызова, заменяя их на null или какую-то структуру общего назначения – для этого и нужен обработчик по умолчанию. Точно также, в XML вы игнорируете теги, которые вам не интересны.
В самих запросах к серверу, конечно, логика может присутствовать, также как она может присутствовать в SQL-запросах и любых более-менее сложных языках запросов. Это и прекрасно. Это позволяет конструировать гораздо более сложные запросы, когда они вам нужны. Но можно и запретить их использовать, если они вам без надобности.
Куда его там навесить, если место экономят даже на размере симок? )
Кроме размера у разъема есть и другие характеристики, которые потенциально можно улучшать.
Я не против стандартов — пусть существуют и конкурируют.
Я не против даже рекомендуемых стандартов.
Я только за, когда какая-то группа по собственной воле договаривается использовать единый стандарт.
Но я против объявления всех стандартов кроме одного вне закона.
А именно это произошло.
По самым разным вопросам временами казалось, что дальнейшее усовершенствование невозможно.
Как правило, казалось ошибочно.
Может, усовершенствовали бы по другим параметрам.
Может, придумали бы что-то принципиально новое.
А так — зачем? Есть же утвержденный законом стандарт. )
Если закон реально будет работать — он затормозит появление новых, более совершенных разъемов.
А они довольно бурно эволюционировали, отсюда во многом и зоопарк.
Стандарты должны конкурировать на других принципах, нежели «чиновник так решил».
Когда все по ГОСТу, это, конечно, с одной стороны удобно, а с другой — поди-ка протащи что-то новое, каким бы хорошим оно ни было.
Эта новость заставляет вспомнить высказывание, что Европа — это новый СССР по уровню бюрократических странностей )
Я не уверен, но, наверное, там возможно использование source maps
Возможно, но даже без source maps отладка вполне вменяемая, т.к. тело каждого модуля остается неизменным (добавляется только обвязка).
Но главный плюс browserify — возможность использования npm для собирания и использования пакетов. Это очень мощный инструмент, который недоступен всем другим «склейщикам» и иже с ними.
И эта возможность с лихвой компенсирует лишние телодвижения, связанные с source maps и прочими возможными неудобствами, поскольку избавляет от огромной кучи лишних телодвижений в других местах.
Основная фишка browserify не столько «эмуляция» ноды в браузере (хотя именно с этой идеи все началось), сколько возможность использовать CommonJS и npm для сборки клиентских пакетов, что очень удобно.
Кроме того, browserify позволяет создавать универсальные пакеты, которые могут работать в обоих мирах (см. опцию "browser") — это моя любимая часть его магии )
Что касается эмуляции fs, то сделать shim, который в какой-то мере решает эту задачу, наверное, не так уж и сложно.
Но я бы скорее ставил на появление пакетов, учитывающих возможность запуска в окружении Firefox OS и Chrome Apps, и ведущих себя там правильным образом. Такую возможность зачастую несложно добавить, даже если она изначально не предусмотрена автором.
И делать это будет еще проще, если появятся готовые библиотеки, предоставляющие единый интерфейс для доступа к подобным частям системы в разных окружениях. Здесь вопрос только в активности сообщества и готовности развивать эту тему.
Казалось бы, если все браузеры поддерживают кроссдоменное общение между фреймами, так почему бы сразу в приложении не открыть окно для авторизации в iframe? Но тут подножку ставит заботливый CORS – практически на всех OAuth серверах запрещено открытие страницы авторизации в фрейме.
Не CORS, а X-Frame-Options.
Это сделано для защиты от кликджекинга (ClickJacking).
Судя по синтаксису, require работает практически также как в ноде (вопросы вызывают только правила записи идентификатора модуля при загрузке из файловой системы), а import просто выкладывает в глобальную область видимости части загруженного «модуля» (судя по всему, обычного JS-объекта).
RequireJS никто не мешает перекрыть эту функцию по собственному усмотрению и использовать внутри себя оригинал, например.
В общем, введение модулей в таком стиле нанесет минимум повреждений существующим подходам. Да, возможно что-то придется поправить по-мелочи, но про «волосы дыбом» — это перебор )
Это можно сказать о любом фреймворке.
Но возьмите, к примеру batch-запросы Facebook Graph API. Они устроены довольно сложно. С точки зрения клиента, jsonex даже проще, при том, что возможностей у него больше. На серверной стороне batch-запросы Facebook тоже устроены непросто, поверьте. Может, чуточку проще, чем движок arc, но не принципиально. При том, что arc опять же умеет больше.
При этом Facebook не претендует на универсальность подхода в своем batch API. Если вам понадобится использовать batch-запросы другой системы – придется начать с нуля. Если вы захотите реализовать batch-запросы у себя на серверной стороне – нет хорошего способа это сделать. Вы можете мимикрировать под Facebook (и подстраваться под все их изменения) или придумать свой подход – в любом случае решение будет достаточно уникальным.
При этом мы говорим только о batch-запросах, не затрагивая других тем. jsonex решает задачу batch-запросов, а также ряд других задач. При этом в качестве решения берется очень простое расширение всем знакомого JSON. Если ваша система «говорит на jsonex», в ней уже есть batch-запросы, кастомные типы данных и прочие плюшки. И вы можете общаться с любой системой, поддерживающей jsonex не внося изменений в подходы к построению запросов и обработке данных.
Далее по вашим вопросам.
Во-первых, клиент (браузер) очень плохо гарантирует параллельность выполнения чанков. Число одновременных подключений к одному домену ограничено. SPDY или его аналог когда-нибудь решит эту проблему, но пока она есть.
Но даже если бы ее не было. Часто вам нужно получить одни данные, а затем на их основе получить другие. В этом случае запросы не параллелятся. Чтобы вытащить друзей ваших друзей, вам придется сделать два последовательных запроса. Либо добавить в API специальный вызов для вытаскивания друзей друзей (а также кучу других вызовов, вытаскивающих прочие комбинации зависимых данных, которые вам могут понадобиться). Альтернативное решение – batch-запросы с поддержкой зависимых вызовов. Как в том же Facebook Graph API, или как в jsonex.
jsonex не позволяет выполнять произвльный код, ни на клиенте, ни на сервере. Только заранее определенные обработчики, смысл которых, равно как и возможные параметры, должен быть явно прописан в API. В случае jsonex ваши обработчики и есть API, включающее как возможные серверные вызовы, так и спецификацию нестандартных типов данных.
Если у вас есть схема данных с четко прописанными типами, конечно, вы можете ее использовать. Это не даст вам других возможностей jsonex, но с типами данных все будет хорошо )
И конечно же, отсутствие формального описания схемы данных вовсе не дает вам право отдавать дату рождения то как dateOfBirth, то как birthDate – в пределах серверного кода вы ведь так не делаете, не смотря на всю эту динамическую типизацию? Здесь ровно то же самое.
jsonex позволяет вам не иметь схемы данных. А если она есть – отделить валидацию согласно схеме данных от парсинга. В случае обработки JSON вам придется прямо во время валидации интерпретировать данные согласно схеме, чтобы ту же банальную дату, переданную в виде строки, превратить в объект даты и подставить в нужное место. Если вы этого не сделаете, вас будет ждать сюрприз в качестве строки в поле, в котором ожидается дата. Вам понадобится хитрый валидатор, который умеет не только проверять корректность данных, но и модифицировать их согласно схеме. По моему опыту, многие за неимением такого валидатора разбирают пришедшие данные вручную, независимо от наличия или отсутствия схемы.
jsonex отдаст вам готовые объекты. Хотите – валидируйте после, хотите – прямо в обрабочиках. Хотите – не валидируйте. Вся явная чушь все равно должна быть отсеяна обработчиками во имя принципов безопасности.
Первоочередная цель этой статьи – поделиться идеей с теми, кто решает похожие задачи. Идея может оказаться полезной, а отзывы будут бесценными. В конце концов, при проектировании я думаю в первую очередь о своих собственных задачах и могу упустить что-то важное.
Как можно заметить по выбору хабов, jsonex ориентирован в первую очередь на веб-разработку и JS. Он выглядит очень естественно для JS-разработчиков, а в случае использования JS на стороне сервера, один и тот же код обработчиков можно использовать с обеих сторон.
Будет ли jsonex широко использоваться – вопрос истории. А документация будет )
Но тем более интересно – что же хотелось бы улучшить вам?
Соглашусь, что ничего концептуально нового тут нет – «нотация вызова» широко используется в языках программирования. Но чтобы увидеть ее ценность применительно к формату данных, потребовалась долгая дорога.
Date()означает дату и имеет своим единственным аргументом дату в таком-то формате.В случае необходимости использовать даты в JSON, вам пришлось бы делать приписку к каждому полю, содержащему дату, указывая, в каком она формате, либо делать где-то пометку, что все даты передаются в формате таком-то и надеяться, что все обратят на эту надпись внимание и никто ничего не напутает. Если даты – ваша единственная проблема, это еще куда не шло. При большем разнообразии типов запутаться еще проще.
К сожалению, любой достаточно гибкий и мощный инструмент будет грозить быдлокодерством. В том числе и сам JS.
Насчет черного ящика – верно, но для поддержки любых типов данных за пределами набора, предоставляемого JSON, придется либо держать схему с явно прописанными типами полей, либо городить странные конструкции. Именно этого хотелось бы избежать. Конечно, если схема уже есть – никаких проблем, используйте схему.
Что касается «усложнения» общения с сервером – если вам не нужны batch-запросы, вы не используете типов данных за пределами поддерживаемых в JSON или для всего уже есть схема, которая тщательно поддерживается, если вам не нужна возможность делать API доступным как по HTTP, так и по веб-сокетам, а то и по каким-то еще протоколам, то конечно, не надо ничего усложнять. Но если вам нужны какие-то из этих возможностей – jsonex дает их все разом, простым и согласованным способом. То, над реализацией чего вы могли бы ломать голову, становится уже решенной задачей.
Никто вас не заставляет засовывать логику в данные. В данных вида
Date('1991-01-01')не больше логики, чем в<date>1991-01-01</date>– нотации вызова можно считать своего рода тэгами, данные остаются данными. То, что парсер трактуетDate()как вызов некой функции – всего лишь деталь реализации, позволяющая сделать парсер простым и расширяемым.Конечно же, с помощью jsonex можно делать публичный API. Главное, чтобы клиенты понимали тот набор «тэгов», которым вы оперируете. Но это верно для любого API – та часть данных, которую клиент не может интерпретировать, будет ему бесполезна. В jsonex вы можете отбрасывать все незнакомые нотации вызова, заменяя их на null или какую-то структуру общего назначения – для этого и нужен обработчик по умолчанию. Точно также, в XML вы игнорируете теги, которые вам не интересны.
В самих запросах к серверу, конечно, логика может присутствовать, также как она может присутствовать в SQL-запросах и любых более-менее сложных языках запросов. Это и прекрасно. Это позволяет конструировать гораздо более сложные запросы, когда они вам нужны. Но можно и запретить их использовать, если они вам без надобности.
Кроме размера у разъема есть и другие характеристики, которые потенциально можно улучшать.
Я не против даже рекомендуемых стандартов.
Я только за, когда какая-то группа по собственной воле договаривается использовать единый стандарт.
Но я против объявления всех стандартов кроме одного вне закона.
А именно это произошло.
Как правило, казалось ошибочно.
Может, усовершенствовали бы по другим параметрам.
Может, придумали бы что-то принципиально новое.
А так — зачем? Есть же утвержденный законом стандарт. )
А они довольно бурно эволюционировали, отсюда во многом и зоопарк.
Стандарты должны конкурировать на других принципах, нежели «чиновник так решил».
Когда все по ГОСТу, это, конечно, с одной стороны удобно, а с другой — поди-ка протащи что-то новое, каким бы хорошим оно ни было.
Эта новость заставляет вспомнить высказывание, что Европа — это новый СССР по уровню бюрократических странностей )
Возможно, но даже без source maps отладка вполне вменяемая, т.к. тело каждого модуля остается неизменным (добавляется только обвязка).
Но главный плюс browserify — возможность использования npm для собирания и использования пакетов. Это очень мощный инструмент, который недоступен всем другим «склейщикам» и иже с ними.
И эта возможность с лихвой компенсирует лишние телодвижения, связанные с source maps и прочими возможными неудобствами, поскольку избавляет от огромной кучи лишних телодвижений в других местах.
Кроме того, browserify позволяет создавать универсальные пакеты, которые могут работать в обоих мирах (см. опцию "browser") — это моя любимая часть его магии )
Что касается эмуляции fs, то сделать shim, который в какой-то мере решает эту задачу, наверное, не так уж и сложно.
Но я бы скорее ставил на появление пакетов, учитывающих возможность запуска в окружении Firefox OS и Chrome Apps, и ведущих себя там правильным образом. Такую возможность зачастую несложно добавить, даже если она изначально не предусмотрена автором.
И делать это будет еще проще, если появятся готовые библиотеки, предоставляющие единый интерфейс для доступа к подобным частям системы в разных окружениях. Здесь вопрос только в активности сообщества и готовности развивать эту тему.
А browserify не поможет?
Активно использую npm для клиентских пакетов с помощью этой штуки.
Очень доволен )
Не CORS, а X-Frame-Options.
Это сделано для защиты от кликджекинга (ClickJacking).
В harmony местами такое предлагают, что за судьбу JS страшно становится.
Рад, что в итоге добавляется только самое лучшее и продуманное.
Судя по синтаксису, require работает практически также как в ноде (вопросы вызывают только правила записи идентификатора модуля при загрузке из файловой системы), а import просто выкладывает в глобальную область видимости части загруженного «модуля» (судя по всему, обычного JS-объекта).
RequireJS никто не мешает перекрыть эту функцию по собственному усмотрению и использовать внутри себя оригинал, например.
В общем, введение модулей в таком стиле нанесет минимум повреждений существующим подходам. Да, возможно что-то придется поправить по-мелочи, но про «волосы дыбом» — это перебор )