Resumen : ¿debo usar express-validator si puedo validar datos usando el esquema de mangosta?
Soy un desarrollador front-end, y generalmente realizo algunas validaciones en el formulario antes de enviarlo. Ahora, he comenzado a estudiar express.
Una de las primeras cosas que hice fue recibir un formulario y validarlo usando una biblioteca llamada express-validator, luego se realizaron las operaciones de la base de datos. muy simple, no es gran cosa. Sin embargo, después de hacer un proyecto por mi cuenta, me di cuenta de que Mongoose podía manejar los errores, no solo eso, sino que era bastante fácil devolver estos errores al frente, especialmente en el caso de una API.
Entonces esa es mi duda, ¿por qué validar este dato tantas veces? Sé que los esquemas de la base de datos no son solo para hacer eso, sino que hacer estas cosas una vez al frente y dos veces en el backend provoca demasiadas repeticiones y puede ser un poco difícil de mantener.
Aquí van algunas líneas de código solo para ilustrar el caso. No me juzgues, todavía estoy aprendiendo.
import mongoose from "mongoose"; const TaskSchema = new mongoose.Schema({ name: { type: String, required: true, trim: true, maxlength: 20, }, description: { type: String, required: false, }, completed: { type: Boolean, default: false, }, date: { type: Date, default: Date.now, }, }); export default mongoose.model("Task", TaskSchema); import taskModel from "../models/tasksModel"; export function createTask(req: express.Request, res: express.Response) { taskModel .create(req.body) .then((task) => res.status(201).send(task)) .catch((err) => res.status(400).send(err)); }La cosa es que tienes requisitos tanto básicos como de negocio. Lo que significa que al declarar las tablas de la base de datos (colecciones), sus propiedades, tipos de datos, restricciones, etc., configura, por así decirlo, la estructura de datos básica. Pero también puede tener requisitos comerciales adicionales, que probablemente no estén cubiertos por la sintaxis de la base de datos.
Por ejemplo, tiene en la entrada una matriz de objetos, que luego debe guardarse en la base de datos. Probablemente le gustaría evitar pasar objetos duplicados.
Por diferentes condiciones (roles de usuario, permisos, etc.) sus datos pueden validarse a través de diferentes esquemas de validación.
También es un caso común que valide su entrada y la transfiera a varias capas, módulos, componentes de su aplicación como DTO.
Por último, pero no menos importante, la inyección de SQL se puede realizar simplemente "consumiendo" datos no validados por la base de datos.
En la interfaz, cada usuario trabaja con su propia copia de la aplicación que se ejecuta en una sola computadora portátil y acepta entradas del sistema local o recursos web conocidos.
En el backend, todos los usuarios trabajan con una sola aplicación que se ejecuta en la infraestructura compartida y acepta entradas de Internet.
La validación del lado del servidor es necesaria para garantizar la integridad y la seguridad de los datos, ya que no tiene control sobre el origen de las solicitudes HTTP y la carga útil que entregan. Incluso los clientes legítimos pueden carecer de validación del lado del cliente si su API se llama desde un script. La solicitud no válida o maliciosa puede afectar a todos los usuarios. La pérdida de datos puede no ser recuperable.
La validación del lado del cliente es opcional y está ahí para mejorar la UX y proporcionar comentarios instantáneos sobre entradas no válidas: ahorra en HTTP de ida y vuelta y puede validar campos de forma aislada antes de que se complete todo el formulario y se envíe al servidor. La aplicación del lado del cliente en cuanto a seguridad afecta solo al usuario actual y siempre se puede restaurar al estado inicial recargando la página web.