problem: no async/await API

[somdoron]

We can follow zeromq/zeromq.js#189

@rolftimmermans any suggestion regarding the subject?

[rolftimmermans]

In my opinion an async interface should follow the semantics of a "blocking" API as you would write it in lower level languages without async support.

I spent quite a bit of time experimenting with an API that would make sense, is simple, and keeps ZeroMQ semantics in JS. So by all means take cues from ZeroMQ-NG if you think that makes sense.

I'm not sure if there are additional challenges for a JS-only implementation, but I'd be happy to weigh in where possible.

[somdoron]

Thanks, @rolftimmermans. I think you can contribute by implementing the async/await feature.
Also, one more thing I want to implement is the inproc transport, so you can explore this as well.

Thanks!

[rolftimmermans]

I recently had the chance to review the implementation of this library a little. I noticed the implementation is based on event emitters, like the current version of zeromq.js.

I would strongly suggest picking an async-first approach, which I designed and implemented for https://github.com/rolftimmermans/zeromq-ng (which I intend to be a replacement for zeromq.js). Otherwise, an application that is not consuming messages fast enough (due to slow application-specific logic, for example) will never be able to trigger high water mark settings. I think that's a core feature of ZMQ and breaking it will hurt reliability.

With the event emitter pattern an application cannot put any backpressure on the stream of messages. They just keep coming in (possibly way too fast). All it can do is queue the incoming messages in the application, completely sidestepping ZMQ.

[somdoron]

@rolftimmermans I would really like an async approach, the reason I went with event emitters is to be compatible with zeromq.js.

I want to support both the old zeromq.js API and the new one that was just merged.

[rolftimmermans]

You can't add backpressure if the underlying API is an event emitter, but the reverse is possible. So you can write async/await first and add an event emitter layer on top.

[somdoron]

I will look into that, also pull request is welcomed.

[Sceat]

@somdoron aside events based and async based approaches, there is also Observable based style that is often forgotten yet pretty powerful and could fit here for best of both worlds!

[somdoron]

I'm a big fan of Observable and used it when I implemented the NetMQ binding for F# (FSNetMQ).
However, I would like to the API of JSZMQ and zeromq.js to be very similar or even compatible. I would like to move from the current API and use the async/await one and maybe even drop the events API. We can add the Observable on top.

[Sceat]

I agree that an async starting point is always good to build any kind of things on top, once zeromq.js support websockets we will be able to do really cool stuff with jszmq in the browser and zeromq.js as the server! nice

[Sceat]

@somdoron i just discovered that in node but you can implement backpressure in an observable way with recent streams using async iterators https://nodejs.org/api/stream.html#stream_stream_pipeline_source_transforms_destination_callback