I've taken a quick look at the code, and a few things come to mind. First, that 144 is pretty arbitrary: since EMA is a recursive calculation, its accuracy is very dependent on the number of samples. After a certain point it becomes less relevant since the further you go back, the less the weight given to the data, but 200 * whatever timeframe you're trading is a generally accepted sample size. I remember someone complaining that the initial sample size was not accurate enough so Piotr increased it to 144 which should be an ok compromise, but it won't hurt if you have more.

So you could either keep making these 144 requests of 1000 trades and then divide that by your trading sample size, which would give you about 10 times more candles to back your calculations on, or you can make that 144 dynamic by making requests with a timestamp equal to (number of samples required for accuracy x trading sample size) instead of this fixed 144. In other words, fetch only as much as you need according to your sample size instead of making an arbitrary number of requests. This fixed value made sense when the original bot only dealt with H1 trading and needed 144H of backdata, but not so much now that you allow users to define the trading candle size.

Also, this history and its subsequent updated candles should probably be cached into localstorage until next launch. Since for a 60m candle you're fetching about 5 days worth of history, chances are that some of that data will still be valid on next bot launch, and that would also prevent from refetching everything upon a simple change of parameters.