Q&A: Async Iterators

[00:00:01]
>> Jafar Husain: Any other questions out there? I'm actually somebody asked that question cuz I wanted to cover subjects. Yeah?
>> Speaker 2: I have a question about the async iterator proposal.
>> Jafar Husain: Yeah?
>> Speaker 2: Do you see any way that you can use them together with observables?
>> Jafar Husain: Absolutely, the main difference between an async iterator and an observable, as I think I eluded to early, an async iterator is almost exactly, but not entirely exactly, like an iterator of promises.

[00:00:27]
So I say hey, give me the next value. And then the producer, instead of giving me the value immediately, it gives me a promise which eventually resolves to the value. And what's great about that is for things like I/O for example, I can read data at my leisure, right?

[00:00:41]
Let's say I'm writing out to an output stream, and I can only write so fast. Well I can decide to read, whenever I'm ready, I can just call next and I get the next value. All right so, asynchronous iterables, just like regular iterables, the consumer is in power and they decide when to pull the next value.

[00:00:58]
Observable flips that around, right? With and observable, the producer decides when you get the next value. And there's no way of telling the observable cool it for a while man. I'm not quite ready yet. You can unsubscribe but that's not the same thing as pausing the observable, all right.

[00:01:12]
If you unsubscribe, then you resubscribe you might cancel a network request, or kick off a whole new network request which will get different data. So it's important to understand that unsubscribing and resubscribing might have a whole bunch of side effects. It is not the same as pausing a stream.

[00:01:24]
Does that make sense? So in order to adapt an observable into an asychronous inerator, basically you need some back pressure strategy. You need a way of kinda pausing the observable even though there's not way out of the box of pausing the observable. And the most obvious strategy is two obvious ones.

[00:01:42]
One if buffer, right? Well, data's coming, but the consumer's not ready for it yet. So I'm gonna put it over here in a buffer. And then the other one is drop. Just throw the data away, right? You could, basically it's like a buffer of one. You can put it in one and then you can throw away any overflow data.

[00:01:58]
>> Speaker 2: Isn't that kind of what a debounce is though?
>> Jafar Husain: Well it's similar to a debounce, similar. But it's not the same thing because in a debounce usually you're doing it for some period of time. Whereas in this case you're kind of debouncing until the consumer sends you an explicit request signal.

[00:02:13]
And there's no concept of that in observable, right? There's no pull, it's all push. But it's similar in some way to the demounts. And then of course, you could drop all the new ones. You could also drop all the old ones, there's a whole bunch of variations. But yeah, it's pretty straightforward to adapt an observable into an async iterable as long as you don't mind losing a little data or you don't mind an unbounded buffer.

[00:02:38]
Now in general, you're probably, since async iterable is the most flexible type, in the end you can always adapt an observable into a async iterable. You could also go the other way as well, right? That would just mean four looping over the async iterable, and then next thing and pushing out, right?

[00:02:57]
In general, I'm not sure how commonly they're gonna be used together. In practice, I think you're gonna see a lot more async iterables on the server and you're gonna see a lot more observables in the client. In general async iterable makes a lot of sense when you're doing IO, right?

[00:03:10]
Cuz you can only write at a certain speed with async iterables. And so that makes sense cuz you have back pressure. But if you're working with events, well, you can't tell the user to wait, right? [LAUGH] The user can always click a new key and so observables are a much better fit for evented programming, like the type of programming we see in the front end.