FormidableLabs / FormidableLabs/groqd
GROQD params are nested, which cause very slow query times.
- Dominant language
- TypeScript
- Stars
- 293
- Forks
- 15
- PR merge metrics
- No merged PRs in 30d
Description
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Code of Conduct
- [x] I agree to follow this project's Code of Conduct
### Code Sandbox link
_No response_
### Bug report
```markdown
There is currently a bug in sanity's query engine which causes very poor performance in certain scenarios. Take the two queries and their corresponding params
Query 1: `*[_type == "video"][references($parameters.contributorId)] { _id }`
Params 1: `{"parameters":{"contributorId":"de21f586-6660-477a-8ca5-48aba9b844b5"}}`
Query 2: `*[_type == "video"][references($contributorId)] { _id }`
Params 2: `{"contributorId":"de21f586-6660-477a-8ca5-48aba9b844b5"}`
When you run any query from sanity studio's vision tool with nested parameters like Query 1, the execution time is an order of magnitude longer than if you use a flat parameter object such as in Query 2.
GROQD by default produces all queries in a manner that matches Query 1. I'm not sure if there is a different way around this, but in my codebase i have used this workaround.
export const runQuery = makeSafeQueryRunner((query, options) => sanityClient.fetch(query, options));
export const runQuery = makeSafeQueryRunner((query, options) => {
const unnestedQuery = query.replace(/\$parameters./g, "$");
return sanityClient.fetch(unnestedQuery, { ...options, ...options.parameters });
});
This is not technically a bug in groqd, but all groqd users will experience poor performance because of the current implementation.
```
Contributor guide
Assessment
This issue has not been assessed yet.