search

nodejs / standards-positions

The Node.js Projects Official Positions on various standards proposals
MIT License
17 stars 1 forks source link

Observable API #1

Open domfarolino opened 3 months ago

domfarolino commented 3 months ago

Request for Node.js Position on an Emerging Specification

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 https://github.com/WICG/observable/issues/93 for a list of all standards positions issues that we've filed for the Observable API.

benjamingr commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

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

What's the practical difference for the user?

ronag commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

benjamingr commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

jasnell commented 3 months ago

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 commented 3 months ago

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 https://github.com/nodejs/node/pull/51065

benjamingr commented 3 months ago

@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 commented 3 months ago

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.