Question: multicast by default?

After working with most for a while (which I greatly enjoy, thanks for that) I still get bugs because I forgot to multicast a stream that has more than one listener. Most often I don’t spot this first and lose time debugging until I figure out that it’s a multicast issue again.

Would it be possible to make streams multicast by default and have unicast as an optimisation? As a user it’s much easier to have my graph work as expected and add unicast as an optimisation later if a stream has just one listener, than suddenly getting unexpected behaviour because a new listener was added.

[briancavalier]

tl;dr there are significant performance implications. For now, it’s not likely to change, but we’re actively investigating ways we could make it work.

It’s been an open question, and there are good reasons on both sides. If you’ve seen any of the discussions about hot vs. cold streams in other libraries, this is related. It’s a very tricky problem for push-based implementations (like all of the popular current generation reactive JS libs), and unfortunately (as you’ve seen), introduces additional cognitive load. Other approaches, such as pull-based (like the experiment here), can avoid the problems (tho they have their own issues to work out!).

One interesting discussion has been around the intent of reactive streams. Some feel that the intended use case is point-to-point, and doing something different from that requires action on the part of the developer. IOW, reactive streams aren’t event emitters.

That’s complicated by the fact that some streams, like most.just(x) or most.from(array), have quite different behavior than those created by @most/dom-event or most.fromEvent. The former are typically referred to as “cold”, and reproduce their entire sequence for each observer, whereas the latter are referred to as “hot”, and new observers simply “tune in” at some point (like turning on the radio)

The reason multicasting isn’t the default in most.js is that doing the necessary bookkeeping at every node in the stream graph has significant performance implications. In the vast majority of “intermediate” nodes, multicasting isn’t necessary. For example, take a function like:

const getTheStuff(url) =>
  most.fromPromise(getUrl(url))
    .filter(removeSillyThings)
    .map(extractOnlyTheGoodParts)

In that case, getTheStuff knows that multicast isn’t necessary between fromPromise and map, nor between filter and map, because there can’t possibly be multiple consumers on those intermediate nodes. It would be an unnecessary hit to force getTheStuff to pay an invisible cost by having most.js automatically multicast each.

There’s been some work to reduce the cost in the case where a node has exactly one observer, but so far, it simply isn’t possible to achieve the current non-multicasted level of performance.

So, right now, identifying the right points to allow multiple observers is the responsibility of the application developer. So, if you know that getTheStuff may have multiple consumers:

const getTheStuff(url) =>
  most.fromPromise(getUrl(url))
    .filter(removeSillyThings)
    .map(extractOnlyTheGoodParts)
    .multicast()

So, for now, we’ll probably continue to experiment with ways to make multicasting “acceptably” fast. If that’s possible, then it’ll definitely be worth revisiting whether multicast-by-default is the right thing!

[AlexGalays]

Just in case you don’t receive notifications on edits; @briancavalier