¿Frontend o Backend, dónde debería escribir las validaciones?

Cuando se trata de desarrollo de aplicaciones web, un debate recurrente entre programadores de backend y frontend es, ¿dónde debemos realizar la validación de datos, en el frontend o en el backend? Esta cuestión se torna aún más crucial cuando se busca un equilibrio entre ofrecer una óptima experiencia de usuario y garantizar la seguridad de la aplicación.

El Escenario

Imaginemos un formulario común que requiere que el usuario introduzca su número de teléfono y país, para posteriormente ser procesado por nuestra API. En un escenario ideal, el backend se presenta como lider absoluto, con herramientas como la librería google-libphonenumber, asegurando que cada dato ingresado cumpla con los estándares requeridos. Pero, ¿qué sucede cuando se propone incluir la misma rigurosidad en el frontend? porque al ser una librería javascript, se puede utilizar en ambos lados.

Validación en el Frontend

Validar en el frontend ofrece ventajas palpables:

1. Respuesta Inmediata: El usuario recibe un feedback instantáneo, mejorando su experiencia.
2. Eficiencia: Se reduce el tráfico innecesario al backend y se ahorran recursos.

No obstante, el frontend tiene su talón de Aquiles:

• La seguridad es frágil, y usuarios con intenciones maliciosas pueden burlar estas validaciones.

Validación en el Backend

El backend, por otro lado, ofrece:

1. Seguridad Robusta: Centraliza la validación, evitando posibles ataques o errores.
2. Consistencia: Garantiza que todos los datos sean válidos y consistentes.

Sin embargo, conlleva desafíos:

• Puede resultar en una experiencia de usuario menos fluida debido a tiempos de respuesta más prolongados.

NOTA: Aunque siendo honesto, los tiempos de respuesta entre una validación del front o del back, son apenas milisegundos, por lo que quizás no se debería considerar como una limitación debido a las implicaciones de seguridad y la importancia de los datos.

¿Tiene sentido duplicar las validaciones?

1. Desde una perspectiva de UX: Sí, porque puedes dar un feedback inmediato al usuario en el frontend y asegurarte de que los datos son correctos en el backend.

2. Desde una perspectiva de seguridad: No, porque una validación realizada desde el frontend puede ser alterada fácilmente ya que podemos modificar el código cliente justo antes de enviar los datos al backend.

3. Desde una perspectiva de mantenimiento: Puede ser problemático, ya que duplicar lógica puede complicar futuras actualizaciones; y aún más complejo con aplicaciones grandes y equipos rotando donde pequeños detalles como este podrían ocasionar que se actualice la validación en un lugar y no en otro.

Encontrando el Equilibrio

La solución no reside en elegir un lado sobre el otro, sino en armonizar ambos. El frontend puede encargarse de validaciones básicas, como longitud, uso de caracteres indebidos y formato en general, garantizando que el usuario reciba retroalimentación inmediata. El backend, con su robustez, se asegura de que todos los datos sean correctos y seguros.

La clave está en una comunicación efectiva entre ambos extremos. Si el backend identifica un problema, este debe ser comunicado claramente al frontend, quien a su vez debe informar al usuario adecuadamente.

Generalmente, al diseñar APIs y realizar validaciones en el backend, aparte de retornar un error, un estado de transferencia, es buena práctica retornar el campo que ha fallado, por ej.:

Imagina que este ha sido el request:

{
    "phone": 1234567890
}

Después de pasar por una validación en el backend, este podría ser el responseÑ

{
    "statusCode": 400,
    "message": "An error ocurred, please see details",
    "internalCode": "invalid_request_error",
    "details": [
        {
            "field": "phone",
            "message": "phone number is not allowed",
            "path": [
                "phone"
            ]
        }
    ]
}

De tal forma que el frontend al recibir este mensaje de error con status 400, inmediatemente podría saber que se trata de un error en la petición y al examinar la respuesta y encontrar con que se encuentra una propiedad llamada details, podría fácilmente identificar el campo que ha fallado y si ese campo tiene el mismo nombre en el frontend, eso ayudaría a establecer el error junto al campo que se ha marcado como erróneo.

Conclusión

La decisión de dónde implementar la validación de datos, ya sea en el frontend, backend o en ambos, no debe tomarse a la ligera. Al abordar esta cuestión con un enfoque lógico y basado en evidencias, podemos diseñar sistemas que sean tanto eficientes en su operación como robustos en su seguridad. Es imprescindible que los desarrolladores mantengamos una comunicación fluida y comprendamos las ventajas y limitaciones de cada enfoque, para así ofrecer soluciones que cumplan con los estándares más altos de calidad y protección.

He escuchado comunmente decir, "yo creo que" o "me gusta así", pero en realidad no se trata de corazonadas o de gustos, siempre se debe de tratar de elegir la forma más segura, menos compleja.

Happy coding! :D

Photo by James Yarema on Unsplash