Understanding @stream directive

[vrenken]

First off kudos to the team - The HotChocolate GraphQL libraries and tools add great value.

I've been playing with getting the @stream directive running and am starting to wonder if what I try to achieve is actually doable.

Hence a few questions:

• Can lists decorated with the streamed directive also be viewed and validated using Banana Cake Pop? I.e. that updates trickle in when received, just like with subscriptions? Is there a solid, complete example somwhere that I might have overlooked?
  There was a mention in either the documentation or issues/discussions that this was not possible yet completely - due to complete execution still needing to happen when the request initiated, but even with the latest 14.0.0-p.127 the request just keeps waiting indefinitely without any results returning at all.
• Can lists like IAsyncEnumerable also be streamed for a longer period of time - i.e. for example to inform clients of changes to an entity, even beyond minutes or hours?

I am probably missing something so happy to learn.

Thanks in advance & keep up the great work.

[cabillin]

Piling on with my own questions related to "Understanding @stream directive".

Can anyone confirm or correct the following?

1. Based on the fact that we need a IAsyncEnumerable, it seems like @stream is only usable on a field that returns a collection and where the resolver itself makes multiple async calls (e.g. API call or db lookup) to build the collection.

• e.g. in the example below, streaming quz would have no effect because the field itself is not a collection

2. Based on the fact that we need a IAsyncEnumerable, @stream will only impact the top-level resolver, not any children resolvers

• e.g. in the example below, streaming queryFoos will have no effect because the top-level result is handled by a single async call, not multiple

3. If pt2 is wrong and @stream impacts children resolvers, my understanding is that for any given resolver/field, the server devs have to choose between EITHER DataLoaders (and avoiding the N+1 problem) OR @stream support (and avoiding long wait times before any data is available to the client).
4. Using @stream inside of a deferred fragment will have no effect

Example use case:

query bob {
queryFoos(
filter: { ... }
) {
fooId
bars {
barId
quz {
name
}
}
}

• I am building a GraphQL on top of several RESTful API servers
• I have a top-level query that returns a collection of Foos (from a single call to a RESTful API).
• I also query for field "bars" (on Foo object), which returns a list of Bar objects.
• The resolver for the "bars" field leverages a BatchDataLoader, in which I make a single call to a RESTful API that returns a dictionary of Foo ids to Bar collection
• I also query for field "quz" (on Bar object), which returns a single Quz object
• The resolver for the "quz" field does not leverage a DataLoader because there is currently no RESTful API that can handle a batch query.
• The lookup for "quz" seems like a good opportunity to use/support streaming, but I'm not sure I can/how I would (in the query above).

... I guess I'm trying to see the value of @stream. It seems like the only use case where @stream makes sense is when ALL of the following is true.

1. incremental load is desirable (client-side)
2. have a collection field
3. the field is not configured for paging (which I thought was a best practice to avoid DoS)
4. the field is not in a defer fragment
5. the resolver for the field could make several async calls to populate the collection (e.g. 1 async call per item)
6. the boilerplate latency of the async calls (e.g. establishing a db connection) is small enough that making several async calls "makes sense"/will actually result in significant latency savings (client-side) for the 1st set of data
   ... this just doesn't seem like a common use case. Am I missing something?