You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For GraphQL requests we allready know which relations should be resolved and which fields are requested. Use this information to only fetch spartial fieldset and relations instead of the complete document.
So it should be rather easy to translate the graphql query to the required setting on select and populate for the request.
I think the note from the select API also applies for the GraphQL queries:
To perform querying with select efficiently, Payload implements your select query on the database level. Because of that, your beforeRead and afterRead hooks may not receive the full doc.
So perhaps the rollout of this feature should be done via a feature flag?
Link to the code that reproduces this issue
This is a private repo.
Reproduction Steps
We have a GraphQL request against a collection which has a lot of very deeply nested relations.
The REST API for a call against a document in that collection without select and populate APIs returns a json document which has a size of 1,5 MB.
The GraphQL API for a call against a document in that collection returns a json document which has only a size of 16KB.
However how it currently internally works is that the GraphQL API does actually do the 1,5 MB call with all the unrequired data and then only "re-formats" the data to the 16kb. There are a lof of unnecessary data loading and database requests.
Which area(s) are affected? (Select all that apply)
db-postgres
Environment Info
Payload: 3.20.0
NodeJS: 22.16
Next.js 15.1.6
The text was updated successfully, but these errors were encountered:
Please add a reproduction in order for us to be able to investigate.
Depending on the quality of reproduction steps, this issue may be closed if no reproduction is provided.
Why was this issue marked with the invalid-reproduction label?
To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository created with create-payload-app@beta -t blank or a forked/branched version of this repository with tests added (more info in the reproduction-guide).
To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.
Please test your reproduction against the latest version of Payload to make sure your issue has not already been fixed.
I added a link, why was it still marked?
Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.
yobottehg
changed the title
Use select and populate API from local and Rest API for GraphQL
Use select and populate API of the local and rest API for GraphQL
Feb 3, 2025
Describe the Bug
For GraphQL requests we allready know which relations should be resolved and which fields are requested. Use this information to only fetch spartial fieldset and relations instead of the complete document.
So it should be rather easy to translate the graphql query to the required setting on select and populate for the request.
I think the note from the select API also applies for the GraphQL queries:
So perhaps the rollout of this feature should be done via a feature flag?
Link to the code that reproduces this issue
This is a private repo.
Reproduction Steps
We have a GraphQL request against a collection which has a lot of very deeply nested relations.
The REST API for a call against a document in that collection without select and populate APIs returns a json document which has a size of 1,5 MB.
The GraphQL API for a call against a document in that collection returns a json document which has only a size of 16KB.
However how it currently internally works is that the GraphQL API does actually do the 1,5 MB call with all the unrequired data and then only "re-formats" the data to the 16kb. There are a lof of unnecessary data loading and database requests.
Which area(s) are affected? (Select all that apply)
db-postgres
Environment Info
The text was updated successfully, but these errors were encountered: