Performance issues for backend use
See original GitHub issueHi.
I love the API of yup, and I love it SO much that I’m trying to build an isomorphic application that uses the same yup schema validation in both the frontend and the backend 🚀.
However, at the moment it’s not really viable simply due to the fact that it’s about one order of magnitude slower than it should be, considering what is actually running in the source code (“joi-lite”). I really don’t expect ajv
levels of “extreme” performance since yup
is not compiling schemas, but I’d expect to at least be somewhere around joi
’s level.
First, the setup: https://github.com/JaneJeon/validator-benchmark (I forked https://github.com/icebob/validator-benchmark, updated the dependencies, added strict mode to the yup schema, and properly ran the async validator - I tested synchronous version, and it was literally 2x slower xP)
And, the results (run node .
):
https://i.imgur.com/AuQLnTD.png
At first, I thought it was because the email/url regex yup was using was ungodly (no offense), so I thought maybe using simplified regex (like here: https://github.com/icebob/fastest-validator/blob/master/lib/rules/email.js) might help.
It didn’t.
I changed the regex in both lib/string.js
, es/string.js
in node_modules/
and it didn’t affect the performance in any noticeable way.
I messed around with sync vs. async, different ways of running the validation, etc.
Then I realized there’s babel’s crufty code all over the place, in both es/
and lib/
. I dug around and found that babel-compiled code often has performance issues, especially regarding ES6 syntaxes.
I suspect that the default babel compilation is what’s slowing down your codebase significantly since, as far as I can tell, you’re only using babel for ESM syntax.
Is there any way you could directly expose the ESM code or at least use a much more efficient compiler/babel setting? People running this in node/backend just need to convert ESM -> CJS. I feel like babel config is key here.
I’d really love to use this in my backend and bring it to production! This is the last thing that’s preventing me.
Thanks
Issue Analytics
- State:
- Created 3 years ago
- Reactions:4
- Comments:28 (11 by maintainers)
Top GitHub Comments
gonna try and get something out soon
not sure what i’m supposed to do with a context-less benchmark @Timer
Gonna guess that you are just running the benchmark from above with the newest version. It’s not an apples to apples comparision, run it while using
isValidSync
and you getThis is pretty close to joi, and i’m happy enough with the result. If anyone wants to save off more time please feel free to send a PR