-
Notifications
You must be signed in to change notification settings - Fork 1
Engineering Goals
This is a general collection of behind the scenes engineering items I want to improve on or move towards.
The current implementation is fine while I only have a single way to issue commands from a remote client, but will not work if I were to add another way to receive commands such as support for the WiThrottle Protocol. Ideally, loco state would be treated as a write-through cache that knows how to issue commands via a command station when a request to change loco state is made.
External command handlers would simple make a request to update a loco's state and let the state cache handle issuing the command to enact the state change.
Entering a page that requires knowledge of a loco's current state incurs the cost of a request message to the server for the state and potentially multiple response messages depending on the type of request. While on a local network the overheads are barely noticeable, we can improve this by requesting all the state we needs when we initially establish the WebSocket connection and caching the results. The cache can be automatically kept up to date by listening out for state change broadcasts. When entering a page that needs to know about the loco state, the controls can directly bind to the data held in the cache rather than manually listening to broadcast messages.
Parameter validation mostly happens at the point a command is about to by physically sent to the track or the database. It would be better to validate parameters at the point we receive requests to catch issues early and reduce the work done before a request is rejected.
This is also help preventing a single point of failure if a low-level system incorrectly validates parameters in the future.