Most validation logic (IBAN, VAT, phone, email, credit card format) is language-agnostic — it's just string parsing and checksums. So why did I build it as an HTTP API instead of a JS library?
A few reasons that mattered to me:
- Polyglot by default. An HTTP API works from Python, Go, Ruby, whatever — a JS package only works in JS projects.
- No dependency upgrades to babysit. libphonenumber's metadata changes as countries update numbering plans; that's my problem to keep current, not every consumer's.
- The VIES/MX-record/breach-check lookups need a server anyway. Those aren't pure functions — they're network calls. Once you need a server for those, you may as well put the offline checks behind the same API for consistency.
The tradeoff is obviously latency — a network round-trip beats a local function call every time. For anything on a hot path doing thousands of validations per second, a local library is the right call. For "validate this form submission once," the API overhead is noise.
If you want to see the actual shape of it: Validate on RapidAPI — free tier, no card required. Source structure is public too: https://github.com/Jay-Ecommerce/validate-api. Same account also runs QR API and Currency API.
Top comments (0)