LINUX.ORG.RU

Чем вы пользуетесь для валидации JSON-а?

 ,


1

4

Здравствуйте

Вдумчивое гугление привело меня к выводу, что тема валидаторов раскрыта плохо. Да, есть json-schema, но, складывается впечатление, что мало кто ей пользуется. Есть еще ряд проектов сомнительного свойства, например joi, который умудрились сделать зависимым от node.js

Хотелось бы узнать, а чем вы пользуетесь для проверки входных данных на адекватность?

Deleted

Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от vertexua

Serde ещё слабо помогает работать с сериализаторами для межязыкового взаимодействия, приходится дуплицировать схему, в зависимости от реализации

Беда. Прям напрашивается языконезависимая схема, одна для всех

Deleted
()

https://github.com/mafintosh/is-my-json-valid

В текущий момент времени юзаю везде это. Раньше было что-то другое, но там разработка прекратилась на долгое время.

Да, есть json-schema, но, складывается впечатление, что мало кто ей пользуется.

кажется перед нами потенциальный автор еще одного никому не нужного валидатора :)

Vit ★★★★★
()

В качестве грязного хака, если на проекте уже есть PostgreSQL - использовать в нем проверку на валидность.

Кроме обычных проверок можно еще и своих интересных накрутить.

anonymous
()
Ответ на: комментарий от Deleted

Есть такое. Нативный JSON.parse быстрее и эффективнее родит js-объекты

Только на хелвордах. Ну и без учёта валидации. К тому же, на клиенте не особо это важно. А вот на сервере есть нативный парсер.

чем ненативный protobuf-парсер.

Он то ещё говно, но куда лучше жсона.

Tsaruchetka
()
Ответ на: комментарий от Vit

https://github.com/mafintosh/is-my-json-valid

Закинул в закладки. Кодогенерация это гуд

кажется перед нами потенциальный автор еще одного никому не нужного валидатора :)

Господь миловал. Но прежде 20КБ тайпскрипта все-таки успел написать :)

Deleted
()
Ответ на: комментарий от Tsaruchetka

Ну и без учёта валидации. К тому же, на клиенте не особо это важно

Согласен

Он то ещё говно

Но почему?

Deleted
()
Ответ на: комментарий от Deleted

Но почему?

Ну потому что слишком избыточно, если у тебя один и тот же язык и там и там(а у тебя скорее всего так и есть), то проще и лучше использовать описание форматов кодом, в моделях.

К тому же он тормозной и нужно костылять свой протокол поверх него, т.к. он не умеет сам передавать типы. Либо использовать что-то готовое, но оно так же говно.

Поэтому проще взять и запилить свой протокол. Вся эта компрессия тебе ненужна(раз ты используешь жсон убогий). По-сути тебе нужна строка/число и массив/тапл. И я уже не помню как там с блобами.

Tsaruchetka
()
Ответ на: комментарий от Tsaruchetka

С протоколом да, беда. gRPC еще не курил, но то, что он только для HTTP2, осуждаю. Наверное есть тому разумная причина

Либо использовать что-то готовое, но оно так же говно

Еще бы были они. Стандарта-то нет. Есть тухлые нестандартные реализации для одного языка. Видать придется самому городить

Deleted
()

Dimez. Говно, к ноге падаль. Побежала, шлюха, обосновывать за флуд. Бегом.

anonymous
()

Ничем. У нас весь JSON почти плоский, так что достаточно просто в коде прописать список полей с типами.

Miguel ★★★★★
()

тупо выбирай через поиск гитхаба, то что больше всего звезд имеет. Это идеальная стратегия. JSON-схема давно используется в Swagger и иже си. В MongoDB коллецкциям можно схему задать, в приницпе удобно все кроме регулярок. Регулярки конченные. Нет флагов, а значит гуано полное выходит.

tz4678 ★★
()
Ответ на: комментарий от tz4678

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

Не идеальная. Это либо челу повезло с раскруткой, либо не малая часть усилий была вложена в продвижение (в ущерб остальному), и как вариант это продукт медийной личности или известной компании. В действительности это мало говорит о качестве продукта, но легко попасть в эту ловушку (типа если много звёзд значит востребовано и проверено — что работает только отчасти — иначе говоря миллионы мух не могут ошибаться, да?).

EvilFox ★★
()
Ответ на: комментарий от EvilFox

С Flask, Vue и т.п. я не ошибался. Мухи не ошибаются. И вообще замени мух на пчел в заезжанной фразе и смысл измениться кардинально.

tz4678 ★★
()
Ответ на: комментарий от EvilFox

Да это еще ладно

Закончил читать гайды по синтаксису и кодированию protobuf и расстроился. Слишком вольные правила декодирования. У всех полей есть дефолтные значения, соответствующие их типу (0, false, пустая строка, итд). Неизвестные поля игнорируются. Выходит, что декодер cможет взять почти любой мусор из байт, предположить, что это неизвестные поля, проигнорить их и гордо выдать структуру, заполненную дефолтными значениями по схеме

Стыд. Схема одна лишь видимость. Валидация — пустой звук

Deleted
()
Последнее исправление: Deleted (всего исправлений: 4)
Ответ на: комментарий от crutch_master

Ага. Миллионы професионалов за десятилетия делали одно лишь говно, а я щас на коленке сделаю костыль, который перевернет игру

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Миллионы професионалов за десятилетия делали одно лишь говно

Ты преувеличиваешь полезность жс хипсторов. Всё очень молодое и сырое.

crutch_master ★★★★★
()
Ответ на: комментарий от Deleted

Протобаф тоже молодое и сырое?

Протобаф тебе не нравится же. Что тебе не нравятся велосипеды? Они быстро делаются и сносно ездят.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Что значит «не нравится». Я описал опасения, появившиеся после прочтения гайдов. С у четом того, что, как правильно сказал Царь, нет спецификации для RPC, протобаф выглядит паршивенько

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Смотри, есть такая штука - pdfmake. Он из декларативной схемы делает pdf. Но делает его ~секунду, хотя рендерится сам документ 50мс на pdfkit (что тоже много, но всё же). Что плохого в своём велоpdfmake на том же самом pdfkit? Да у него не будет столько возможностей, но у меня и времени столько нет и задачи не стоит реализовать всё. Для платёжки я смогу что надо реализовать за недельку, а другого ничего мне не надо. И этот велик будет прекрасно ездить и делать что он него хотят без сюрпризов. Так что в этом плохого?

crutch_master ★★★★★
()

У меня на серверной стороне Java (и, соответственно, Jackson), который подразумевает строгую типизацию и конкретный перечень полей - это чтобы «полная херня» не пролезла.

А с точки зрения содержимого - валидация в самих методах - что передали с клиента. Клиенту (веб или толстому) доверия нет никогда. Валидацию в виде схем никогда не использовал (хотя и посматривал на json-schema когда-то очень давно - когда была v4 и драфт v5 ЕМНИП).

Qasta
()

Чем вы пользуетесь для валидации JSON-а?

Ничем, я как нормальный человек не использую жсон там где нужна валидация данных по схеме.

Как крайний вариант - валидация модели после раскладки в неё данных.

ya-betmen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.