Replies: 1 comment 1 reply
-
You mean |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
In our project https://github.com/SeaQL/seaography we depend heavily on
async_graphql
dynamic schema. In our latest task we try to implement a solution to the N+1 problem and optimize the dynamic related queries. During the planing on how to modify the code we came with a bunch solutions and a few questions we would like to discuss with you. In the following sections we will lay down the current situation and present the solutions we came up and the issues we encountered.The situation now
At the project you can find a ready to compile sqlite example.
In this example you can run the following query
And it will execute the following SQL statements
Ideal case
The ideal case would be to have the following sql queries
or even better
Solution A: Dataloader
Skimming through the provided examples and the documentation of
async_graphql
we found out about the dataloader. At first glance it looks promising but because we have filters and ordering on the fields of the related query things do not work so well because dataloaders accept a key value only (ref: https://docs.rs/async-graphql/latest/async_graphql/dataloader/). Despite this limitation we came with the following solutionFor the filtering we utilize the SQL capabilities, and for ordering we rely on rust algorithms implementation. This is the solution we will work, it is good enough but we think that we can do better. The advantages is that is easy to implement, has good enough performance and utilizes most of SQL capabilities. The downside is that it does not feel natural.
Option B: Look Ahead + Caching
By utilizing the look ahead API we can construct the desired query and cache it. This can be done either in a custom intermediate object that maps to the regular object using the magic of dynamic objects or through a caching service that is stored in the context object of the
async_graphql
server.This can be done in the following file:
https://github.com/SeaQL/seaography/blob/main/src/query/entity_query_field.rs#L119
This solution is the most ideal regarding the performance and it feels right, but requires some rewrites from our side and it will look complicated.
Sources:
https://docs.rs/async-graphql/latest/async_graphql/struct.Lookahead.html
Option C: Child Look Reverse
Disclaimer: This is not possible with the current API of
async_graphql
(August 2023), please correct me if I am wrong.There is a way to get the parent of a child https://docs.rs/async-graphql/latest/async_graphql/dynamic/struct.FieldValue.html#method.with_type
The idea is to get the parent of the parent. in our case an array of the result customers and then construct the desired query.
This solution also looks ideal, and requires less effort from our side. But requires a new feature in the
async_graphql
which I am willing to implement if it is possible.Time for discussion
async_graphql
?Thanks for your time.
Beta Was this translation helpful? Give feedback.
All reactions