FormidableLabs / FormidableLabs/groqd

GROQD params are nested, which cause very slow query times.

Open
#399 1 comment 1 reaction 0 assignees View on GitHub
bug
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.