Parse Don’t Validate en Rust: Type-Driven Design para SaaS

El Problema de Validar sin Garantías

En el desarrollo de software, uno de los errores más comunes es validar datos en un punto del código pero asumir que esas validaciones se mantienen en todo el flujo de ejecución. Imagina una función que verifica que un número no sea cero antes de usarlo como divisor, pero esa verificación ocurre en una capa diferente a donde se ejecuta la división. Este desacoplamiento genera bugs sutiles y difíciles de rastrear en producción.

El patrón Parse, Don’t Validate propone una solución elegante: en lugar de validar datos repetidamente en diferentes puntos del código, transformamos (parseamos) los datos una sola vez en tipos que codifican las invariantes directamente en su estructura. Una vez que un valor ha sido parseado exitosamente, el sistema de tipos del lenguaje garantiza que cumple con todas las restricciones necesarias.

Type-Driven Design en Rust: Haciendo Imposibles los Estados Inválidos

Rust es particularmente adecuado para implementar este patrón gracias a su sistema de tipos robusto y la capacidad de crear newtypes (tipos nuevos envolventes) sin costo adicional en tiempo de ejecución. El principio fundamental es: hacer que los estados inválidos sean irrepresentables en el sistema de tipos.

Ejemplo Práctico: División Segura

Considera el problema clásico de la división por cero. En un enfoque tradicional de validación, podrías escribir:

fn dividir(numerador: i32, denominador: i32) -> Result<i32, Error> {
  if denominador == 0 {
    return Err(Error::DivisionPorCero);
  }
  Ok(numerador / denominador)
}

Este código valida, pero cada vez que quieras dividir, necesitas verificar el resultado. Con Type-Driven Design, en cambio, creas un tipo que garantiza que nunca será cero:

pub struct NonZeroI32(i32);

impl NonZeroI32 {
  pub fn new(valor: i32) -> Option<Self> {
    if valor != 0 {
      Some(NonZeroI32(valor))
    } else {
      None
    }
  }
}

fn dividir_seguro(numerador: i32, denominador: NonZeroI32) -> i32 {
  numerador / denominador.0
}

Ahora, dividir_seguro no puede fallar porque el sistema de tipos garantiza que el denominador nunca será cero. La validación ocurre una sola vez, al construir el NonZeroI32, y después el compilador hace el trabajo pesado.

Beneficios Concretos para Startups y SaaS

Para founders técnicos que construyen productos escalables, este patrón ofrece ventajas tangibles:

1. Menos bugs en producción: Los errores de validación se detectan en tiempo de compilación en lugar de tiempo de ejecución. Esto reduce drásticamente los incidentes críticos que afectan a usuarios.

2. Código más mantenible: Las invariantes están documentadas en el sistema de tipos. Un nuevo desarrollador que se una al equipo puede entender las restricciones simplemente leyendo las firmas de las funciones.

3. Performance sin sacrificar seguridad: Los newtypes en Rust tienen costo cero en runtime gracias a las optimizaciones del compilador. Obtienes las garantías de seguridad sin penalización de rendimiento.

4. APIs más claras: Cuando tu API pública usa tipos como NonEmptyVec<T> o ValidEmail, los consumidores de tu código saben exactamente qué esperar sin necesidad de leer documentación extensa.

Casos de Uso Reales en Aplicaciones Modernas

Validación de Emails y Datos de Usuario

En lugar de validar emails con expresiones regulares en cada endpoint, crea un tipo ValidEmail que solo puede construirse si el string pasa la validación:

pub struct ValidEmail(String);

impl ValidEmail {
  pub fn parse(email: &str) -> Result<Self, ValidationError> {
    if email.contains('@') && email.len() > 3 {
      Ok(ValidEmail(email.to_string()))
    } else {
      Err(ValidationError::InvalidEmail)
    }
  }
}

Ahora, cualquier función que acepte ValidEmail como parámetro puede operar con total confianza de que el dato es válido.

Colecciones No Vacías

Para operaciones que requieren al menos un elemento (como calcular el promedio de una lista), un tipo NonEmptyVec elimina checks redundantes:

pub struct NonEmptyVec<T> {
  head: T,
  tail: Vec<T>,
}

Esta estructura hace imposible representar una lista vacía por diseño.

Deserialización y Parsing de JSON

Cuando consumes APIs externas, en lugar de validar cada campo después de la deserialización, define tipos que solo pueden construirse si los datos cumplen las invariantes. Bibliotecas como serde en Rust se integran perfectamente con este patrón.

Comparación con Otros Lenguajes

Si bien el patrón Parse, Don’t Validate se originó en la comunidad de programación funcional (especialmente en Haskell y Elm), Rust lo hace particularmente práctico gracias a:

• Costo cero de abstracción: Los newtypes se optimizan completamente en compilación.
• Ownership y borrowing: Rust añade garantías adicionales sobre la vida útil y mutabilidad de los datos.
• Macros y derives: Puedes automatizar la generación de código repetitivo para parsing y validación.

Lenguajes como TypeScript también pueden implementar patrones similares con tipos branded, pero sin las garantías en runtime que ofrece Rust. En Python o JavaScript tradicional, estas validaciones requieren bibliotecas adicionales y disciplina del equipo.

Mejores Prácticas para Implementar Este Patrón

1. Parsea en los bordes del sistema: Valida datos lo más cerca posible de donde ingresan a tu aplicación (endpoints HTTP, parsers de archivos, etc.). Una vez dentro, trabaja con tipos validados.

2. Usa Result y Option apropiadamente: Las funciones de parsing deben retornar Result<ValidType, Error> para manejar casos de fallo explícitamente.

3. No abuses de los newtypes: Úsalos cuando codifican invariantes valiosas, no para cada campo de datos. El equilibrio entre seguridad y ergonomía es clave.

4. Combina con el principio de Least Privilege: Si una función solo necesita leer un valor validado, pasa una referencia inmutable en lugar del tipo completo.

5. Documenta los invariantes: Aunque los tipos comunican mucho, comentarios que expliquen por qué existe una restricción ayudan a nuevos desarrolladores.

Lecciones para Founders Técnicos

Implementar Type-Driven Design requiere una inversión inicial de tiempo en diseñar tus tipos cuidadosamente, pero el retorno es exponencial:

• Escalabilidad del equipo: Nuevos desarrolladores cometen menos errores porque el compilador los guía.
• Refactoring seguro: Cambios en invariantes se reflejan automáticamente en todo el código que las usa, generando errores de compilación en lugar de bugs silenciosos.
• Menor deuda técnica: El código expresivo y con garantías de tipos envejece mejor que el código con validaciones dispersas.

Para startups que compiten en velocidad y calidad, especialmente en sectores regulados (fintech, healthtech), este patrón puede ser la diferencia entre un producto robusto y uno que genera incidentes costosos.

Conclusión

El patrón Parse, Don’t Validate combinado con Type-Driven Design en Rust representa un cambio de paradigma: en lugar de confiar en disciplina humana para validar datos repetidamente, delegamos esa responsabilidad al compilador. Los newtypes y el sistema de tipos de Rust permiten codificar reglas de negocio como restricciones que se verifican automáticamente, reduciendo bugs, mejorando la claridad del código y manteniendo un rendimiento óptimo.

Para founders técnicos que construyen productos de software críticos, adoptar estos principios no es solo una mejora técnica, es una ventaja competitiva. Menos tiempo apagando incendios en producción significa más tiempo construyendo features que tus usuarios necesitan.

Fuentes

1. https://www.harudagondi.space/blog/parse-dont-validate-and-type-driven-design-in-rust/ (fuente original)
2. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
3. https://doc.rust-lang.org/book/ch19-04-advanced-types.html