-
Notifications
You must be signed in to change notification settings - Fork 238
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
feat: Implement @live, @stream, @defer #342
Comments
That article is 2016. I'm not sure what happened to those but they are likely outside of their plans or already implemented. |
It's on the 3.0 roadmap of Apollo, I'm on the phone right now i don't have the link |
not sure about |
About the stream version: I'm experimenting with inter service communication or background tasks with federated services, and I would like to reuse the existing graphql interface available for the federation to avoid the addition of an other communication layer. And I've some cases where I would like to pull a large amount of data from an API for example to do some batch processing, and currently, using the graphql interface I have to chunk the data and send multiple search query. It would be awesome if I could do something like: client: const streamQuery = `
query {
searchResource(criterias: { status: PENDING }) @stream {
id
name
status
}
}
`
// or
// const streamQuery = `
// stream {
// searchResource(criterias: { status: PENDING }) {
// id
// name
// status
// }
// }
const client = new GraphQLClient('http://localhost:3000')
const stream = await client.query(query, variables)
for await (const data of stream) {
const resource = JSON.parse(data)
// do something
}
` The graphql query would not return an @mcollina Idk if this is a non-sense and there is a better way to achieve this, what do you think ? I feel like this is different from the subscriptions that offers a long running connection, and sending a query other the websocket would just result in one large message replied through the websocket. |
I think we'd need to implement a server-to-server client as well to take use of that properly. I'm overall ok with the idea, however the implementation is complex. Would you like to kickstart a repo in the org and try to experiment? |
Sure, I'll take a look when I've some time available. |
I would do that, yes. |
@edno I didn't even know about the RFC, thanks ! |
Support for this would be awesome! Any updates on this? This blogpost could provides some more context, with examples: |
Would you like to send a PR @robertherber? |
@mcollina I'd love to - but not sure I have the time to dig into it right now.. =/ |
Any updates on this? |
This requires work :(. Would you like to help? |
@mcollina are you still open for the PR? I started working on that so will open it some time soon! |
@igrlk what's the status of the spec for these? |
It would be awesome to support these directives, see: https://www.apollographql.com/blog/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07/
I haven't found any implementation yet but I read this will be part of apollo 3.0.
I have no idea how to achieve this feature yet, and this is probably linked to a client implementation. Maybe also a mercurius-client package ?
The text was updated successfully, but these errors were encountered: