A few questions about Subscriptions

[acavestro]

Hello everyone,
I'm sorry to bother about some maybe trivial questions, but I'm quite new to Rust and Juniper and I'm working to a spike project about GraphQL subscription. There is a couple of things I can't understand and I would like to ask.

I'm working with juniper-actix, juniper-subscriptions and juniper-graphql-ws crates.

First question. A subscription resolver should return a Stream object. Do the libraries keep polling on it or do they poll on the entire resolver method, expecting a new Stream every time?

Second question. Does every subscription correspond to a thread (or a tokio task) or is there something like a thread pool to manage websockets and subscriptions? Maybe something like a coordinator?

Thanks in advance to who will be patient enough to answer :D

Have a great day
Antonio

[tyranron]

@acavestro hi!

First question. A subscription resolver should return a Stream object. Do the libraries keep polling on it or do they poll on the entire resolver method, expecting a new Stream every time?

The entire resolver method is resolved once, and once juniper has the returned Stream, it polls it until it completes. If Stream::Item contains requested computable fields, they will be resolved each time a new Stream::Item is yielded.

Second question. Does every subscription correspond to a thread (or a tokio task) or is there something like a thread pool to manage websockets and subscriptions? Maybe something like a coordinator?

In your setup this question has nothing to do with juniper, but rather how actix-web works with websockets.

The actix-web itself runs N single-threaded tokio executors. So once HTTP request arrives to some thread, managed by actix-web, it never leaves it, undependently on the fact whether it's websocket or a regular one. So, using juniper-actix you may be sure that resolving is never moved to another thread, and use this fact to simlify your life with Send + Sync requirements (if you do hit them) by using workarounds like send_wrapper crate.

At the moment, juniper is fully transparent in this question, and execution fully depends on how the underlying runtime executes juniper.

[acavestro]

Hi @tyranron thanks for your answers. I'm glad you covered also the part related to actix-web.

So,

The entire resolver method is resolved once, and once juniper has the returned Stream, it polls it until it completes. If Stream::Item contains requested computable fields, they will be resolved each time a new Stream::Item is yielded.

I assume the Stream completes when it returns Poll:Ready(None), not when it returns Poll::Pending.

The actix-web itself runs N single-threaded tokio executors. So once HTTP request arrives to some thread, managed by actix-web, it never leaves it, undependently on the fact whether it's websocket or a regular one.

Can I assume an executor will be dedicated to a subscription until its Stream completes?

Thanks again

[tyranron]

@acavestro

I assume the Stream completes when it returns Poll:Ready(None), not when it returns Poll::Pending.

Yes. This is better described in docs.

Can I assume an executor will be dedicated to a subscription until its Stream completes?

Seems to be a terminology inaccuracy. Let's summarize it:

• Executor is a runtime performing async tasks (the event loop). In actix-web it's a single-threaded, and once it's dedicated to some thread, neither thread changes its executor, nor executor changes its thread.
• Task is a composed Future that is ::spawn()ed on some executor, and executors runs it until the whole task completes (composed Future representing it returs Poll::Ready). In actix-web once a task is spawned on some executor, it will never move to another one (so will never move to another thread).
• Stream is a sequence of values produced asynchronously. So, for a Stream to emit something, it should be transformed into a Future and completed as asynchronous task by the underlying executor.

So, answering your question strictly: no. An executor is not dedicated to a single Stream. Furthermore, it has no sense, while a Stream is pending, it may easily process other tasks (the whole point of async, actually). But, once you return a Stream, it will be executed on a single executor, and won't ever move to another one.

Polling a Stream is polling just a Future inside an async task. There is no sense to dedicate it to a separate executor.

[acavestro]

Hello,
sorry for the very late reply.

I just wanted to thank you for your clear explanation and for your patience with my very general question.
Everything was great, thank you again.