You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parsing a query and validating a query on every request adds performance overhead. It also prevents validation errors from being discovered until request time, rather than when the query is parsed at startup.
Building runtime GraphQL query strings with user input may lead to security issues. Always using a static query along with variables is a best practice.
This means well, however it forces a certain implementation on the caller that is very un-ruby and cumbersome to manage. It forces the client to keep a static around forever whereas that might not be what the client wants. It requires a client to reload if the schema changed, for example or lead to hard to debug scenarios.
We should be able to define a client, parse a query, then execute it separately, achieving both (1) and (2) without imposing this. I would vote to make allow_dynamic_queries true by default and better document the tradeoffs rather than impose a certain style even if it's for the greater good.
Finally, having gone through the experience of a first time Ruby GraphQL client call I was surprised that I can't just make a query. Creating a module, parsing a query and executing a query are much more complicated compared to just making a query with all its values because this requires understanding of GraphQL parameters. Compare:
Coming from ashkan18/graphlient#24.
Currently graphql-client forces you to declare static module variables in the name of security and optimization. It makes two good arguments in https://github.com/github/graphql-client/blob/master/guides/dynamic-query-error.md:
Parsing a query and validating a query on every request adds performance overhead. It also prevents validation errors from being discovered until request time, rather than when the query is parsed at startup.
Building runtime GraphQL query strings with user input may lead to security issues. Always using a static query along with variables is a best practice.
This means well, however it forces a certain implementation on the caller that is very un-ruby and cumbersome to manage. It forces the client to keep a static around forever whereas that might not be what the client wants. It requires a client to reload if the schema changed, for example or lead to hard to debug scenarios.
We should be able to define a client, parse a query, then execute it separately, achieving both (1) and (2) without imposing this. I would vote to make
allow_dynamic_queries
true by default and better document the tradeoffs rather than impose a certain style even if it's for the greater good.Finally, having gone through the experience of a first time Ruby GraphQL client call I was surprised that I can't just make a query. Creating a module, parsing a query and executing a query are much more complicated compared to just making a query with all its values because this requires understanding of GraphQL parameters. Compare:
to
It gets much hairier with complex types or mutations. We want this library to become more friendly to beginners.
The text was updated successfully, but these errors were encountered: