Skip to content
This repository has been archived by the owner on Sep 2, 2022. It is now read-only.

Extend subscriptions to return initial data #239

Closed
kbrandwijk opened this issue Jun 11, 2017 · 8 comments
Closed

Extend subscriptions to return initial data #239

kbrandwijk opened this issue Jun 11, 2017 · 8 comments

Comments

@kbrandwijk
Copy link
Contributor

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.

@marktani
Copy link
Contributor

marktani commented Jun 11, 2017

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 Post nodes. Is that the behaviour that is always desired?

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.

@kbrandwijk
Copy link
Contributor Author

kbrandwijk commented Jun 11, 2017

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...
I put it here to give the discussion a place to live, it's by no means a final solution.

@marktani
Copy link
Contributor

marktani commented Jun 11, 2017

I put it here to give the discussion a place to live, it's by no means a final solution.

Absolutely, and I appreciate your input! Would love for everyone in the community to chime in if they have an idea.

@kbrandwijk
Copy link
Contributor Author

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...

@kbrandwijk
Copy link
Contributor Author

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?

@eliezedeck
Copy link

+1 for this

@stale
Copy link

stale bot commented Jan 9, 2019

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.

@stale stale bot added the status/stale Marked as state by the GitHub stalebot label Jan 9, 2019
@stale stale bot removed the status/stale Marked as state by the GitHub stalebot label Jan 10, 2019
@stale
Copy link

stale bot commented Feb 24, 2019

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.

@stale stale bot added the status/stale Marked as state by the GitHub stalebot label Feb 24, 2019
@pantharshit00 pantharshit00 added kind/feature and removed status/stale Marked as state by the GitHub stalebot labels Feb 27, 2019
@janpio janpio closed this as completed Sep 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants