Why make a 'relay server' instead of using Web Serial
The Web Serial API is the first obvious candidate for connecting a web browser and a serial port, and initially I
spent quite some time trying it out. Eventually I decided against using webserial for the reasons below.
- The Web Serial API is not well supported across browsers. Even on the 3 browsers that do currently support it,
the status is experimental and may change in future (or even be withdrawn completely as Chrome has done with
some experimental features in the past). Being an experimental feature often means the user needs to enable it in a
developer settings console (at least with Chrome this is the case) and so does not work right away.
While it wouldn't be a show-stopper to require that everyone has to use a specific browser, most people already have
a browser they prefer and it would be nice to accommodate that if possible.
Compare support for the WebSockets used by the relay server.
- If the web page was connected directly to the device, either a) the device would have to parse and produce long JSON strings, or b) the
JavaScript would have to pack and unpack information to and from binary format. Option A would require precious memory and
extra time from the microcontroller and is basically not viable. Option B would be a painful headache to maintain and update. The relay server can handle both
steps easily with no extra load on either side.
-
With a relay server the configurator is not restricted to connecting only to the ports of the host computer. By connecting to a
remote relay server, configuration can potentially be done from anywhere in the world, by multiple different configurators. Devices with no
USB host capability (eg. iOS) can also view the configurator via another computer on the network.
- Most browsers have a developer panel where messages going between the webpage and the relay server will be logged in plain text.
This is very helpful while developing and will likely come in handy for investigating bug reports too. If this communication was being done
in binary this logging would be near useless.
- Being JavaScript, the configurator is essentially open source and anyone could make their own webpage to interact with the system.
If the webpage and device were connected direcly, future firmware updates might require changes to the way the device communicates, which might require
users to update their custom
webpages. With a relay server in between this disruption can be kept to a minimum because the webpage does not directly deal with device messages.
Yes, there will still be message changes in new versions of the relay server, but JSON is a much more forgiving format when dealing with
missing or unknown data properties. The relay server is much less restricted in memory and CPU power so it can be given the heavy lifting of
liasing between different versions.
- Having a relay server as a separate process is useful for more than just access to serial ports. It can also read and write local files,
for example to save and load configs locally, or to allow firmware updates from within the configurator. If the webpage and device were
connected directly, the firmware file would have to be loaded into the webpage over the network before flashing. Doable, but only if you have
internet access, and you would need to load it every time instead of being able to save a collection of firmwares locally. I suspect flashing
would also be much slower.
- It is anticipated that the configurator would most commonly be used as a central website, but this is inconvenient when you're out
in the field and don't have internet access. The configurator will therefore be available to be downloaded and run offline. This will
require a minimal web server setup on the local computer which is actually not that difficult. If the webpage and device
were to be connected directly via Web Serial API, you would further need to set up an SSL certificate on your local computer (to connect from anything
other than 'localhost'). This is of course doable but not quite so easy, and adds yet another hurdle that is not required when using a
relay server.
- The relay server writes a log file with more information than the browser knows about, that will not be lost when the browser tab is closed.