Currently this implementation fetches /config from the SRComp HTTP API every .3s, which is quite a lot of extra requests.
The CoffeeScript stream only loaded the config at the start and then assumed it was going to be fixed. While it's probably more correct to re-fetch the config occasionally, it would be better to only do so when the state changes. This would avoid load on the upstream server.
The reason that the other implementation has this query in a loop at all is to ensure that it handles the upstream API not being ready when the stream starts up. There is otherwise essentially no need to re-fetch the data.
Currently this implementation fetches
/configfrom the SRComp HTTP API every .3s, which is quite a lot of extra requests.The CoffeeScript stream only loaded the config at the start and then assumed it was going to be fixed. While it's probably more correct to re-fetch the config occasionally, it would be better to only do so when the state changes. This would avoid load on the upstream server.
The reason that the other implementation has this query in a loop at all is to ensure that it handles the upstream API not being ready when the stream starts up. There is otherwise essentially no need to re-fetch the data.