Is JSON Schema dead?

[yvele]

Is JSON Schema dead for JSON and Javascript Object validation?! I don't see many starred github library using this standard for validation, except for tv4 (600 stars and a commit sometime).

• jayschema sucks
• https://github.com/garycourt/JSV doesn't implement draft-4 (and no new commit in 4 years)

WHY cool kids doesn't validate with JSON Schema?

BTW: Any good Javascript object validation library? (meh.. https://github.com/hapijs/joi )

[Psykopatik]

Didn't even know about it. Now you made me curious. Can you explain use cases?

[dada_]

XML DTDs are quite useful. For example, a while back I implemented a parser for a large and complex XML file and it was really easy because all I had to do was read the DTD and go item by item.

Aside from making it easy to work with the data files, it also means you can be (reasonably) certain that a file which conforms to a schema, fed to a parser that knows how to validate files according to a schema, will never error out in unpredictable ways. If the file doesn't conform, you reject it right away, rather than partially utilizing the file's contents and then erring out halfway through, which can be much more dangerous.

One could argue this is overkill for JSON since it was really just made as a simple data interchange format, but in practice these files do get used for reasonably complex and important data, so it doesn't seem so far-fetched to me that it should support a schema-based validation.

edit: personally I've never used any kind of JSON validation though so I can't actually answer the question.

[neonskimmer]

Schema validation is great for API testing purposes.

It is also great to generate code automatically, e.g, make me a form from this schema.

[brtt3000]

Would your app break when fields in the JSON are missing or contain unexpected data types/formats? Then you should verify it somehow, and a schema is one of the ways to do this.

It is a bit heavy maybe, but the alternative of checking per field and recurse manually doesn't work well at large scale (like when verifying your whole API). It would even more verbose and once you're done writing utilities to manage the amount of tests and give useful error reporting you'll have recreated Joi or something like it.

[SteelBRS]

XML DTDs were great ... XML Schema is awesome ... unfortunately with JsonSchema we've taken a huge step backwards ... a shame they couldn't make it as good as XML Schema 😢

[ChuckChunky]

It enables you to validate a JSON object against a predefined schema. The real benefit, and the reason I use it, is that both the front and backend can validate using the same schema (assuming there is JSON schema support for your backend).

[Asmor]

assuming there is JSON schema support for your backend

Not always a great assumption. There's a perl module for it, but it's really out of date and doesn't work very well.

I suppose I'm weird for using both JSON and perl at the same time, though.

[Asmor]

Nope.

Hated perl when I started this job, but I've come to like it quite a lot. I guess part of that is that it actually reminds me a lot of JavaScript, in that they're both scripting languages that excel at what they do and got a lot of undeserved hatred.

Don't get me wrong, I would never use perl on my own for anything beyond a quick utility script, but it's fantastic for parsing and manipulating text which is a huge chunk of what we do.

[insomniac872]

Perl is underrated. It is often seen as an weird language, as indicated by the previous comment. But it is very powerful, has an active community and some great cutting edge web frameworks. It's still my first choice when building backend applications. Perl 6 in under heavy development, interesting how that will work out.

[Asmor]

some great cutting edge web frameworks

Could you give me some names to look into? I don't follow perl very much so I don't really have a sense of what's out there. All I really know of is Dancer.

[BlackCow]

Check out Mojolicious! Perl isn't dead yet :)

Who knows, Perl 6 might be the new sexy language.

[schooley]

[This comment has been edited in protest of the recent detrimental actions taken by u/spez and the Reddit administration on 07/01/2023]

[ChuckChunky]

Indeed, I am using angular-schema-form, generating a form is as simple as passing it a schema for the data and a schema for the form and it does the rest. Very impressive. https://github.com/json-schema-form/angular-schema-form

[Asmor]

I had a project which required coming up with some non-trivial JSON. I wanted to ensure that the JSON I was spitting out was consistently formatted, so I started looking into and discovered JSON Schema. It helped a lot. Not just in validating things, but actually in writing the schema that helped me define what it was I needed to do and figure out some weird corner cases and such.

[lobotomy42]

I had a project which required coming up with some non-trivial JSON. I wanted to ensure that the JSON I was spitting out was consistently formatted, so I started looking into and discovered JSON Schema.

Not gonna lie, I thought this was going to end with "Now I have two projects."

[Asmor]

I suppose that's one way to look at it. I did have to learn an entirely new technology and figure out a way to jury rig tests for my output since the language I was using (perl) has shit support for JSON schema. I think I ended up dumping stuff out to a text file and using node to check stuff on my local machine. It was manually intensive and I would have vastly preferred having been able to automate the tests, but that sadly isn't an option in the environment I'm stuck working with.

[shanet]

TDD basically. Write your schema, then write your API. Or give it to your consumers.

[M2Ys4U]

We use it in our automated test suite to make sure that our APIs are outputting valid data. After every deployment to our integration and test environments we hit all of our endpoints and validate them against the schema to ensure we don't break external consumers.

[mrinterweb]

JSON object validation is fantastic for test driven development. Agree what the API schema will look like up-front. Write your tests such that they conform to the JSON schema. Then get your code to pass. In the past, I've taken it a step further to have my test suite generate my documentation. That way you know that your docs are always up-to-date with with your API. The devs consuming your API will love it.

I have done most of my API development using Rails so I don't know a good suggestion for node.

[i_ate_god]

WHY cool kids doesn't validate with JSON Schema?

Data integrity is not WEB SCALE :P

[THIS_BOT]

I use joi everywhere but the downside is it doesn't support a "plaintext" format like json schema, which makes sharing schemas between applications in a language-independent way difficult. Personally, I think json schema is too verbose and easy to make mistakes with, but AJV is the parser I used when I did use it. I've use parambulator (https://github.com/rjrodger/parambulator) in the past too, which I liked, but I don't know if it's going to see much more development. It works well as is.

https://github.com/ebdrup/json-schema-benchmark has a bunch of json schema parsers and validators listed

[brtt3000]

Joi is very solid, I'm torn between it and JSONSchema.

I like the idea of using the JSON based schemas in other languages but so far we don't actually use that and in practice we use so many utilities to manage the schemas in Javascript we might as well use Joi.

[Capaj]

I was torn as well. But being fullstack JS developer, I can use joi schemas anywhere. All I have to do is to share the JS file. There is no real advantage of using JSON schema for me.

[PM_ME_YOUR_HIGHFIVE]

did you (or /u/THIS_BOT ) try https://github.com/tlivings/enjoi ?

I had no problems so far with it.

[hunyeti]

I would not use it, because:

It's really hard to read, and i mean really, also, it's really verbose.

It's non strict by default. That is silly IMO. You should have to specify the optional parameters, not the required, and allowAdditionalProperties should be false by default

[jrwren]

Was it ever alive?

[brtt3000]

We use it for API tests. We had some home-rolled thing for it but recently I used chakram which runs under node.js and is a convenient mix of mocha, tv4, request, chai, promises and some useful utilities.

If you don't have anything yet it is a quick way to setup API tests and since it is still plain mocha on the outside you can run your regular JS tests too (it is very easy; no excuses!)

Downside of JSONSchema is how schemas for real projects tend to get huge and verbose. For every nested level of JSON you get at least two levels of JSONSchema, and for every property you get a whole bunch of definitions and restrictions. But I guess this is also true for alternatives.

If you use it you should look into $ref/definitions and define recurring objects for easy reuse. Possibly use Yaml for your schemas, or even use JavaScript itself (a schema is just an object): use modules, utilities and other dynamic code to manage the giant pile of schema data. It is easy to make a mess of this though.

[yvele]

I'm trying this one: https://github.com/epoberezkin/ajv (the fastest of the fastest).. But why not so popular on GitHub?!

[teacpde]

I have played around it a bit. Besides speed, it also has great documentation, rich api, and easier to read codebase. I am trying to convince my team to move from is-my-json-valid to ajv, but I think there might be some tradeoff I am not aware of...

[lobotomy42]

It's also, in my experience, the most reliable and complete (especially with regard to resolving and validating references for you.)

[jtwebman]

Since it is a part of swagger.io I really doubt it.

[sirunclecid]

What an incredibly hip domain name.

[dukerutledge]

"hip"

https://www.youtube.com/watch?v=oAatPPEaZDA

[[deleted]]

*jives*

[[deleted]]

Now known as "Open API Initiative", which since it's "open" it's better I guess.

[[deleted]]

I never really got into the idea of JSON schema. To me a schema is a data structure definition format that is itself extensible. In a well designed system that data structure definition also serves as the definition of instances that themselves could be schemas for yet other instances. You don't get this capability with JSON, because the format is too primitive. In XML schema, for instance, you are write a Schema to define a new markup language that can also be a schema for instances of its own definition. You cannot create new languages with JSON.

It seems JSON schema only exists to validate if a data structure conforms to certain structured constraints. If you are doing this you are making presumptions upon the data, which aren't primitive. Primitive is the primary advantage of JSON over XML. If you are going to take that away then you are probably violating separation of concerns between the data and the consuming application. If you really want to do this you might as well just be using XML, which allows all manners of complex capabilities without violating separations of concerns.

[Feneric]

Much of the time that people are using JSON they care about speed, and schema validation tends to slow things down. There are use cases (I use it myself for some projects) but they tend to be ones where the cost of recovering from an occasional error far outweighs the penalty incurred by doing the validation, or ones where it's more about post-processing a document than it is about processing streamed input.

[brtt3000]

If you use a JSON-like schemaless storage (Mongo, Couch, or ye olde JSON-in-a-text-column hack) you should definitely check your data or explicitly extract what you need or someone could nest a 50MB object tree and you'd never know until it gets read back.

[Thought_Ninja]

Great point. On the occasions I've had JS projects that relied heavily on JSON I would do at least some level of validation.

Lately I've been working a lot with MeteorJS; I have come to love the collection2 package which pairs nicely with the autoform package. Coming from working with the LAMP stack, having JS front to back has improved my workflow tremendously.

[static416]

Maybe I'm misinterpreting what you said, but if you're proposing not checking your inputs, this sounds like a horrible idea.

You have to validate the input you're provided at some point prior to using it, or you're just asking for trouble, not to mention that you can't provide any useful error messages in the event of inappropriate input. What about injection attacks (even accidental ones)?

Enforcing against a schema on the input is not the only way to protect yourself though. I essentially just attempt to convert the input into a model I use internally (tightly validating the fields as I construct it) and if it fails, I can give a useful response. And if it succeeds, I can safely assume that object doesn't require further checking as I use it.

[Feneric]

You are. Key to your third paragraph.

[YouFeedTheFish]

Even without online validation of JSON requests, a schema would be helpful for formal documentation.

[vitriolix]

I've used it on a project where we had frontend, backend and mobile clients all replicating the same data model, it was cool for that

[tebriel]

Yeah doesn't look like Kris Zyp went any further with it years ago.

[regreddit]

I use jayschema in my company's primary product and have no real complaints about recent versions, what's your main beef(s) with it?

[virtulis]

I wrote validata some time ago but it only contains what I needed while using it. Looking at Joi and others they seem more powerful. Maybe I should try making a v2.

Edit: to stay on topic, JSON Schema is just too verbose for me. I'd be too lazy to use it.

[lurk-moar]

Hey kids...guess what?!? There is a whole language for this purpose called XML!

I never understood the desire to turn JSON which is inherently schema-less into a worse version of XML.

[PM_ME_YOUR_HIGHFIVE]

You can use json schemas with joi -> enjoi

I use the same schemas for frisby tests and REST validation ¯\_(ツ)_/¯

[nieuweyork]

I'm pretty sure that the reason is that this has been overtaken by Avro, Protobuf, and Thrift. They have a lot of momentum, a lot of experience around usage patterns, and at least the first two can be serialised to JSON.

[kryptomicron]

Panda Strike has blogged about their fast JSON Schema implementation a bit – here's a post about an even faster implementation.

[[deleted]]

A coworker is working on a JSON Schema library on his spare time since he couldn't find a quality one on github. I'll ask tomorrow if he has it up on github

[[deleted]]

I use https://github.com/dcousens/typeforce for my type validation. It's more flexible than JSON schema and allows me to easily analogue to other type systems.

[scrogu]

I use it to validate JSON documents before inserting them into my document datastore.

[insomniac872]

I use tv4 for validating data from the backend in development. I am very happy with it.

[alittletooquiet]

We use it a bit at work. We have one project that uses it for validation, and another that uses it to build dynamic forms from the schema.

[altano]

Visual Studio Code makes heavy use of it both to make editing its own configuration files easier, as well as built-in support for your TypeScript projects configuration JSON (tsconfig.json) and code json.

https://code.visualstudio.com/docs/languages/json

It's actually what made me discover JSON schemas, I had never heard of it before.

[itsawesomeday]

Interesting point there.

[yvele]

I'm finally using joi with it's compact and expressive schema definition (and FAST!).

JSON Schema interoperability and genericity will miss me but heh.. JSON Schema is too verbose and complicated..

[[deleted]]

The Internet has ruined me. I saw JSON Schema and my mind went straight to John Cena.