vccs
Vue 3용 차트 컴포넌트 모음, Recharts에서 포팅
수천 건의 1·2성 앱스토어 리뷰를 불만 별로 정리, 모든 수치와 인용문이 실제 리뷰입니다
Thousands of one- and two-star App Store reviews, sorted into the complaints that keep coming back. Every count is real and every quote is a real review.
데이터TypeScript · CSSGitHub @antionmil온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기The complaints inside a thousand one-star App Store reviews, counted and quoted. Day 5 of onedaybuilt.com.
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
What people actually hate about the apps they use every day.
Apple publishes a public feed of one- and two-star App Store reviews. This site
reads them, groups them into the complaints that keep coming back, and prints a
real count and a real quote beside each one. Day 5 of a 26-day run.
Live at onestarreader.onedaybuilt.com.
A watched app has a name, a genre and a score. A read app also has its
complaints. The gap between those two numbers is the whole engineering problem
below.README 전문 보기 ↗What people actually hate about the apps they use every day.
Apple publishes a public feed of one- and two-star App Store reviews. This site reads them, groups them into the complaints that keep coming back, and prints a real count and a real quote beside each one. Day 5 of a 26-day run.
Live at onestarreader.onedaybuilt.com.
| Watched | ~11,800 apps, from every genre chart in four storefronts |
| Read | the apps whose review feed a collector has reached |
| Storefronts | United States, Germany, Britain, France |
| Model | claude-haiku-4-5, Batch API, for grouping and translation only |
A watched app has a name, a genre and a score. A read app also has its complaints. The gap between those two numbers is the whole engineering problem below.
Both were measured, not assumed. Both measurements are in
src/lib/apple.ts and src/lib/schema.ts next to the code they explain.
The review feed hands out fifty reviews a page, ten pages deep — a hard ceiling of 500 per app per storefront — and rations that to roughly one page per address every ten minutes. A throttled request returns HTTP 200 with an empty feed, not an error, so a site that trusts it publishes "no complaints" when it means "we were blocked". Every attempt is recorded, answered or not.
The lookup endpoint gives a score, a rating count and a version. It answers one request instantly from anywhere, including datacentre addresses. Asked 45,000 times from one address it refuses about three in four, and asking more slowly does not help: five a second and forty a second were refused at the same rate. The lever is the address, not the pace.
So neither feed is collected from Vercel. Both run as scheduled GitHub Actions, four shards each, because a fresh runner is a fresh address:
.github/workflows/collect.yml — reviews, every 15 minutes, 14 pages a shard.github/workflows/ratings.yml — scores, hourly, 900 pairs a shardwatch holds the app/storefront pairs worth asking about — where the app
actually charted, plus all four storefronts for anything somebody requested.
That is 20,124 pairs instead of the 47,192 a blind cross join produces, and
27,000 questions a night that could never have had an answer.
apps.slug, unique index, filled by fillSlugs(). Five apps here are called
McDonald's and 62 have names written entirely in Chinese, Arabic or Japanese
that reduce to an empty string. Deriving a URL from a name in the browser — as
the search box did — sends a reader to another company's page.
Neon's free plan allows 5 GB of egress per project per month. Past it the
whole project answers HTTP 402 — reads, writes, psql, pg_dump — until the
first of the next month, and the data cannot be exported to escape.
This site walked into it on 12 September with 5.95 GB in ten days. The cause
was snapshot() reading the whole database on every cold render: 11,798 apps,
40,000 rating rows and every quoted review, about 14 MB, to draw two hundred
pages that needed a fiftieth of it.
Every query in that snapshot is now anchored to the apps that actually have
complaints, and review bodies are clipped in SQL rather than in the browser —
roughly 14 MB down to 2.5 MB. A watched app's page is one small query of its
own (watchedApp()), because eleven thousand pages nobody has asked for should
not be held in memory so that a handful can be visited.
Check the number with:
neon api "/projects/holy-bread-39202992"
data_transfer_bytes against 5e9, synthetic_storage_size against 0.5e9.
Free except the model. Grouping and translating everything read so far has cost about $0.63 in total, at Batch API rates. No model is ever called while somebody waits; the site only reads what the cron has already written.
pnpm install
cp .env.example .env.local # DATABASE_URL, ANTHROPIC_API_KEY, CRON_SECRET
pnpm db:push
pnpm dev
Scripts import server-only, so they run under
tsx --conditions=react-server:
| Script | What it does |
|---|---|
scripts/import-charts.mts | walks 224 genre charts, fills apps and watch |
scripts/ratings.mts | one turn of the score rotation |
scripts/collect.mts | one shard of the review collector |
scripts/cluster.mts | groups complaints via the Batch API (--stale for new reviews only) |
scripts/translate.mts | translates the quoted reviews |
scripts/slugs.mts | gives new apps their URL |
packageManager is pinned to [email protected] and pnpm.onlyBuiltDependencies
is set — without both, Vercel guesses a pnpm version and the install can exit 1
on a repo that builds locally every time. Neon is in Frankfurt and
vercel.json pins fra1; a mismatched region puts a transatlantic hop on
every query. Reads and writes go through a server-only module.