Implement tab activity detection to optimize API calls

[Tanya-ruby]

Overview:

This resolves #105
Previously, the application was fetching the price at regular intervals, regardless of whether the user's tab was active or not. This approach led to reaching the daily limit of the free Infura API when deployed for Sepolia, as a single user could leave a tab open, consuming the limit.

Implemented a solution that detects whether the tab is active or not. The price update logic now only executes when the tab is active, significantly reducing the number of API calls and preventing the daily limit from being reached.

This change ensures that the application remains functional and efficient under the constraints of the free Infura API, while also improving the user experience by reducing unnecessary data fetching when the application is not in use.

Detailed Description:

Before Changes	After Changes

As shown in the images ,Previously, even when the tab was not active and the user had switched to another tab, there were 10 request methods being called every minute. This behaviour could easily lead to exceeding the API rate limit.

implementing a solution that involves detecting whether the tab is active. As a result, no requests (zero) are being made when the tab is not active.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
djed-solidity-web-dashboard	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 5, 2024 11:25pm

[ceilican]

there were 10 request methods being called every minute.

Could you show me where the frequency of calls is coded? It is probably hard-coded somewhere, but we should make it an environment variable.

[Tanya-ruby]

there were 10 request methods being called every minute.

Could you show me where the frequency of calls is coded? It is probably hard-coded somewhere, but we should make it an environment variable.

@ceilican Actually, I explored the Infura stats dashboard manually, and it became evident that 10 requests were being made if the user wasn't on the window, reference is in the first picture.If it is hardcoded somewhere then I will search for it and then make it an env variable.

[ceilican]

there were 10 request methods being called every minute.

Could you show me where the frequency of calls is coded? It is probably hard-coded somewhere, but we should make it an environment variable.

@ceilican Actually, I explored the Infura stats dashboard manually, and it became evident that 10 requests were being made if the user wasn't on the window, reference is in the first picture.If it is hardcoded somewhere then I will search for it and then make it an env variable.

@Tanya-ruby , I found the place that is causing the repeated calls. Have a look on lines 209 and 225 here (

Djed-Solidity-WebDashboard/src/context/AppProvider.jsx

Line 13 in f62ed2b

getCoinDetails,

). This is the place that we have to fix. Your PR should change AppProvider.jsx, instead of Ethereum.jsx.

Consider the following:

With your current PR, AppProvider is calling getCoinDetails repeatedly and getCoinDetails is having to check whether it should have been called. This ounds strange, doesn't it?

Intuitively, it should be the responsibility of AppProvider to check whether it should call getCoinDetails.

[Tanya-ruby]

there were 10 request methods being called every minute.

Could you show me where the frequency of calls is coded? It is probably hard-coded somewhere, but we should make it an environment variable.

@ceilican Actually, I explored the Infura stats dashboard manually, and it became evident that 10 requests were being made if the user wasn't on the window, reference is in the first picture.If it is hardcoded somewhere then I will search for it and then make it an env variable.

@Tanya-ruby , I found the place that is causing the repeated calls. Have a look on lines 209 and 225 here (

Djed-Solidity-WebDashboard/src/context/AppProvider.jsx

Line 13 in f62ed2b

getCoinDetails,

). This is the place that we have to fix. Your PR should change AppProvider.jsx, instead of Ethereum.jsx.
Consider the following:

With your current PR, AppProvider is calling getCoinDetails repeatedly and getCoinDetails is having to check whether it should have been called. This ounds strange, doesn't it?

Intuitively, it should be the responsibility of AppProvider to check whether it should call getCoinDetails.

@ceilican Yes, this makes sense ! I can create an useEffect hook to monitor changes in the document's visibility status. I can then modify the interval condition to isWalletConnected && isVisible ? COIN_DETAILS_REQUEST_INTERVAL : null.
Additionally, I can include a redundant check inside the callback function to ensure that any remaining scheduled intervals don't fetch data unnecessarily.
async () => { if (coinContracts == null || !isVisible) return;
What do you think about the redundant check inside the callback function?I find it will help if there are any remaining scheduled intervals.

[ceilican]

@Tanya-ruby , the hook idea seems to make sense. Let's try it.

I didn't fully understand the redundant check idea. If it is really redundant, then why is it necessary?

Anyway, if you submit a PR, it will be easier for me to understand.

[Tanya-ruby]

@Tanya-ruby , the hook idea seems to make sense. Let's try it.

I didn't fully understand the redundant check idea. If it is really redundant, then why is it necessary?

Anyway, if you submit a PR, it will be easier for me to understand.

The inner check provides an extra layer of safety to ensure data fetching only occurs if visibility is still favorable.
Suppose the interval is set to 10 seconds (COIN_DETAILS_REQUEST_INTERVAL).
The user starts fetching data but then switches tabs at the 9th second.
The asynchronous function would run but exit early due to the inner !isVisible check.

[ceilican]

@Tanya-ruby , the hook idea seems to make sense. Let's try it.
I didn't fully understand the redundant check idea. If it is really redundant, then why is it necessary?
Anyway, if you submit a PR, it will be easier for me to understand.

The inner check provides an extra layer of safety to ensure data fetching only occurs if visibility is still favorable. Suppose the interval is set to 10 seconds (COIN_DETAILS_REQUEST_INTERVAL). The user starts fetching data but then switches tabs at the 9th second. The asynchronous function would run but exit early due to the inner !isVisible check.

OK. I understood now. I think we don't need this redundant check. When the behavior you described occurs, it will occur only once, and that's OK. What we really need is to prevent the recurring API calls.

[ceilican]

Very elegant now!