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

[ENHANCEMENT]: Avoid repeating identical HTTP requests in @custom fields #8949

Open
damonfeldman opened this issue Aug 11, 2023 · 0 comments
Labels
dgraph Issue or PR created by an internal Dgraph contributor. kind/enhancement Something could be better.

Comments

@damonfeldman
Copy link

Use case and current behavior

Currently an @Custom field such as

type User {
username: String! @id
...
posts: [Post] @Custom(http: {
url: "https://my.api.com/person/$username/posts",
method: GET
})
}

may request the same "itemType" information many times in a single query. This can lead to varied results if the API info changes, and is inefficient.

Enhancement

Instead, the exact same URL should make one call per Dgraph transaction. For requests with a post body, GraphQL request or other information, the entire request may be needed to be used as a key, or hashed and used as a key to avoid duplicates.

This may not make sense under the current restriction per the docs that "each custom call must include either an ID or @id field" which may mean that the requests must already include a unique identifier, which prevents many requests of the same item in most cases.

Overall, any item should be return-able via @Custom, and if there are duplicate requests within a transaction, they should be consolidated to one request.

Ideally, this will work both with regular Entities in Dgraph (fields and entity UIDs returned) and @Remote types where the entire data object is returned from an external source.

Solution proposal

This could be accomplished by keeping a map of URLs called, and responses for the transaction duration.

Links to Discuss, RFC or previous Issues and PRs

No response

Links to examples and research

No response

Additional Information

See @Custom docs here: https://dgraph.io/docs/graphql/custom/directive/

@damonfeldman damonfeldman added the kind/enhancement Something could be better. label Aug 11, 2023
@rderbier rderbier added the dgraph Issue or PR created by an internal Dgraph contributor. label Aug 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dgraph Issue or PR created by an internal Dgraph contributor. kind/enhancement Something could be better.
Development

No branches or pull requests

2 participants