Repository navigation
Observable API #1
Description
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.
Activity
benjamingr commentedon Jun 6, 2024
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 commentedon Jun 6, 2024
@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 commentedon Jun 6, 2024
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 commentedon Jun 7, 2024
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 commentedon Jun 7, 2024
@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 commentedon Jun 7, 2024
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 commentedon Jun 7, 2024
Doesn’t rxjs work on all platforms? Interoperability in what way?
ovflowd commentedon Jun 7, 2024
Interoperability as a standard specification bundled within the engines and runtimes?
domfarolino commentedon Jun 7, 2024
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 commentedon Jun 7, 2024
What's the practical difference for the user?
ronag commentedon Jun 7, 2024
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 commentedon Jun 7, 2024
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 commentedon Jun 7, 2024
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.
True with every JS library that inspires platform primitives! We should probably not stop standardizing features though.
benjamingr commentedon Jun 7, 2024
@ronag hey the idea for this as a standard means several things:
benjamingr commentedon Jun 7, 2024
Also:
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 commentedon Jun 7, 2024
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 commentedon Jun 8, 2024
From the perspective that we can add observable API to other standard API interfaces I'm more positive to this.
jasnell commentedon Jun 8, 2024
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 commentedon Jun 9, 2024
I believe a PR is already open here nodejs/node#51065
benjamingr commentedon Jun 9, 2024
@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 commentedon Jun 10, 2024
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.
streamich commentedon Mar 20, 2025
This would be huge when it lands. Observables is not just mechanism for managing events, it is also by far the best state management tool we have.