option to speed up performance by disabling validation

[zsolt-dev]

Feature requests

I am sure by now everyone interested in graphql servers for node saw this:
https://github.com/benawad/node-graphql-benchmarks

I myself noticed slow performance of apollo server in the past and spent couple of days investigating just to find out that the slowness is not in my resolvers but in apollo/graphql itself.

I would like to propose an option that would disable some validation and type safety to get somewhere near the performance of REST apis.

Lets prefix it this option with UNSAFE_ or something similar, but there are many use cases that need the performance.

Any ideas?

[tomasAlabes]

Implemented and disappeared: #839

[geiszla]

I would still be interested in an option like this (and looking at the likes on the OP, I believe many others feel the same). If it was already implemented, would there be an easy way to bring the option back?

[glasser]

Apollo Server caches validation successes (the 'documentStore' which caches parsed ASTs is only populated if validation passes, and if the cache has an AST it doesn't re-run validation). It seems like the only case where disabling validation would be where there's only a very restricted and known-safe set of validations allowed by your server — but in that case, surely the caching would be good enough?

Running invalid operations can lead to all sorts of undefined and insecure behavior. I'd like to see compelling benchmarks and descriptions of real-world situations where it feels safe enough to disable validation but where doing so actually provides realistic speedups.

Perhaps we should document the caching somewhere more discoverable?

[geiszla]

@glasser What about the above-mentioned benchmarks? Surely, a 2-3 times speedup is worth it especially if one can validate data from the db (e.g., with Mongoose), then just use TS to keep data valid between the client and the server. Not as safe as an online validation, but could be enough in some cases where efficiency/performance is more important than ensuring full data integrity. What do you think?

[glasser]

There are a lot of benchmarks there. Can you show me which one indicates that "validation" is the cause of performance issues?

Note that I assume you mean the validation phase of GraphQL operation processing when you say "validation" — ie, the phase that says "is this operation legal with respect to this schema". If there's some other kind of validation you're referring to, that might be a different question!

[geiszla]

Can you show me which one indicates that "validation" is the cause of performance issues?

I haven't investigated myself in detail, so I just inferred from the original description of the issue that the slowdown had to do stgh with the validation. Is there a different reason other, "lightweight", solutions are so much faster?

[glasser]

I don't think it makes sense to guess here, vs profiling or experimenting with taking different pieces out.