## Where does the work happen?

Three practical options — rate limits and CORS are the real constraints

A

### Full WASM, client-side

Compile the `onym` crate to WASM. Browser fetches registries directly.

[ browser + WASM ] ──▶ crates.io / pypi / npm / rdap
[ browser + WASM ] ──▶ api.github.com

#### Pros

- Zero infra, zero cost
- Rate limits burn user's IP, not yours
- Same Rust code as the CLI
- Privacy: no server sees queries

#### Cons

- CORS: registries mostly OK, but github.com HEAD is blocked — must switch to api.github.com (60/hr unauth)
- RDAP CORS varies by TLD
- Bundle size ~500KB–1MB gzipped

B

### Edge proxy (Cloudflare Worker)

Tiny stateless function fans out to registries, returns combined JSON. Cache popular names for ~1h.

[ browser ] ──▶ [ CF Worker + KV cache ] ──▶ registries

#### Pros

- Zero CORS problems
- Shared cache = popular names are instant + cheap
- Can authenticate GitHub requests for higher limits
- Tiny surface, free tier (100k req/day)

#### Cons

- Your IP hits registries — rate limit risk if it goes viral
- Worker is a second codebase (TS or Rust-on-Worker)
- Needs an abuse guardrail (per-IP limit)

C

### Hybrid: WASM + thin fallback proxy

WASM handles CORS-friendly sources (crates.io, pypi, npm, most RDAP). A tiny proxy only for GitHub + CORS-blocked TLDs.

[ browser + WASM ] ──▶ crates.io / pypi / npm / rdap (direct)
[ browser + WASM ] ──▶ [ proxy ] ──▶ github.com

#### Pros

- Most work stays in the browser (no rate limit exposure)
- Proxy only needed for 1–2 sources
- Showcases WASM as a feature ("it's the CLI, in your browser")

#### Cons

- Still need a proxy (but minimal)
- Two code paths to reason about
- Slightly more complex to ship

My lean: C — Hybrid. Keeps the "rate limits aren't my problem" story mostly intact, but you don't have to fight CORS on github.com. Click a card if you agree, or tell me in the terminal.