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.