perf: stop regenerating the UI token index on every deploy#1271
Merged
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…build The prebuild ran generateIndex.mjs on every Vercel deploy, hitting public RPCs + DefiLlama to enrich ~4200 tokens sequentially (~16 min per deploy, even for a one-line UI change). The metadata it fetches changes only when tokens change, not when the frontend does. Commit the generated index (public/data) and make prebuild --if-missing so the Vercel build reads it instead of regenerating it — deploys drop to a plain next build. The refresh workflow now regenerates the index and commits it back (on a real logo change and weekly for market caps), which triggers a normal, fast redeploy. A count guard refuses to commit a collapsed index if an RPC/DefiLlama outage degrades a run.
91e310b to
2079a76
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Every Vercel deploy of the UI ran
prebuild→generateIndex.mjs, which enriches ~4200 tokens by hitting public RPCs + DefiLlama sequentially (multicall chunks + mcap batches, one chain after another, with an 8s-timeout-plus-retry per chunk). Result: ~16 min per deploy, even for a one-line UI change. The metadata it fetches only changes when tokens change — not when the frontend does.Fix
Decouple index generation from the frontend build:
_config/ui/public/data) instead of gitignoring it.prebuild→generateIndex.mjs --if-missing: the script early-returns whenpublic/data/chains.jsonexists, so the Vercel build reads the committed index instead of regenerating it. Deploys drop to a plainnext build.ui-refresh.ymlnow regenerates AND commits the index back tomain, which triggers a normal (now fast) redeploy. The old deploy-hook POST is dropped.The refresh workflow
pushonmainfiltered totokens/**/logo.svg+chains/**/logo.svg(real logo adds/removes only — deliberately not the ~4-6×/day[bot] - Update listscommits, which touchtokens/*/list.json/_info.jsonand don't change the generated index), plus weekly (market-cap refresh) +workflow_dispatch.totalTokens< 1000 or drops >20% vs the committed baseline — an RPC/DefiLlama outage during the job can't ship a degraded index.GITHUB_TOKENpushes don't re-trigger workflows, and the committed data path (public/data/**) isn't in the trigger filter.permissions: contents: write(it pushes) +fetch-depth: 0(recency dates from git history).Behavior to know
Adding a token → Vercel deploys immediately with the old index (fast, token not listed yet) → the workflow regenerates + commits → a second fast deploy lists it. Two fast deploys instead of one 16-min deploy. The logo itself (CDN/jsDelivr) is served immediately regardless. A Vercel "Ignored Build Step" on
tokens/**could collapse this to one deploy later (dashboard config, not code).Verification
--if-missingearly-returns whenchains.jsonexists (generateIndex.mjs:370).Not measured on a real Vercel build (no access) — the speedup is proven by the mechanism (early-return + committed index present). The first deploy after merge will confirm the number.