WebSocket Client

[rwb27]

I'm re-writing the software for the OpenFlexure Microscope which will have a Vue.js front-end and a Python/FastAPI back-end (LabThings-FastAPI). Previously, we rolled our own HTTP client with axios but I'm keen to use an actual WoT client library this time. I've been able to get a good few things working using node-wot and an HTTP client, but for some things (like observing events and actions) it would be great to have a websocket client.

A quick look at the source suggests the websocket client in this library is currently a stub - is that correct, or have I missed something obvious? I will probably have a go at writing one one way or another, so I thought I'd ask here in case there's an existing effort I could join in with. @miguelrk is listed as maintainer - perhaps you could comment?

I cannot claim to be an expert node programmer, so you may or may not want a PR from me - but if I do write something, I'll see if I can format it as a PR in case it saves you effort in the future. In order to do so sensibly, is it possible there's some documentation of the websocket subprotocol you're currently using in the server part? I see that is implemented (though I've not analysed it in detail). I have mostly based my FastAPI implementation on the webthings.io subprotocol, but if there's other takes on this I would be keen to know.

If any WebSocket/HTTP long polling experts see this and want to chime in with comments like "you don't need websockets, just do long polling and the overhead is negligible" or "it's really important to minimise the number of websockets you use, so make sure you share them between components in your app" I would be very happy to take pointers!

Thanks,

Richard

[danielpeintner]

I would like to wait for @miguelrk to comment about his availability/plans/workload.

Anyhow, what I can say is that contributions are always welcome & appreciated 👍.
W.r.t. to websocket I have to say that I think the entire workflow is currently not fully describable via Web of Thing TDs since often it is about opening a connection and the data which goes back and forth is its own format/protocol.

I am not sure whether this is going to change (or can change) in the TD 2.0 work that is about to be kicked off right now. @egekorkan ?

[miguelrk]

Hello! Sorry for the late response, I'm no longer the active maintainer, so feel free to continue, we should probably update the maintainer list then 👍🏼

[relu91]

Hi @rwb27! 👋
Thank you for your interest in contributing to node-wot development. As @danielpeintner said we are always looking for new matainers and contributors. Regarding the WebSocket protocol binding, I would really love to see some advancement and I can support you by reviewing the code and pointing in the right direction.

I read that you used webthings.io subprotocol, but I don't know if you are aware there has been some standardization activity on that. The Web Thing Protocol Community Group has published a strawman proposal for a WoT-oriented protocol. Here you can find details about the Websocket protocol that they are building. I think we could start adapting our solution to what is written in the gdoc.

If any WebSocket/HTTP long polling experts see this and want to chime in with comments like "you don't need websockets, just do long polling and the overhead is negligible" or "it's really important to minimise the number of websockets you use, so make sure you share them between components in your app" I would be very happy to take pointers!

I would say we definitely need WebSockets even though an alternative solution would be to use SSE. For long polling I already have experience that it does not scale well enough. If you have a complex Web application the number of open HTTP connections is limited (and it is not that much) therefore you start losing notifications pretty quickly. SSE has similar limitations for HTTP/1.1 but no restrictions for HTTP/2 (not 100% about this please prove me wrong if you find something else).

+1 for re-using connections as much as possible. I would say one easy strategy is to have a connection pool in the client instance and re-use the connection for any subsequent operation. The connection pool may be populated for the event-oriented TD operations like observeproperty or subscribeevent. For the operations, I would still keep the request-response paradigm and close the connection once finished (if it was not a pooled connection).