Discuss: transaction fetching optimization strategy

[nop33]

Let's improve the explorer backend load by discussing our current tx fetching/caching strategy in our apps (mobile/desktop/extension wallets & explorer).

There are 2 main UI components where our apps display transactions:

1. Address transactions list
2. Aggregated wallet transactions list

1. Address transaction list

Found in:

• Explorer "Address page"
• Extension wallet "Account Activity" tab
• Desktop wallet "Address details modal"

Click to see screenshots

Explorer "Address page"	Extension wallet "Account Activity" tab	Desktop wallet "Address details modal"

2. Aggregated wallet transaction list (txs from all wallet addresses together)

Found in:

• Mobile wallet "Transfers tab"
• Desktop wallet "Overview page"
• Desktop wallet "Transfers page"

Click to see screenshots

Mobile wallet "Transfers tab"	Desktop wallet "Overview page"	Desktop wallet "Transfers page"

Desktop wallet

The DW uses Tanstack for query fetching, retrying, and caching (persistence).

The API data live in 2 places:

1. Tanstack query memory (RAM)
2. Persisted cache (HD)

Data fetching strategy overview

1. User launches the app. Tanstack query memory is empty.
2. User unlocks a wallet:
   1. App hydrates Tanstack queries memory with the persisted query cache.
   2. Cached data displayed in UI.
3. For every wallet address the app fires the query GET /address/{addressHash}/transactions?page=1&limit=1 (soon will be updated to GET /address/{addressHash}/latest-transaction)
4. If any of the responses do not match the cached value, the following endpoints will be called:
   1. GET /address/{addressHash}/balance
   2. GET /addresses/{addressHaash}/tokens-balance
   3. POST /addresses/transactions?page=1&limit=5 (if the user goes/is to the Overview page)
   4. POST /addresses/transactions?page=1 (if the user is in Transfers page and clicks "Click to see new transactions")
   5. GET /addresses/{addressHash}/transactions?page=1 (if the user clicks on the "Click to see new transactions" in the address details modal)

Mobile wallet

TBD

Explorer

TBD

[nop33]

Why POST /addresses/transactions was introduced

The POST /addresses/transactions was introduced when we realized that relying on the GET /addresses/{addressHash}/transactions was insufficient. Requesting the 1st page of each address of a wallet might result in gaps in the transaction list.

Click here to see why.

Assuming a wallet with 2 addresses:

1. GET /addresses/{ADDRESS_1}/transactions might return 20 txs where the oldest is today
2. GET /addresses/{ADDRESS_2}/transactions might return 20 txs where the oldest is 1 year ago

Merging these 2 lists would create gaps in the aggregated tx list (all txs between today and 1 year ago).

That's when the POST endpoint was introduced. It accepts an array of addresses and returns a paginated array of txs, without gaps.