Improve frontend loading performance

[kolaf]

Frontend api redesign

Existing implementation

1. The frontend loads the navigation task data from a single endpoint that provides the navigation task, the route, and all current contestants.
2. It then connects to the websocket that pushes position and score updates, as well information about new or deleted contestants. Position and score updates are cached while loading initial track data.
3. Initial track data is loaded for each contestant included in the initial navigation task load. Is currently done sequentially avoid overusing webserver connections. Loading the track data for a single contestant may take as much as five seconds.
4. After initial track loading any data arrived on the websocket is added to the internal data structure, and the display is live.

To summarize, initial loading is done via rest and all subsequent updates are pushed via the websocket. The track for contestant will never be modified after it has been received, but the score and score log may be changed after the fact by the contestant administrator if there were any errors in the scoring.

Considerations for a new implementation

The most important thing is to cache the static files (especially the frontend since it is quite large) and the contestant tracks. Contestant tracks can never be altered, but they will typically be updated every second with a new position as long as the contestant is flying. Changing to a model where the websocket only pushes notifications about data and having the front end fetch the updated data via rest seems like a good approach to reduce load on the real time system.

The simplest approach is to cache contestant tracks indefinitely with a one second resolution, which leads to 1800 HTTP requests for half an hour of data. This seems excessive. Having larger slices, e.g. 5 seconds, means that the last slice will be incomplete and should not be cached which leads to higher server load. However, retrieving five positions should not pose a big imposition on the server.

The score and score log may be altered after the flight which means it cannot be cached indefinitely or for a significant time. It appears to be possible to explicitly invalidate a CDN cache, but it looks like this is not advisable.

[kolaf]

The track may change after the fact if the administrator uploads a gpx file or reverts back to the live data.

[kolaf]

The speed of the live tracking map frontend is been significantly improved. We have not implemented cdn yet, not sure if this is required.