Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate how Gateway performs GraphQL query normalization #40

Open
tkornuta-semiotic opened this issue Jan 9, 2023 · 7 comments
Open
Assignees

Comments

@tkornuta-semiotic
Copy link
Collaborator

No description provided.

@tkornuta-semiotic tkornuta-semiotic changed the title Investigate how Gateway performs normalization Investigate how Gateway performs GraphQL query normalization Jan 9, 2023
@tkornuta-semiotic
Copy link
Collaborator Author

@aasseman can you please point @tumaysem to the AutoAgora processor code that does normalization "our way"?

@tumaysem
Copy link
Contributor

After some gateway code investigation. queries are matched against agora models with CostModel.cost_with_context method which maps to agora library. I found a good unit test to investigate further.
https://github.com/graphprotocol/agora/blob/bbe0c3c5882eb8685697f4615e285572706bde88/lang/src/tests.rs#L69

@tumaysem
Copy link
Contributor

If we assume query { a(skip: 10), b(bob: 5) } has two separate top fields as a and b. For each top field and predicate in the model, match_field is executed.

1- Matches top field names with predicate name
2- Check top field is not excluded due to query directives skip:if true or include:false
3- Matches predicate argument vs query variable names and values
4- Matches selection fields. This is checked recursively and some graphQL structures such as fragments.

For each top field first matched cost is aggregated to calculate the total cost.

@tumaysem
Copy link
Contributor

We should be using directly agora library because the code complexity and heavy graphQL language dependent match is prone to frequent changes. Thus required a patch to model providing a more detailed cost result with the matched predicates.

@tumaysem
Copy link
Contributor

After wrapping the agora and extend it to provide cost details, I have come to a conclusion that current processing of queries inside agora cost models is fully heuristic and without any normalization similar to semiotic-ai gql utils.
🔖 Cost details leads to a new idea. Gateway can provide list of tuples containing hash of selected cost model branch (top field in agora lang.) and cost to indexers with query instead of aggregated cost as price. Thus enables indexers to validate both provided price for a query (model validation) and payment verification (@aasseman) .

@tkornuta-semiotic
Copy link
Collaborator Author

should we try to upstream AutoAgora processing/normalization to the Gateway?

@aasseman
Copy link
Contributor

aasseman commented Mar 8, 2023

should we try to upstream AutoAgora processing/normalization to the Gateway?

We can't upstream the Python code as Agora is in Rust. However @tumaysem is working on documenting (upstream issue) the disparities between how Agora compares queries, and how graph-node actually manipulates the GQL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants