Decide on the best JS object validation library about guide HOT 10 CLOSED

The validation code flow is pretty crazy because it validates modifiers. For non-modifier objects, a different and much faster flow could be used.

But yes, moving it to a pure node npm package has been my goal for some time now. Other than some code that auto-sets the userId for validate functions, I don't think there is anything Meteor-specific. The MongoObject files should be their own npm package, too.

from guide.

Yeah. I mean I think for actual usage it's totally fine, it's in tests where you are maybe creating and validating thousands of documents where >1ms validation times start to hurt you. Sounds like we can probably make it totally fast enough very easily which is good news.

from guide.

OK, I had a look around for other stuff. TBH it was always a bit of a stacked deck because of SS's support for checking modifiers, which a generic JS lib is not going to do.

Probably the only other option would be Mongoose's schemas. Mongoose is pretty popular (7k stars on GH), but it doesn't really work from an modifier model (you make changes to the doc, then hit .save()).

So I'm pretty comfortable that SS is the best fit for Meteor.

from guide.

@tmeasday Have you checked Astronomy (atm.link) as an option, what can you say about it?

from guide.

Hey @vladshcherbin. I think we discussed it at some length already here: #10

If you mean specifically as a schema library, my impression of it is that it's much less expressive than SS once you get away from the simpler use cases.

Personally I think it would be better if Astronomy just used the same schema format as SS. I'm not sure exactly why it doesn't (given SS is pretty good, IMO, and already existed when Astronomy was created). Perhaps @jagi can weigh in on why he made that decision?

from guide.

Hey, @tmeasday . All I just wanted to say - for some people the switch may be very hard after reading huge docs. I believe in Astronomy as I believed in the Flow Router from the first versions. I do think it is better for non-novices and it will be much more popular in the future.

from guide.

@tmeasday As far as schema formats, JSONSchema is pretty popular now. @Yodata (@bshamblen) has a package that can convert JSONSchema to a SimpleSchema. This is useful because (1) JSONSchema can be stored in a database and (2) JSONSchema can be shared with other frameworks or languages that understand it like Rails, Go, etc. On the other hand, functions and other SS icing can't be used.

from guide.

Interesting, thanks @aldeed. That's really cool. I think we should definitely mention it in the collections chapter anyway.

from guide.

@aldeed - FYI we did a tiny bit of profiling, as a data point:

This schema

new SimpleSchema({a: {type: String}, b: {type: String}, c: {type: String}})

Takes ~2.5s to validate 10k documents of the form {a: 'a', b: 'b', c: 'c'}.

If I add a label to each field definition (to bypass the call to S.humanize()), that time drops to ~325ms.

That's one obvious spot for optimization :)

from guide.

Move this conversation to SS, and close this one

from guide.