dojo / dojo/meta

Efficiently handling WebSockets

Open
#93 5 comments 0 reactions 0 assignees View on GitHub
enhancement future
Dominant language
No language data
Stars
226
Forks
42
PR merge metrics
No merged PRs in 30d

Description

In Dojo 1.x, WebSockets are mostly an afterthought in how we approach APIs, with most examples using traditional XHR calls, and all provide store implementations using XHR.

For Dojo 2, I think it would nice if it was clear how WebSockets are used. The native APIs for WebSocket events are rather basic, which over the years led to [dojox/socket](https://github.com/dojo/dojox/blob/master/socket.js) and [tube](https://github.com/bryanforbes/tube).

As such I think we should consider:
- Do we provide an API for WebSockets similar to our handling of dojo/request? The challenge in the past was that it doesn't follow a traditional request/response paradigm, and is more akin to our other event-driven paradigms. If so, do we bother with falling back to long-polling and introducing reconnection logic (needed for some networks and firewalls))
- Do we provide an out of the box module for stores to be backed by a WebSocket for data updates?
- Are there other considerations we need to make for real-time data updates (with Dojo 1.x, dgrid handles this pretty well out of the box, charting was always quite a bit of work). I imagine this fits nicely into our architecture and vdom approach and is easier to make work with Dojo 2.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.