Websocket server for testing and development.
I needed this for e2e and integration testing a bot that listened on a websocket.
Start the webmocket webserver. ```bash cargo run
```
Connect a websocket client (webpage, bot, client, etc.). e.g. wscat. Then send a few messages to the server. Typically this would be the subject under test. ```bash wscat --connect http://127.0.0.1:3000/ws
```
Check messages received from client: ```bash curl http://127.0.0.1:3000/messages | jq
```
Fire websocket messages to the client using a normal HTTP library. e.g. curl
.
wscat --connect http://127.0.0.1:3000/ws
curl -X POST -H"Content-type: text/plain; charset=UTF-8" \
--data 'Hello from the server 👋' \
http://127.0.0.1:3000/messages
We should see wscat print the message to the console.
In order to install the platform on development machine, run
cargo install webmocket
TODO: build binaries and make the avaiable for download.
webmocket
Webmocket is configured through env vars. These must be set before starting.
| var | | default |
|---------|----------|---------|
| WEBMOCKET_ADDR
| IP address of the listening host. Must be a valid IPV4 | 127.0.0.1 |
| WEBMOCKET_PORT
| Port on which the service will listen. Must be a valid unix port | 3000 |
| WEBMOCKET_WS_PATH
| Path on which the websocket can be connected. Must start with / | /ws |
E.g. to set all variables, one could run:
bash
WEBMOCKET_ADDR=127.0.0.2 WEBMOCKET_PORT=8080 WEBMOCKET_WS_PATH="/messages/user" cargo run
Alternative is to run webmocket in a container. Usefull in e.g. a CI pipeline, or when you don't want or don't have cargo around.
docker run --rm --detach --expose 3000:3000 berkes/wemocket:latest
Environment variables as described under Configure can be passed in to configure the service. For example:
docker run --rm --detach --expose 3000:3000 --env WEBMOCKET_WS_PATH=/chat/stream
This will run the webmocket service with the websocket endpoint on http://0.0.0.0:3000/chat/stream.
Note: The port 3000 is hardcoded in the image so changing the WEBMOCKET_PORT
to anything other than 3000 won't work.
Get the source-code, then
cargo test
This builds the application and runs the tests locally.
TODO: CI/CD setup
TODO: CI/CD setup
The service is intended for local development or tests (A CI server or such): it keeps its database in memory. This means that if you're going to send a lot of data to it, it will need a lot of memory.
The service does not bind to HTTPS (or SSL), because that is hard to achieve. if the client insists on SSL only, you may need to configure some proxy before it.
If needs arise, or pull-requests arrive, some additional features could be added: