Three private-api queries in the SDK refetch far more often than their data actually changes, and none of their responses can be reused by the browser between page loads. All three are global or per-post reads with no per-user component, so most of that traffic is avoidable.
Current state
| query |
file |
issue |
pro-members |
packages/sdk/src/modules/accounts/queries/get-pro-members-query-options.ts |
staleTime 5 min on a roster the comment itself describes as "changes slowly" |
announcements |
packages/sdk/src/modules/notifications/queries/get-announcements-query-options.ts |
staleTime is a sensible 1 h, but a cold cache on every fresh page load still refetches |
post-tips |
packages/sdk/src/modules/posts/queries/get-post-tips-query-options.ts |
POST for a read, and no staleTime (defaults to 0, so it is stale on every mount/refocus) |
post-tips is the structural one: because it is a POST with a JSON body, the response is uncacheable by the browser and by any intermediary, permanently. It takes author + permlink and returns tips for that post - a plain read.
Proposed
post-tips -> GET with author/permlink as query params, plus a staleTime. Needs a companion endpoint change in the private-api service; keep the POST accepted until clients have rolled.pro-members -> raise staleTime to ~30-60 min. Nothing about a badge roster needs 5-minute freshness.- All three -> have the endpoints send
Cache-Control: public, max-age=..., stale-while-revalidate=.... These payloads are identical for every visitor and need no auth, so the browser should be able to reuse them across page loads instead of re-requesting on each navigation.
staleTime alone only dedupes within one session; the Cache-Control part is what stops the repeat request on the next page load. Both are needed.
Notes
- SDK change ships first, then the web bump - see the usual release order.
- Worth checking whether mobile calls the same three endpoints before changing the
post-tips verb.
Three
private-apiqueries in the SDK refetch far more often than their data actually changes, and none of their responses can be reused by the browser between page loads. All three are global or per-post reads with no per-user component, so most of that traffic is avoidable.Current state
pro-memberspackages/sdk/src/modules/accounts/queries/get-pro-members-query-options.tsstaleTime5 min on a roster the comment itself describes as "changes slowly"announcementspackages/sdk/src/modules/notifications/queries/get-announcements-query-options.tsstaleTimeis a sensible 1 h, but a cold cache on every fresh page load still refetchespost-tipspackages/sdk/src/modules/posts/queries/get-post-tips-query-options.tsPOSTfor a read, and nostaleTime(defaults to 0, so it is stale on every mount/refocus)post-tipsis the structural one: because it is aPOSTwith a JSON body, the response is uncacheable by the browser and by any intermediary, permanently. It takesauthor+permlinkand returns tips for that post - a plain read.Proposed
post-tips->GETwithauthor/permlinkas query params, plus astaleTime. Needs a companion endpoint change in the private-api service; keep thePOSTaccepted until clients have rolled.pro-members-> raisestaleTimeto ~30-60 min. Nothing about a badge roster needs 5-minute freshness.Cache-Control: public, max-age=..., stale-while-revalidate=.... These payloads are identical for every visitor and need no auth, so the browser should be able to reuse them across page loads instead of re-requesting on each navigation.staleTimealone only dedupes within one session; theCache-Controlpart is what stops the repeat request on the next page load. Both are needed.Notes
post-tipsverb.