Is frequi consume an api designed to be used by telegram ? about frequi HOT 2 CLOSED

well if you consider the history of the RPC Components in freqtrade, it was originally developed for telegram, and only later adapted to provide similar answers as REST (that's why the REST APi is currently changing a lot ...).

Now i'm not sure what exactly it is you disagree with specifically - balance / open (and closed) trade view and /whitelist seem fine to me to do "daily operations".

Also, trade endpoints (open / closed trades) do provide the full database object (with small deviations for open trades) - so everything we want should be possible based on this data.

However, what i'd like to avoid is to do too much logic in the UI - but have most calculations done in the backend, so other RPC methods (speak telegram) can benefit from it eventually.

However, new endpoints (also rest-only endpoints without a telegram counterpart) can be added to freqtrade as necessary - but so far i've not encountered anything that's "completely missing" - most parts just miss some information, or provide it in a biased format (timestamps formatted for human eyes...).

One thing that might be worth to point out here is that vuex contains more information than what is currently shown - you can inspect that using the vue extension in chrome (for example).

However, another point is also terminology - define Dashboard for me (what it is for you)?

For me, a dashboard is something you look at after the fact, visualizing you summary statistics and KPI's about things that already happened.

A dashboard however does not necessarily give you real time insights into bot operations, nor does it allow you to control operations ... so whenever you say "dashboard" - my first thought is "FreqUI is not a dashboard, but a UI to control the bot" ...

from frequi.

As explained above - the API started as a copy of the telegram telegram, so it was not made for a real application.
Since there was no official consumption layer for the API other than the standalone script, it was functional but design was partially lacking.

We're now slowly moving it towards a better API design, with aligned fieldnames to make it easier to be consumed by frequi as issues come up, so i'll close this as i agree in principle - but it's up to us to improve the API layer over time :)

from frequi.