WebUI: Use websockets instead of http polling/API

[kripton]

Currently the Web UI uses HTTP call to the device's API to get/update information like device status, buffer content (Console page), log entries, wireless status counters. Usually, a one second update polling interval is being used which makes the Console seem laggy when the values update often or fade. Websockets provide a nice way to make the Web UI more responsive and faster. Some "live audio mixers" that can be controlled via web browser from a tablet or similar uss websockets for control and signal level display (Soundcraft's Ui series).
The client/browser part should not be a problem (and a fallback to polling could be done if the user-agent doesn't support websockets). On the server side (lwIP stack and its http server) impementation will be quite some effort.

[kripton]

Some references (all seem to implement a custom http server on top of lwIP):
https://github.com/willemwouters/ESP8266/blob/master/projects/apps/websocket_example/src/lwip_websocket.c
https://lujji.github.io/blog/esp-httpd/
https://github.com/maxushka/web_socket_stm32f4/tree/main/Core/Src

[peternewman]

It would be nice to keep a basic JSON API too if possible if it doesn't add too much codespace, as that's much easier for people just hacking around with the board wanting random integration. Although I appreciate it's probably not the best way to e.g. send DMX data to it.

[kripton]

Yes, the JSON API is meant to stay, even if websockets are implemented for exactly the reasons you mentioned :)
The "CGI" approach offered by lwIP's web server is a bit awkward and bloats the code a bit but I agree that using curl or wget for simple commands is a big advantage.