Observable API

[domfarolino]

Request for Node.js Position on an Emerging Specification

• Specification title: Observable API
• Specification or proposal URL (if available): https://wicg.github.io/observable/
• Explainer URL (if available): https://github.com/WICG/observable/blob/master/README.md
• Proposal author(s) (@-mention GitHub accounts): @domfarolino, @benlesh
• Node.js collaborators or ecosystem members who can provide input (optional): ?

Notes

The Observable API is a primitive with long history, providing declarative ergonomics for streams of async events. At an extremely high level, they are "Promises for multiple events, but with no built-in async scheduling". The Observable API is a long-awaited and highly-desired feature on the web platform.

The reason we're coming to Node.js (and WinterCG more broadly) is because these environments implement similar DOM APIs that integrate strongly with Observables, such as EventTarget and AbortController/AbortSignal. This is a natural primitive to sit alongside those ones, hence the outreach we're performing here. Please let me know if you have any questions, and see WICG/observable#93 for a list of all standards positions issues that we've filed for the Observable API.

[benjamingr]

I am personally +1 and in favor of doing this and adding this platform for compatibility and ease of use as well as integrating it into Node.js APIs where appropriate.

[benjamingr]

@nodejs/web-standards @nodejs/wintercg @nodejs/streams (since it's a push-stream primitive and Robert spoke to me about this a bunch) WDYT?

[ovflowd]

Heyo 👋 let me glance over the docs whenever I have some time, this sounds something I'm personally a huge fan of so +1 (or at least based on the abstract)

But since Im slow/OOO it might take some time for me to go over all of this, so please do not hesitate to proceed without me, but def +1 🫶

[ronag]

We use the rxjs Observables extensively and I believe it's an important library. Lack of back-pressure is unfortunate. Overlap with node streams is unfortunate.

TBH: even if it was part of the standard we would still use RxJS. I'm unsure whether or not it's part of the standard makes much of a differences for the backend. I'm +0 in regards to whether Observables should become a API standard.

[benjamingr]

@ronag I think a big point is interoperability - once all our platforms expose the observable proposal it's possible to write universal code using observables and integrate it into APIs where it makes sense

[mcollina]

I think push interfaces should be avoided. However, this is more or less as risky for our users to our events.on(emitter, event) utility that will buffer all events.

I’m neutral to the proposal. I can only see benefits in compatibility with the frontend ecosystem.

[ronag]

@ronag I think a big point is interoperability - once all our platforms expose the observable proposal it's possible to write universal code using observables and integrate it into APIs where it makes sense

Doesn’t rxjs work on all platforms? Interoperability in what way?

[ovflowd]

@ronag I think a big point is interoperability - once all our platforms expose the observable proposal it's possible to write universal code using observables and integrate it into APIs where it makes sense

Doesn’t rxjs work on all platforms? Interoperability in what way?

Interoperability as a standard specification bundled within the engines and runtimes?

[domfarolino]

We use the rxjs Observables extensively and I believe it's an important library. Lack of back-pressure is unfortunate.
TBH: even if it was part of the standard we would still use RxJS.

Can you clarify what the reason for this (last part) would be? Just to clarify, our proposal does not mean to obsolete RxJS entirely. That library would likely evolve into one of subtler operators that we would not immediately push into the web platform, but its custom Observable implementation would almost certainly get removed in favor of the platform's, once widely available. But I'm curious why your first take is to keep using RxJS in light of a standardized Observable protocol.

[ronag]

Interoperability as a standard specification bundled within the engines and runtimes?

What's the practical difference for the user?

[ronag]

We use the rxjs Observables extensively and I believe it's an important library. Lack of back-pressure is unfortunate.

TBH: even if it was part of the standard we would still use RxJS.

Can you clarify what the reason for this (last part) would be? Just to clarify, our proposal does not mean to obsolete RxJS entirely. That library would likely evolve into one of subtler operators that we would not immediately push into the web platform, but its custom Observable implementation would almost certainly get removed in favor of the platform's, once widely available. But I'm curious why your first take is to keep using RxJS in light of a standardized Observable protocol.

If there was feature parity over time there would be no reason. However, I would expect RxJS to evolve faster than a standardized API.

[ovflowd]

Interoperability as a standard specification bundled within the engines and runtimes?

What's the practical difference for the user?

It should be a transparent adoption somewhat IMO. I do see advantages for the user. Regardless. Genuinely speaking, a standard API removes the need of an NPM package, which cannot run on every single JavaScript environment.

Now, RxJs could definitely extend upon the standard API.

I don't see harm on implementing it, why so much negativity? 😅

[domfarolino]

Now, RxJs could definitely extend upon the standard API.

That's exactly the plan. I'll let @benlesh comment though, as he's the maintainer of RxJS and has been helping out a lot with the Observable API proposal.

However, I would expect RxJS to evolve faster than a standardized API.

True with every JS library that inspires platform primitives! We should probably not stop standardizing features though.

[benjamingr]

@ronag hey the idea for this as a standard means several things:

• Platform APIs (like Node's own EventEmitter and DOM's EventTarget could support conversion/interoperability cleanly.
• Similarly libraries get a platform supported way to consume/produce observables where it makes sense.

[benjamingr]

Also:

I don't see harm on implementing it, why so much negativity? 😅

Because the streams people are the ones most likely to end up having to maintain this as well as consider how this interoperates with other flows. We have concerns around being careful about exposing APIs with observables where backpressure is needed but probably(?) want to support them in stuff like file watching - it's tricky and not obvious and adding another async primitive is certainly not something to be done lightly.

That said, I think in this case it's common/good enough to consider it and I think the benefits are tangible. 3

[jasnell]

I'm fairly neutral on the API at the moment. I'd like to see more implementation and real world use. I'm certainly not against an implementation directly in Node.js. I'm +1 to the project publishing a position on the spec.

[ronag]

From the perspective that we can add observable API to other standard API interfaces I'm more positive to this.

[jasnell]

Given the responses here, the next step would be for someone to open a PR drafting an initial take on the position the project wants to take here.

[ovflowd]

Given the responses here, the next step would be for someone to open a PR drafting an initial take on the position the project wants to take here.

I believe a PR is already open here nodejs/node#51065

[benjamingr]

@ovflowd I think James means in this repo (i.e. the project to discuss what it thinks about the standard vs. directly adopting it) though this repo and process is new and I'm unclear about the process myself.

[jasnell]

Yep, per the process outlined https://github.com/nodejs/standards-positions#process we need a separate document added via PR here that outlines our position. It can be super simple and straightforward. Any discussion of whether we may or may not actually implement the API should happen in that PR and that document.