-
Notifications
You must be signed in to change notification settings - Fork 859
Extend subscriptions to return initial data #239
Comments
It's not immediately clear to me what the initial data should return. For this subscription subscription createPost {
Post(
filter: {
mutation_in: [CREATED]
}
) {
mutation
node {
description
imageUrl
author {
id
}
}
}
} We could return the most recently created 1000 For this subscription subscription changedPost {
Post(
filter: {
OR: [{
mutation_in: [CREATED, DELETED]
}, {
mutation_in: [UPDATED]
updatedFields_contains: "imageUrl"
}]
}
) {
mutation
node {
id
description
}
updatedFields
previousValues {
description
imageUrl
}
}
} I can't even come up with an initial data response that makes sense. |
Good points, there's also this discussion: graphql/graphql-spec#283 that lead to the change in the RFC to allow any data to be returned initially from a subscription. But I agree that it's not always clear what initial data set belongs to a subscription... |
Absolutely, and I appreciate your input! Would love for everyone in the community to chime in if they have an idea. |
IMAP / ActiveSync style patterns come to mind, that would involve keeping track of the last requested record (so you have a 'starting point' for the subscription), which is also impossible to do with the free query structure... |
Additional thoughts on this one. Maybe for the IMAP/ActiveSync style, whenever a subscription is created from a client, it could get a unique id. And the server could keep generating responses for it, even though there is no active wss connection anymore. Then, when you restart your app later on, you would get the subscription results the server has 'cached' as initial response? |
+1 for this |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions. |
GraphQL subscriptions are, by specification, not designed to guarantee completeness of data. The delay between an initial query, and activating the subscription on the data, can cause missing data on the client.
The RFC allows subscription queries to return a response (other than the connection ack), so returning an initial data set is within specs.
The text was updated successfully, but these errors were encountered: