tailcall
tailcall copied to clipboard
Pass `operations` to `check` command
Problem As a user I wish to validate the generated graphql schema with a set of graphQL queries.
Solution 1 Since #438 we now support loading multiple graphQL files. Which means that we can pass the queries as a part of the configurations more easily. We should just validate the queries that are in the graphQL files without and special check parameter.
The command would look a lot simpler now:
tc check ./jsonplaceholder.graphql query1.graphql query2.graphql
All the above options should be allowed to test the graphQL schema against the provided queries and mutations.
Solution 2 We will extend the check command on the CLI to support checking of the schema against provided queries and mutations:
# using operation parameter
tc check ./jsonplaceholder.graphql --operation query1.graphql --operation mutation1.graphql
# using comma as a delimiter
tc check ./jsonplaceholder.graphql --operation file1.graphql,file2.graphql
# using space as a delimeter
tc check ./jsonplaceholder.graphql --operation file1.graphql file2.graphql
All the above options should be allowed to test the graphQL schema against the provided queries and mutations.
Technical Requirements
- Use
ValidationError
to capture and display all the errors. - Errors should be composed with errors
from_config
.
/bounty 180$
💎 $180 bounty created by tailcallhq
🙋 If you'd like to work on this issue, comment below to get assigned
👉 To claim this bounty, submit a pull request that includes the text /claim #416
somewhere in its body
📝 Before proceeding, please make sure you can receive payouts in your country. 💵 Payment arrives in your account 2-5 days after the bounty is rewarded. 💯 You keep 100% of the bounty award. 👍 If you go above and beyond by cleaning up or enhancing aspects beyond the scope of the PR, a tip may be awarded as a token of appreciation. 🙏 Thank you for contributing to tailcallhq/tailcall!. 🙋♂️ Join our discord channel if you need help.
@tusharmath can you explain a bit more on what you're thinking about validation? do we need to compare the the generated schema with the provided operations? or is there any existing implementation which can easily accepts graphql query to perform operation?
We need to check if the schema is compatible with an existing set of queries. Meaning - can I run those queries on the generated schema.
One issue, though, is that the Config::from_file_paths
does not load queries.
I've tried query QueryName {
, query {
, and only {
.
I'm seeing this error:
Would you happen to have any suggestions on how to handle queries @tusharmath?
Likely, we'll need to handle the queries differently than we do with the configs. Because of that, I recommend that we keep the initial idea of having a flag, but rather than operations
, we could use queries
, so the usage would be tc check ./jsonplaceholder.graphql --queries query1.graphql query2.graphql
.
We can also add the handling on Config::from_file_paths
, but I fear we'll overload this method. Please let me know what you think about this.
/attempt #416
Options
Note: The user @b4s36t4 is already attempting to complete issue #416 and claim the bounty. If you attempt to complete the same issue, there is a chance that @b4s36t4 will complete the issue first, and be awarded the bounty. We recommend discussing with @b4s36t4 and potentially collaborating on the same solution versus creating an alternate solution.
@ologbonowiwi, Ah! I think this is problem with the parser unfortunately. We are just parsing the file here and validating it syntactically. Because it doesn't support queries right now, it would be better to just pass them as separate files, like it was in the original proposal.
We should call it operations
and not queries because operations includes both queries and mutations.
I will revert the issue to it's previous state 🙈
Thanks for pointing this out 🙏
Updated the issue with Solution 1 and Solution 2 :)
Hey @tusharmath, I'm back to working on this one.
Where did you plan to parse the operations?
I was thinking about add
let operations = Operation::from_file_paths(operations.iter()).await?;
and then find a way to check the operations against the configs.
Some questions:
- should I create an
operation.rs
to handle operations logic or do it underconfig.rs
? - where should we validate it? after, before the
display_details(&config, blueprint, &n_plus_one_queries, &schema)?;
call, or before the blueprint check?
operations
could be part of config::GraphQL {operations: Vec<Operation>}
, then we could perform a validation in the blueprint.
Can you help me write tests for this issue, @tusharmath?
I'll start with the test, so it'll make easier to review and ensure the behavior
imho it'd be easier to start this from tests, but after careful consideration, I'll not be able to handle this.
Anyone that wants to give it a shot, feel free to take up the bounty 🚀
Hi 👋 @tusharmath. Can I give this a try ?
@tobihans Sure!
@tobihans @tusharmath Is this still available?
I'm working on it @Shylock-Hg. Thanks
Hey @tobihans, if you need help with it, let me know.
I added myself to the queue as I have looked at it in the past, and now I have availability again :smile:
PS: I'll not start to work on it as there are already other people working on it :smile:
Thank you @ologbonowiwi. Yes, I've been working on it slowly 🐌. Currently, at the query parsing stage. Once I submit the draft, you'll be able to review and suggest. Thank you very much 😊.
That's cool @tobihans! Why don't you create a draft PR that @ologbonowiwi can help you with?
Hi @tusharmath @ologbonowiwi, I just pushed the draft. I shifted from the original idea to parse the query after reading more about the async_graphql
crate and looking into the codebase. The code is not that clean for now too, please bear with me. I'll fix it. Thanks
💡 @tobihans submitted a pull request that claims the bounty. You can visit your bounty board to reward.