Simulator Implementation

I am not completely happy with the current state of the simulator. It ignores the core architecture and does not use the abstraction layers between the repository and the service. This makes it very hard to understand the data flow of the application. The main reason for this is that there is no real update source. The updates for the WebSocket are generated from a string. Throughout the process, there is no real SiganlkUpdate object which gets generated. This makes it very difficult to combine real data and simulator data at the end.

The requirement for the cloud server to run both real data and the simulator in parallel with a toggle is very hard to implement in the current state.

The solution to this problem would be to mock the SignalkServerService with a simulator. The design goal should be to keep the simulator completely separate from the SignalkRepository and, obviously, the output routes. This would simplify the application and allow the simulator to exist as another implementation of the SignalkServerService. It would also enable robust end-to-end tests. The toggle could than be implement on the Service Level and not in between the SignalkRepository and the Routes. Half separating the Real dataflow and the Simulator dataflow is not a good option in my opinion.

The inputs for the simulator can be implemented similarly to the current state, e.g., via POST requests and forwarded to the new Service.