Frankencoin-ZCHF / frankencoin-dapp

Frankencoin Web App to interact with the Eco System
https://frankencoin.com/
MIT License
0 stars 4 forks source link

Too many requests #34

Closed luziusmeisser closed 1 month ago

luziusmeisser commented 2 months ago

We should move to the latest version of wagmi, monitor the number of requests we are issuing and check with walletconnect why we see this error.

image

Strangely, our API usage in cloud.walletconnect.com is 0 despite the url having the correct project id in its requests:

image

It also looks like some requests connect to cloudflare-eth.com, which is the default provider for viem, which is often used in concert with wagmi, but apparently requires its own configuration.

samclassix commented 1 month ago

These are my discoveries so far

Currently, there are some adverse side-effects associated with fetching data or making API calls within React components. React components should "primarily" focus on rendering and remain detached from such tasks. Whenever React refreshes a component that implements data fetching or API calls, it automatically triggers these actions, leading to potential issues. At a certain scale, Wagmi encountered a '429 Too Many Requests' error response. As a workaround, it switched to the backup service provided by cloudflare-eth.com, attempting to request the same data as before.

We could consider following steps:

Those changes will eliminate the constant and unnecessary fetching of data, which is highly likely to have remained unchanged.

When might our data have changed?

Given our reliance on the Ethereum blockchain, any relevant changes to our data could occur with each new block.

Wagmi implements a roughly 5sec fetching interval for the latest block height (eth_blockNumber):

Screenshot 2024-05-11 at 8 58 14 AM

{
    "jsonrpc": "2.0",
    "id": 548, // request id
    "method": "eth_blockNumber"
}

Component called BlockUpdater

To stay updated with the latest block height changes, let's introduce a new component called BlockUpdater. This component will execute a one-time solution for fetching new block states for the application, employing either a Full Update or Lazy Loading approach.

import { useBlockNumber } from "wagmi";
import { useEffect } from "react";

export default function BockUpdater() {
  const {error, data} = useBlockNumber();

  useEffect(() => {
    if (error) return
    console.log(`New block found: ${data}`);
    // call redux slice A fetch
    // call redux slice B fetch
    // call redux slice C fetch
    // call redux slice D fetch
   }, [error, data])

  return <></>;
}

Get state from store

Each component requiring access to the Redux store retrieves data from the store or slices using the useSelector hook and object tree parameter. e.g.:

import React from 'react'
import { useSelector } from 'react-redux'

export function Counter() {
  const count = useSelector(state => state.counter.value)
...
samclassix commented 1 month ago

Update Development and Testing

Screenshot 2024-05-16 at 6 29 52 PM

Screenshot 2024-05-16 at 6 31 46 PM

Screenshot 2024-05-16 at 6 31 02 PM

EACH BLOCK Update Policy

10 BLOCKS Update Policy

ERC20Infos

aka. all relevant ERC20 token addresses atm: all mintable (ZCHF), all collateral token used in positions

ADDRESS CHANGES Update Policy

Improvement

Before

After

Improvements and performance improvements are enormously!

Screenshot 2024-05-16 at 6 43 56 PM

Positions filtered by collateral and originals

No need to fetch data at the positions page, and you have access to all position data stored in the redux store.

Screenshot 2024-05-16 at 6 08 18 PM
samclassix commented 1 month ago

Network Traffic over time

Screenshot 2024-05-16 at 7 08 37 PM
samclassix commented 1 month ago

Controlled Fetching and Enforced Update Policies

Screenshot 2024-05-16 at 7 16 43 PM
samclassix commented 1 month ago

should be solved with current state of dev branch. As soon its stable and testing went well, it should be applied to main to stop flooding with requests until the api access key limits are exhausted. If limits are reached, testing on dev does not work neither, because the main and dev applications share the same api keys. @luziusmeisser can we have a separate walletconnect api for dev namespace, it would improve development and testing by separating both namespaces also with api key. Also good for tracking.

luziusmeisser commented 1 month ago

Maybe we should move all api calls to alchemy so we have all the stats in one place? Feel free to setup different keys there (production frontend, dev frontend, production ponder, dev ponder).