Problem:
The front-end automatically updates at a very high frequency (every few seconds) even as the default time scale is 1 month. This is nonsense as it overloads the back-end and increases the cost of AWS services paid on the amount of data extracted.
The displayed data has also no relation to the data sent by the back-end, which currently contains 100% of scope 1 natural gas consumption in category "Emissions directes des sources fixes de combustion".
When the categories nomenclature is changed to something else than BEGES and back to BEGES, the behavior changes and data other than scope 1 remains equal to zero. Even though the donut looks right, the detail by category shown non zero data in other scope 1 categories than "Emissions directes des sources fixes de combustion" and the total amount still randomly adjusts.
Steps to reproduce:
1 - Connect to the dashboard
2 - Use the category nomenclature selector to chose GHG Protocol
3 - Use it again to show BEGES
4 - Observe the data shows 100% of emissions in scope 1 now, and periodic random and massive adjustments
5 - Click on the "scope 1" and observe non zero values for all the categories when only "Emissions directes des sources fixes de combustion" is expected to be non-zero
6 - Click on other scopes and observe absence of any value indication and full progress bars.
Expected behavior:
The front-end does not need to update data every few seconds: data from the previous month will not change!
When the end time of the date range is not "now", the front-end only requests data once.
When the end time of the data range is "now", assuming a UI mean to select that, that currently does not exist, the displayed data is regularly refreshed at a rate coherent with the time scale.
The front-end only calls the back-end on the passing of the aligned timescale index (at the hour which showing hourly data, on Monday at 0:00 when showing weekly data, etc.) and only requests data up to the last completed timescale unit (up to 16:00 if the current time is 16:23 and timescale is 1 hour). Note that to avoid an activity peak, each front-end should randomly pick a small random offset, apply it to the time scale and should delay calls slightly instead of calling the back-end smack on time.
Alternatively, the front-end requests data every minute but sets an If-Modified-Since HTTP header coherent with its current time scale, and the backend will return a code HTTP 304 Not Modified (requires a session cookie to memorize the previous filter settings).
The backend will reload:
If any model (emission factor) used in the selected time range has changed
Problem: The front-end automatically updates at a very high frequency (every few seconds) even as the default time scale is 1 month. This is nonsense as it overloads the back-end and increases the cost of AWS services paid on the amount of data extracted. The displayed data has also no relation to the data sent by the back-end, which currently contains 100% of scope 1 natural gas consumption in category "Emissions directes des sources fixes de combustion".
When the categories nomenclature is changed to something else than BEGES and back to BEGES, the behavior changes and data other than scope 1 remains equal to zero. Even though the donut looks right, the detail by category shown non zero data in other scope 1 categories than "Emissions directes des sources fixes de combustion" and the total amount still randomly adjusts.
Steps to reproduce: 1 - Connect to the dashboard 2 - Use the category nomenclature selector to chose GHG Protocol 3 - Use it again to show BEGES 4 - Observe the data shows 100% of emissions in scope 1 now, and periodic random and massive adjustments 5 - Click on the "scope 1" and observe non zero values for all the categories when only "Emissions directes des sources fixes de combustion" is expected to be non-zero 6 - Click on other scopes and observe absence of any value indication and full progress bars.
Expected behavior: The front-end does not need to update data every few seconds: data from the previous month will not change! When the end time of the date range is not "now", the front-end only requests data once. When the end time of the data range is "now", assuming a UI mean to select that, that currently does not exist, the displayed data is regularly refreshed at a rate coherent with the time scale. The front-end only calls the back-end on the passing of the aligned timescale index (at the hour which showing hourly data, on Monday at 0:00 when showing weekly data, etc.) and only requests data up to the last completed timescale unit (up to 16:00 if the current time is 16:23 and timescale is 1 hour). Note that to avoid an activity peak, each front-end should randomly pick a small random offset, apply it to the time scale and should delay calls slightly instead of calling the back-end smack on time. Alternatively, the front-end requests data every minute but sets an If-Modified-Since HTTP header coherent with its current time scale, and the backend will return a code HTTP 304 Not Modified (requires a session cookie to memorize the previous filter settings). The backend will reload: