DocumentValidator bottleneck

[enumag]

I'm profiling my application using Blackfire. Right now around 25% of the time to response is consumed by \GraphQL\Validator\DocumentValidator::validate(). This is quite a lot. I need some way to either significantly reduce the validation time or to cache the result for the same requests in the future to avoid running the validation again.

I don't think reducing the validation time is possible - or not by much. Caching the result should be possible but from the code this doesn't seem to be supported at the moment. Can you give me some advice how to implement it?

It's not necessary to cache the result of a request with errors, those will be rare and can be slow. No need to fill the cache. But normal successful requests need to be as fast as possible and this slows them down significantly.

[vladar]

You can implement caching logic in your app.

If you know that the query is valid just pass an empty array of validation rules.

For the Standard Server:
See validationRules option.

For the GraphQL::executeQuery facade method:
Pass a custom set of validation rules in the last argument.

There is also an entry in doc which is not directly related, but which may be useful: http://webonyx.github.io/graphql-php/executing-queries/#custom-validation-rules

In general, the most performant solution is to use persisted queries. With a standard server, you can enable them by setting persistentQueryLoader option and setting validationRules option as a callable (see docs for clarifications).

The idea of persisted queries is that you save your queries somehow on the server and get queryId which you later use on the client instead of query. Then on the server, you store cached AST of the query and disable validation. This way you bypass both parsing and validation steps of a query.

[enumag]

This looks promising. I'll try it next week and post here what I end up with. Thank you!

[vladar]

Cool, feel free to re-open if needed.

[vladar]

You want to use version v0.11.6 (just released) as it has some performance improvements for the case with an empty list of validation rules.

[enumag]

Can you tell me how the persisted queries work? Even with this article I don't understand how the client is supposed to send an id instead of a query. What syntax should I use for testing it with GraphiQL?

Btw. I can't reopen this issue since you're the one who closed it instead of me.

[vladar]

GraphiQL doesn't support this as far as I know.

Usually persisted queries require build step for the client-side code. In a development environment you use full queries but during a build step, you submit all client queries to the server and server returns you an ID for each query.

Then you use this id in production instead of a query string. Obviously, client code must be written in a way where you can replace a query with an id.

The process of saving queries is not implemented by the StandardServer. It has to be done separately by your app. Server supposedly parses and validates the query once during saving, and then just uses cached AST for later requests.

So back to this lib... When the StandardServer sees documentId (or queryId as an alias) in the request, it attempts to load the query AST (using persistentQueryLoader). Obviously parsing is skipped in this case, but validation is not skipped by default (yet you can adjust the list of rules yourself via validationRules callback).

For example, following JSON request will trigger persistent query logic:

{
    "documentId": "some-server-generated-id",
    "variables": {
        "myVariable": "test"
    }
}

Just to recap, persisted queries usually require:

1. An endpoint for query saving (and getting back an id)
2. A build step for your client-side code
3. Client-side code is written in a way that supports replacing query with it's id
4. A server capable to execute queries saved by the endpoint (point 1)

This lib only provides you 4.