This page describes the preliminary requirements and design for asynchronous event support in the NDS Labs Workbench. In order to update the GUI in real time, the server needs to send state changes back to the client. This can be achieved via WebSockets, HTTP Long Polling, or HTTP Streaming. Currently, the NDS Labs Workbench prototypes uses a fragile auto-refresh method that can have unexpected behaviors.
Platforms
We need to decide which browsers and versions we will support going forward. Browser support options might preclude use of some technologies.
Use
...
cases
For project A, the administrator has a single instance open in the browser. For project B, the administrator has the project opened in two separate browsers (or two users are sharing the same login).
- When Project A adds a stack, the change is reflected in the Project A session.
- When Project B-1 adds a stack, the change is reflected in the Project B-2 session.
- When the cluster administrator adds a new service, the Project A, B-1, B-2 sessions are notified
- The cluster administrator can send a broadcast message to all logged in sessions (i.e., outage notification)
Gliffy Diagram | ||||
---|---|---|---|---|
|
Authentication
- All connections will use wss (secure ws) when possible.
- The existing JWT tokens will be used for authentication of websocket connections before upgrading
Events
The following will be supported via asynchronous events:
Project-specific
- Add/update/delete stack
- Add/update/delete volume
- Add/update/delete project
- Change in stack status
- Change in stack service status
The project administrator logs in to the NDS Labs Workbench GUI.
Events
Project-specific
- Stop stack
- Start stack
...
System-wide:
- Add/update/delete service spec
- Broadcast messagesOutages
Message formats
Authentication
...
Messages will be sent in JSON format, something like:
Code Block |
---|
{
event: "<ID>",
data: ...
} |
Messages will include
- Errors
- Create
- Update
- Delete
- Status
References
https://en.wikipedia.org/wiki/WebSocket
...