Websocket Test features
- Dominant language
- TypeScript
- Stars
- 58
- Forks
- 47
- Avg merge
- 13h 3m
- Merged PRs (30d)
- 110
Description
Under tools , we have a standalone websocket-test html page.

Right now, this has to be deployed to the folder served by the running vuuserver instance (`yarn deploy:websocket-test`). That's because of the built-in auth mechanism currently employed by the vuu server , which requires that clients get an auth token over https.
At the moment, this page allows a user to connect to a vuu server websocket, get an auth token, login and create a viewport. We should extend this to support:
- exercising as many of the available vuu protocol messages as possible
- subscribing to `system` tables and displaying these in real time e.g. METRICS.tables, METRICS.viewports
The page is completely standalone - it can just be 'copy deployed' to any vuu installation. I image eventually, this might well be be what the standard vuu server installation serves by default. Right now, all code is authored right inside the html page. If we want to break this down into a more modular structure, we should also create a build that writes the entire output into the deployed html file, so we preserve the standalone quality of this tool.
Contributor guide
Research direction
Start with the standalone websocket-test HTML page under tools and run yarn deploy:websocket-test to understand its current deployment flow. Review the existing authentication, login, viewport, and WebSocket protocol handling; done means the page exercises the agreed protocol messages, subscribes to system tables such as METRICS.tables and METRICS.viewports, displays updates in real time, and remains copy-deployable as one standalone HTML file.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- html
- Domain
- testing, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100