Decide on the best JS object validation library

[tmeasday]

We suspect it's simple schema. If so, we should work with @aldeed to get it (the non-meteoric parts anyway) on NPM, and promote it as a cool thing that's come from the Meteor community.

One thing that @timbotnik and I noticed about it: it seems slower than it needs to be. Perhaps there are some simple optimizations that can be made?

TODO items

1. Browse around for alternate validation libs
   • http://mongoosejs.com/docs/guide.html
     • OK, but not super expressive once you get beyond the basics
   • https://github.com/molnarg/js-schema
     • seems sort of experimental, no explicit support for subobjects
   • Some others that don't particularly seem worth mentioning
2. Investigate speedups
3. Consider replacing check / audit-argument-checks with it.

[aldeed]

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.

[tmeasday]

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.

[tmeasday]

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.

[vladshcherbin]

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

[tmeasday]

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?

[vladshcherbin]

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.

[aldeed]

@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.

[tmeasday]

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

[tmeasday]

@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 :)

[tmeasday]

Move this conversation to SS, and close this one