Normadata vs. validator.js: API que mantenemos vs. librería que mantenés vos
validator.js es una librería excelente. Normadata es la API que cubre lo que validator.js no: tax IDs LATAM, normalización LATAM, schema versionado.
validator.js es la librería NPM open-source más usada para validar strings — emails, URLs, UUIDs, IBAN básico, y mucho más. Es un standard de facto para la stack JavaScript. Normadata es una API que cubre validaciones específicas de LATAM que validator.js no resuelve nativamente: CUIT, CPF, CNPJ, RFC con homoclave, RUT chileno con K, NIT colombiano, RUC peruano. La comparación correcta no es 'cuál es mejor' sino 'qué cubre cada uno y cómo se combinan'.
Comparación rápida
| Aspecto | validator.js | Normadata |
|---|---|---|
| Etapa del pipeline | Validación de strings client-side / server-side | Validación de identificadores LATAM como servicio |
| Qué hace principalmente | Email, URL, UUID, IP, IBAN básico, BIC, regex helpers — mucho | Tax IDs LATAM con algoritmos por país, nombres, address LATAM |
| Modelo de pricing | Open-source MIT — gratis, vos lo mantenés | Acceso anticipado — sin pricing público |
| SDKs | Librería NPM — JavaScript / TypeScript | REST + JSON, sin SDK — multi-lenguaje |
| Estilo de API | Funciones puras: isEmail(s), isUUID(s)… | REST batch: POST /v1/validate/tax-ids devuelve {results} en JSON |
| Cobertura LATAM tax IDs | Mínima — algunos países sueltos sin actualización garantizada | Cobertura multi-país LATAM, tax IDs con algoritmos correctos |
| Persistencia de datos | N/A — corre en tu proceso | No persiste PII en el pipeline de validación |
| Certificaciones tipo SOC 2 / ISO | N/A — librería local | En roadmap |
| Profundidad de KYC | Ninguna | Ninguna — Normadata no es KYC |
| Orientación de desarrollo | Librería embedded — vos parchás los bugs | Servicio gestionado: nosotros mantenemos las reglas |
| Buyer típico | Cualquier proyecto JS — npm install y listo | Equipo que necesita reglas LATAM correctas sin mantenerlas |
¿Cuándo usar cada uno?
- Estás en el stack JavaScript y necesitás validaciones genéricas: email, URL, UUID, IP.
- Querés cero dependencias externas y cero llamadas de red.
- Tu producto no tiene foco LATAM y no necesitás CPF/CUIT/RFC con algoritmos por país.
- Estás dispuesto a mantener vos los parches y actualizaciones cuando reglas cambien.
- Necesitás validar tax IDs LATAM con los algoritmos correctos: doble Mod-11 del CPF, K del RUT chileno, homoclave del RFC.
- Querés un servicio gestionado donde el vendor mantiene las reglas cuando cambian (nuevos prefijos de móvil, cambios en formato de tax ID).
- Necesitás multi-lenguaje (TypeScript, Python, Go, Java, Ruby) y no querés portar la librería a cada uno.
- Querés normalización de nombres LATAM (apellido paterno/materno) y address LATAM (estado a ISO 3166-2).
El problema con embedder reglas LATAM en una librería
Las reglas de tax IDs LATAM cambian: Argentina actualiza prefijos de CUIT, Brasil libera nuevos rangos de CNPJ, México ajusta la generación de homoclave del RFC. Una librería embebida en tu app necesita un release, un PR review, un deploy, y propagación a todos los servicios que la consumen. Una API gestionada absorbe el cambio en un único deploy del vendor sin tocar tu código. Si tu producto vive de validar tax IDs LATAM correctos, la diferencia operacional es real.
validator.js es genuinamente excelente en lo suyo
Para validación de email, URL, UUID, IP, BIC, IBAN básico — validator.js es difícil de batir. Es maintenido, tiene tests, está embedded en miles de stacks. Si lo único que necesitás es validar email genérico en un proyecto JS, validator.js es la respuesta correcta. Normadata no compite ahí: resuelve tax IDs, personas, cuentas financieras y direcciones de LATAM con un único endpoint para limpiar todo el formulario.
Schema versionado: una API tiene contrato, una librería tiene semver
Cuando una librería tiene breaking changes, vos tenés que actualizar package.json, leer el changelog, refactorear. Cuando una API tiene breaking changes, mantiene /v1 estable y publica /v2 — vos migrás cuando querés. El compromiso de Normadata es mantener /v1 con backward compatibility por un horizonte largo. Eso es difícil de garantizar con una librería que recibe contribuciones de la comunidad.
validator.js es gratis y vive en tu proceso (cero latencia, cero costo, cero dependencia externa). Normadata cobra (pricing post-beta no definido), añade una llamada de red (latencia y disponibilidad dependen del vendor), y todavía está en acceso anticipado sin SLA contractual. Si tu volumen es bajo y tu necesidad LATAM es mínima, validator.js gana en simplicidad.
Preguntas frecuentes
¿Normadata puede reemplazar validator.js completamente?
Para tax IDs e identidades LATAM sí. Para UUID, BIC, email genérico o regex helpers no — validator.js cubre cosas que Normadata no implementa porque ya están bien resueltas en open source.
¿Cuándo conviene usar ambos?
Cuando tu stack es JS, usás validator.js para validaciones genéricas (UUID, URL, regex), y Normadata para identificadores LATAM (CUIT, CPF, RFC). Es un patrón común y sano.
¿Cuál es más barato?
validator.js es gratis. Normadata todavía no tiene pricing público. La pregunta correcta es el costo total: librería + tiempo de mantenimiento + bugs LATAM mal resueltos vs. API con reglas correctas mantenidas por el vendor.
¿Dónde validator.js gana sobre Normadata?
Costo cero, cero latencia, cero dependencia externa, comunidad madura, ecosistema masivo. Si tu necesidad es JS-only y no LATAM, validator.js es la elección obvia.