No generes los IDs desde la Base de Datos, genéralos desde el Frontend
HTML-код
- Опубликовано: 20 сен 2023
- De lo primero que aprendemos cuando modelamos la base de datos es añadir un identificador autoincremental para identificar a nuestras entidades. Hoy te vamos a explicar por qué es mejor que el frontend los genere.
Curso modelado de Agregados: bit.ly/curso-agregados
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: ruclips.net/user/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🧔🏻 Twitter Javi: / javiercane
├ 💂♀️ Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🥋 Academy: codely.com/academy
└ 📕 Catálogo cursos: bit.ly/cursos-codely 
Наука
OWASP Top 10 ha salido del chat
😂
Xddd
Hace años aprendí una cosa: No pongas al lenguaje a hacer lo que la base de datos tiene que hacer. Incluso, postgres lo puede hacer con o sin una extensión, ejemplo sin extensión:
SELECT uuid_in(overlay(overlay(md5(random()::text || ':' || random()::text) placing '4' from 13) placing to_hex(floor(random()*(11-8+1) + 8)::int)::text from 17)::cstring);
Por dios, solo hablar de generar un identificador desde el front me da yuyo, eso es peligroso y bizarro. Incluso yo con toda mi experiencia no usaría uuid como identificador, eso le pone un overhead duro a la BD, solo imagina cuando el índice crezca a mas de 1 GB, te va a volver loco.
En eloquent con Laravel y postgres luego de un insert hay un returning automático del id que hace la BD.
No sigan éstos concejos, ésto está mal.
la verdad el titulo del video me dio frio en la espalda porque crear el id desde el frontend lo veo bestialmente mal, ademas en mi ignorancia y corto conocimiento se que para los mas util que es la uuid es para identificar tus componentes del front hasta ahora no habia escuchado a nadie orientar estas utilidades a la base de datos que ya directamente se rien del backend(el servidor) por decirlo de alguna forma.
Ese metodo "random()" de postgres no es criptograficamente seguro, en lo demas, toda la razón
Se nota que nunca han trabajado como desarrollador móvil dándole soporte a un modo offline, es un dolor de cabeza y una lógica supercomplicada (yo manejaba 8 estados, con doble id, era horrible) que se puede simplificar muchísimo si se permite mandar los ids desde el móvil.
Además, tecnologías como Realm o similares lo hacen por defecto, con un montón de documentación y explicaciones de porque es lo más óptimo.
¿Y por qué rayos guardar el campo como texto?, guárdenlo como binario, así no tienen esos problemas de indexación. Me da fastidió cuando hablo de esto con gente que solo ha trabajado de back-end, es fácil en servidores escalar horizontal o verticalmente, pero en móvil, en móvil solo puedes optimizar los procesos, dejen de ser tan egoístas.
Yo he trabajado en ambos campos profesionalmente, y un back-end debería buscar facilitar los cálculos en el front-end no al revés.
¿Y cuál problema de seguridad ven?, a mí no se me ocurre ninguno.
@@MinombreesSergio SI a mi me dicen que yo debo trabajar offline, porque una feature de la app debe ser esa, se debe emplear otra técnica donde ningún dato crítico se exponga fuera del backend. Se nota que para vos la seguridad no es importante. Cuando mandas a auditar una app ante una entidad certificadora, si piensas así, ahí van a aempezar tus problemas.
SI queiren evitar colisiones de ids, pues simplemente pongan un servicio que se encargue de generar los ids. La gente que trabaja en backend y tiene experiencia en eso, además de años en el mercado, son los que dicen como funciona el asunto en su cancha, no puede un newe a decirle como... Que hay cosas nuevas y asuntos que explorar, si, eso es verdad, pero una cosa es esa y otra cosa es hacer tu app insegura porque sí.
@@JoseRegalado yo tengo ya mis años de experiencia en backend y en mobile, según tú qué problema de seguridad hay si se mandan las ids desde el cliente, porque a mí por mucho que le doy vueltas no se me ocurre ninguno.
Y como alternativa que lógica usarías, porque a mí me toco usar un sistema de 8 estados donde me tocaba hacer doble proceso cada vez que enviaba información, mandar la información y luego emparejar los ids, y muchas veces no me garantizaban que los ids coincidieran en el orden de envío, a veces ponían algo de un id remoto que ayudaba mucho, pero seguía sin ser suficiente, los procesos en mobile deben ser instantáneos tener que volver a recorrer toda la info y mantener varios tipos de búsqueda es horrible.
Y si intentas usar una base de datos tipo realm ni se diga, por temas de rendimiento era la única que nos servía por performance, pero luego hacer el match de la información era horrible y los de backend no ayudaban.
Como voy a consultar un servicio que genere ids, si estoy offline ??????
PD: ya me han auditado y si me tomo en serio el tema de la seguridad.
Mala practica genéralos en front, siempre en back y tiene que ser 1 punto en conjunto para evitar duplicidad y incongruencia en usuarios. Por lo general un usuario es para un entorno cerrado, lo cual requiere seguridad en su creación y modificación, por lo cual no comparto su idea. En cuanto a lo de usar UUID vs id de usuario, confirmo, a nivel de seguridad debe ser así, nunca expongas un id auto-incrementar que hace referencia a tu base de datos.
yo le veo más desventajas que beneficios, pero lo veo bien como una alternativa, lo de los nulos eso se soluciona guardando el usuario inmediatamente después de que inicie la solicitud y el orm lo hace en automatico para ya tener la entidad con id no nulo , la unica ventaja real que le veo es lo de no hacer el get después de hacer el insert y lo de el modo offline
opino lo mismo.
Y para meter en colas y procesar después pero tener un id con el que trabajar, pasarlo a otros servicios integrados, etc. Hay mucha vida más allá de los CRUD
@@Marcos-pm4zo para eso puedes generar un Guid transaccional, con eso mantienes tu BBDD limpia, ya que apenas termines tu transacción, mandas ese Guid a mejor vida, Así lo he aplicado con sistemas que usan SQS y Lambdas.
Puedes simplemente generar el UUID en el API y retornar eso en vez de dejar el client que mande cosas raras.
El único argumento que entiendo es el modo offline, lo de entidades duplicadas no tiene sentido, el bug que mencionan igual podría pasar en el cliente, pues es un bug.
1. el video no trataba sobre usar uuid o id's incrementales, los uuid aparecen como una opcion fiable para generar id's unicos desde el cliente, dado que de manejar id's incrementales no habria forma de obtener el id correspondiente desde el frontend, no es simplemente generar el UUID en el api por que el tema era el flujo de la informacion, no el formato que se usa.
2. dejar que el cliente mande cosas raras... ¿¿eso fue en serio??
3. las entidades duplicadas es algo que he visto muy frecuentemente en aplicaciones tanto frontend y backend, todo por permitir que en alguna parte del flujo, a una estructura de datos que debe representar una entidad se le permite no tener id, y por lo mismo se recurre a generar un tipado intermedio que represente al objeto antes de ser guardado como entidad, la idea de que un objeto que deberia representar una entidad pueda no tener id ya es en si misma una idea que se siente extraña, y recurrir a clases extras para representar diferentes etapas de una misma entidad es cuanto menos algo tedioso.
4. el bug que mencionan nace de no tener la informacion completa y tener que esperar a que el backend nos devuelva el id, dato que quizas no conozcas: en las bases de datos, las claves primarias no se pueden repetir; por lo que si se hubiera intentado crear 2 veces el mismo objeto con el mismo id, la misma base de datos no lo hubiera permitido, el bug nace de no poder identificar un objeto antes de ser creado y el no poder identificar un objeto llevo a duplicarlo en el caso que explican en el video, asi que no, ese bug no hubiera ocurrido en primer lugar si se forzaba a los objetos a siempre tener un identificador unico.
Saludos bro, ten un buen dia:D
conoces lo que es la programacion concurrente y el bloqueo de procesos? o utilizacion de semaforos o monitores? o una simple validacion del front de que hasta que no se recibio la respuesta de la peticion, no permita enviar otra?@@davidramentol
@@davidramentol Lol para eso debes aplicar los principuos acid y usar transacciones, no generar el id en el cliente, osea porque puede enviar 2 tampoco te importa que envie 100 total enviará el mismo id XD pesima solución
@@davidramentol si le llamas a eso "problema del doble submit" no me queda claro que lo sepas, pero bueno
@@alandiazyanez3915 Con lo de "enviar cosas raras" me refiero a darle libertad al cliente a hacer POST con cualquier string como id, pues si está en el cliente significa que puedo hacer "fetch".
Lo del ejemplo duplicación, es un error de lógica tal como dices puede pasar en el cliente.
En un mundo perfecto os compraría esta solución, pero en la vida real existen problemas aunque tengamos la comunicación con el back al 100%. Usando esta técnica en algún proyecto hemos tenido "otros" problemas de comunicación que son más tediosos de identificar y que han producido inconsistencias complejas de arreglar. Prefiero una respuesta de: "ya lo tienes, este es tu id" y perder algo más de tiempo en el test (que si eres un poco avispado, sería igual de corto que el que habéis puesto con el uuid, pero de forma correcta, dado que en vuestro caso estáis comparando un objeto consigo mismo). Es decir: bien por la explicación, de 10 como siempre, pero en el mundo real no siempre compensa. Gracias por todos esto vídeos, seguid así!
Básicamente seria, en vez de recibir como respuesta "ya lo tienes, este es tu id", solamente recibir "ya lo tienes", me cuesta ver como afectaria ese en el proceso de depuración de bugs.
Me gustaría mucho si compartes mas detalles del caso en el que se les dificulto identificar x problema, para analizarlo y tomarlo en cuenta en futuros proyectos.
Saludos compañero:D
@@alandiazyanez3915 el problema en cuestión fue que, el servicio no insertó, pero devolvió un status code 200, en una arquitectura de cluster, dónde un server no se actualizó correctamente (a saber por qué) en la aplicación se continúa en modo normal, dado que una actualización de esa entidad es poco frecuente, se opera con ese id en otras entidades. Al cabo de un día aparecen datos inconsistentes, hay que buscar la causa, pero la responsabilidad de esa generación cae en un departamento que no puede encontrar el problema. Si hubiese ocurrido en el modo tradicional, se hubiese detectado en el momento que no se disponía de id y no se hubiese generado ruido. Como digo, es una buena técnica, pero no infalible dado que depende de otros parámetros externos. Un saludo!
@ ya veo hermano, gracias por compartir ese caso, en efecto suera raro que una petición devuelva un status 200 cuando no hizo lo que se esperaba, puedo argumentar que si el server se hacia de manera tradicional y ese error ocurria al querer actualizar un registro, ubiera sido igual de difícil de identificar, pero en efecto, al presentarse al crear ya me imagino la faena que fue darse cuenta 😅, no quisiera estar en esa situación
Saludos y gracias por compartir :D
@@alandiazyanez3915 de nada! Un último aporte: de la manera tradicional no hubiese devuelto el identificador, de ahí que, aunque hubiese devuelto un 200, se hubiese identificado que la respuesta no era correcta. Lo que quiero exponer es que muchas veces, desde front, no se tiene un control absoluto de la API. Un saludo!!
@ si se produce un error y el servidor devuelve un 200 tienes problemas muy graves en tu API, mucho mas graves que dónde se genera el identificador 😂
Yo vi muy clara una razón por la que necesité usar UUIDs:
Al crear un evento de dominio, en los escenarios de creación todavia no existe una id, de modo que necesitas generarla antes de la inserción. Cualquier alternativa seria mucho mas compleja.
PD: los UUIDs se pueden almacenar en formato binario, ocupando mucho menos y siendo mas fáciles de indexar
Hola pablo ¿cuándo hablas de un evento de dominio te refieres a registros dependientes?
@@davidpelaez2957 no, me refiero a un DTO que representa los cambios que han sucedido dentro del agregado, y luego se distribuye por un bus de eventos. Sí que puede servir en efecto para actualizar otros registros de forma asíncrona.
Busca sobre "event driven design", "event driven architecture". Codely también lo tiene bien cubierto en cursos, creo que en el de DDD o en el de hexagonal.
mala practica.
@@FujinBlossom así, porque sí, sin aditivos ni conservantes 😂
El problema es que esta encolando el evento de dominio antes de que este guardado en db. la practica es enconlar un futuro/promise/delegate/callback que resuelva el evento a enviar solo cuando el dato esté salvado en db. (en ese caso ya tienes el id)
Cuando he visto el título me ha petado la cabeza😂
Es la intención 😂
@@CodelyTV JDASJJASD
Justo estaba buscando vuestro video mas antiguo donde hablabais de esto por primera vez 😁😁
mmm inventándose el agua tibia. Pero es bueno ver diferentes puntos de vista sobre el tema.
Estoy de acuardo con el uso de UUID en el backend, pero no veo necesario que el frontend conozca el UUID del usuario.
Entonces el fronted informa al backend del Usuario que quieres consultar, editar, etc por ósmosis, ¿no?
obviamente no, basta con que el frontend conozca el nombre del usuario, que es el justamente el dato que conoce el usuario. Insisto no veo la necesidad de exponer un dato como el UUID @@Marcos-pm4zo
Todo lo que dicen se puede hacer en el back. Veo esto más como "extra" trabajo y instalar paquetes totalmente innecesarios en la parte web. Un trabajo que por sentido común no está delegado a la parte web. Bueno saber esto (como opción) pero en el mundo real aplicarlo sería estúpido.
Se nota que nunca han trabajado como desarrollador móvil dándole soporte a un modo offline, es un dolor de cabeza y una lógica supercomplicada (yo manejaba 8 estados, con doble id, era horrible) que se puede simplificar muchísimo si se permite mandar los ids desde el móvil.
Además, tecnologías como Realm o similares lo hacen por defecto, con un montón de documentación y explicaciones de porque es lo más óptimo.
¿Y por qué rayos guardar el campo como texto?, guárdenlo como bytes, así no tienen esos problemas de indexación. Me da fastidió cuando hablo de esto con gente que solo ha trabajado de back-end, es fácil en servidores escalar horizontal o verticalmente, pero en móvil, en móvil solo puedes optimizar los procesos, dejen de ser tan egoístas.
Yo he trabajado en ambos campos profesionalmente, y un back-end debería buscar facilitar los cálculos en el front-end no al revés.
¿Y cuál problema de seguridad ven?, a mí no se me ocurre ninguno.
Ahora si les molesta lo de la indexación pueden crear otro campo como llave numérica interna para indexarla no hay lío, pero eso solo tiene sentido en magnitudes de millones de datos.
@@MinombreesSergio cool!
no vean esto estando ebrios , les puede parecer una buena idea
Hoyo de seguridad se ha unido al chat
No lo se rick parese falso, sabes que si tu base de datos se basa en relaciones unicamente por "UUID", esta se volvera mas lenta en cuando a consultas con relaciones, llegando casi al doble del tiempo de una consulta normal con su relacion... en si esto no tiene sentido, el frontend no debe y no puede crear ids unicos, no es necesario y es un dolor de cabezas...
Puedes tener la propiedad ID autoincrementable, y una propiedad uuid para tus relaciones usas el ID autoincrementable y para mostrar en el frontend el uuid
Fuente ?
@@canodev termina siendo una tonteria, al crear un usuario, un post, o cualquier otro registro en una base de datos bien administrada seria maximo, maximo que 1 segundo de demora... no le veo el porque general uno del frontend, ahora te lo valgo para poder ocultar el id de una orden de compra, en ese caso si vale la pena usar un uuid que no sea primaria pero si unica....
por el coste que tiene generar un uuid yo creo que si puede valer la pena
@@canodev soy dba desde hace muchos años, y eso que planteas es una burrada en rendimiento, no tiene sentido, tienes mil opciones mas optimas en la base de datos que usar un "uuid". Ahora, si lo que pretendes es usarlo en un mini proyecto, donde no existan mas de 10 o 20 millones de registros, no hay problema. Para todo lo demás, no tiene sentido alguno, razones?: Escalabilidad, eficiencia, optimización, evitar fragmentación del motor, no sobre cargar indices, eliminar la posibilidad de que un usuario novato te meta una consulta errónea utilizando los uuid y te bloquee la tablas o las tablas. Y hay mas razones.
Ostras que bueno lo del modo offline! No lo había pensado!
Bueno al fin entendi xq esos id tan largos para buscar en los logs....(solo me dedico a gestion, pero hice 3 años de back hace un par de años atras) Excelente material, como siempre
excelente video
No habéis mencionado el caso en que yo conozca el ID de un usuario que no soy es el mío, y haga un PUT con ese ID. Siguiendo el estandar HTTP, debería ser actualizado (imagino que puedes poner autenticación, pero de nuevo, no habéis mencionado ese caso)
Eso es mucho más grave en ids autoincrementales, porque es mucho más sencillo encontrar los ids de los otros clientes.
Vayamos más a fondo, que sucedería con algún problema de conexión a la base de datos, cómo sabrían que en efecto el Usuario se ha registrado y no es una falsa alarma por el Identificador, implementarían algún middleware que justo valide la transacción?
Los fallos http siguen existiendo, si retorna un 500 tendrás que estar preparado y actuar en consecuencia. Otra opción es política de reintentos. Es mucho más complicado de lo que cuentan en 13 minutos de vídeo, esto no es para nada trivial
El lenguaje debe capturar la excepción del error en la inserción y notificar al cliente.
Yo en mis db tengo montón de entidades que el cliente no tiene idea con lo cual es simplemente una opción eso. Sobre todo cuando el server no tiene mucha lógica
Video muy interesante. Una contra de uuid es el rendimiento. Para remediar esto un poco se usa ULID
También está NanoID
@@rafaeljuradogonzalez7629 ULID es mas un concepto que una libreria, basicamente se pone un timestamp como parte del uuid para poder ordenarlo y no empeorar tanto el rendimiento en la base de datos.
Nunca deberías generar cosas desde el front, porque le das el poder de que despues por otra herramienta, postman, puedes modificar la información y generar tu propoio uuid, que puede escribir cualquier cosa, aparte eso de validar el id con y sin obligatoriedad, puedes usar (ya que usan typescript), Pick u Omit con una interfaz
Por desgracia eso de tener la menor lógica en el front, y más de este tipo, parece que cuesta entenderlo por los comentarios que he ido leyendo. Ya se toparán con esos problemas, supongo
No entiendo. Creas un recurso, y el backend te dice que tienes la id XYZ con la que puedes hacer cosas. Por otro lado, puedes decirle al backend que creas un recurso con la id XYZ, y si esta está disponible y es un UUID válido se crea y te lo confirma. ¿cuál es el problema?
@@falk167 Tienen una página web chiquita con por así decirlo 15 productos, no se están dando de cabeza con un caso de uso en el que hacer algo bien o mal marque alguna diferencia. Estoy seguro de que en nuestra base de datos creamos más documentos/filas en 10 minutos que codely tv en un año.
Para mi está claro que dejar la creación de los identificadores a la bdd es un error, porque en general hace las cosas más dificiles de lo que en realidad son y porque no todas las bdd tienen capacidad de generar el mismo tipo de ids. Por ejemplo todas las SQL (al menos las principales) tienen capacidad de crear identificadores autoincrementales por cada uno de los nodos de un cluster, salvan el problema de colision entre estas teniendo contadores con saltos, por ejemplo si tienes 3 nodos el nodo 1 creara el id 1/4/7... y el nodo 2 el 2/5/8, generandose espacios pero esto ElasticSearch o MongoDB no lo tienen, en su lugar te recomiendan UUIDs o sus propias implementaciones ID como MongoID (que al final es una version reducida de UUID, con información de la hora, contador interno e información de la maquina, en este caso el PID)
Pero en la vida se me ocurriría crear identificadores desde el front. El caso que mencionan que crearon 100 pedidos, es un problema de no validar antes de guardar, no de si se crea el id en el front, en el back o en la bdd, por ejemplo un pedido que es antes de ser un pedido? se trata de un carrito, bien, cuando pasas el pedido coges el carrito, los productos, transportistas, cupones, direcciones, metodos de pago, etc...y lo guardas todo en forma de "pedido" ¿No seria tan facil como validar primero que el carrito ya pertenece a un pedido?
Esto se puede validar a nivel de app, pero al mismo tiempo, ese identificador de cartId en el pedido lo vas a necesitar en muchas ocasiones si quieres tener una cierta trazabilidad de las cosas dentro de tu ecommerce, todas las bdd que conozco permiten hacer que el indice que si o si va a tener dicho campo sea unico, por tanto, si se tratase de un tema de concurrencia, que te lanzasen la misma consulta a la vez, y lograse saltarse tu lógica del servidor, seguiría sin dejarte guardar en la bdd porque antes de guardar tiene que llegar a un cuorum con el resto de nodos del cluster.
Por no hablar de lo obvio, que creo que en cualquier ecommerce es asi, la información del carrito está en la bdd y el id del carrito esta en la sesión, cuando haces un pedido lo normal es quitar el identificador del carrito de la sesión, lo cual complica bastante la aparición de dicho problema porque solo podrías pasar un pedido, a la siguiente petición no hay nada en la cookie y te devolveria un "tu pedido esta vacio y triste" y fuera.
Para guardar un UUID en DB mejor si lo pasas a binario
por que?
Porque un UUID en texto ocupa 36 caracteres "01234567-89ab-cdef-0123-456789abcdef", pero realmente es un número que ocupa 16 bytes: 0x0123456789abcdef0123456789abcdef.
Es mucho más rápido hacer búsquedas por campos numéricos que por campos de texto.
Hay funciones implementadas para pasar de binario a texto y viceversa.
En MySQL existe UUID_TO_BIN() y BIN_TO_UUID()
Sería algo así como el equivalente a un número gigante
por o alguna fuente?
😅mejor en assembler 🤣
Leyendo los comentarios, hay gente que se piensa que generar un uuid en cualquier lenguaje es un calvario... cuando hay cientos de librerias que lo generan.
Luego están los que dicen "es que el front va a decirte a ti que id tienes" ¿dónde está el problema? un uuid es algo estándar y hay cientos de validadores para validar que el uuid que te pasan es un uuid correcto. Si tanto el cliente como el back saben que el identificador de la entidad es un uuid, ¿que más da dónde se genere?
Yo no veo por ese lado. yo lo veo por el lado de que el backend no es solo un pasamano, existen montón de lógica y abstracciones internas, entidades propias del back que el front no conoce, entonces no tiene porque enviar ese numero porque *NO* es su responsabilidad. Luego existen casos especiales que se pueden resolver pero eso del UUID del lado del cliente es solo para casos puntuales y que, intencionalmente, lo quieren resolver así. No hay necesidad, es solamente gusto.
Si expones un api rest con esa lógica alguien podría pasar como ID cualquier string, para evitar eso tendrías que validarlo... Que tanto ganaste con hacerlo desde el cliente?
El apologismo front-end de este video es un anti-patrón. Separation of concerns y SRP.
El ID generado en front-end solo debe usarse en casos muy concretos para un contexto de uso que termina en front-end, por ejemplo para idempotency, evitar queries duplicadas y data tracing. Lo demás, casi seguro es un anti-patrón y llevará a technical debt. No hagáis caso!
para mi que el user en el cliente tenga el ID null cuando no se ha creado me parece una ventaja, por que realmente te estas asegurando que interactúas con un elemento creado y que existe, creo que tiene mas desventajas crear el id desde el front, me parece que se debe respetar la responsabilidad, evidentemente deben haber casos en que puede ser valioso esta implementación
Es que no es en el cliente, es en el sever al procesar el Post.
Si te interesa eso puedes manejar un estado en tu front-end, pero la idea de un modo offline es precisamente que no haya diferencia en si esta o no creada la información en el backend.
Si en vez de uuid utilizamos ulid, además esa key será sortable
La colisión de UUID's es casi improbable. Pero, prefiero confiar en el mecanismo de una base de datos que a un desarrollador invéntandose el algoritmo de generación de UUID's. Sí, ya sé que tienes tu librería tan chula de UUIDs en JavaScript, pero... ¿Habéis pensado que en el contrato REST estáis obligando a que el usuario se identifique con algo único?
Es como si voy a la policía a hacerme un DNI y que me obliguen a generar la numeración junto con la letra (yo solito de cabeza). Como siempre, dando la responsabilidad al front y que la capa de negocio sea siempre el responsable. Lo siento, pero es vuestro peor vídeo con diferencia, todo para evitar un null "que se ve feo en mi código". Ah, y podría molar si generas el UUID en el servidor, ahí ya me parecería mejor.
1. la colisión de UUID's no es "casi improbable", es solamente improbable, (pequeña corrección semántica jeje).
2. no te preocupes, los desarrolladores hace años dejamos de inventar algoritmos de generación de UUID's, los que tenemos son sumamente fiables.
3. no es igual a que te pidan a ti generar algo único con tu cabecita y un algoritmo a que se genere con una computadora, las computadoras tienen mucho mas potencia de calculo que las personas, por eso si hace sentido que cualquier computadora genere un valor único :).
4. no es solo por un null, literalmente explicaron como simplifica el flujo completo de la información, puedes ver el video nuevamente para comprobarlo
Como dba, no hagas ésto, por mas que te lo quieran explicar y funcione para proyectos chicos. Utiliza lo que usa el mundo y sobre todos los proyectos grandes y sobre todo, confia en las bases de datos.
@@galaxiapixelbuen comentario, creo que ir acorde a lo que la mayoria de la industria esta haciendo en efecto ofrece un nivel de seguridad sobre nuestros proyectos, personalmente yo procuro mantenerme abierto a nuevas posturas no simplemente "confiando" (como sugieres que hagamos con las bases de datos), si no basado en resultados matemáticos, si se hacen las cuentas se deduce que es prácticamente imposible obtener uuid's repetidos, puedes investigar por tu cuenta y te daras cuenta de esto, yo recomendaria a las personas mantener una mente abierta y crítica
Saludos compañeros:D
@@alandiazyanez3915 con este aproach estas "confiando" en que nunca va a colisionar un UUID
En el video nunca explican como solucionar una colision de UUID, que es improblable pero no imposible.
No tiene sentido lo que decis, tiraste una analogia que no dice nada, la generacion de identidad desde el front es algo muy util y muy utilizado, obviamente hay casos de uso para todas las variantes. Antes de decir que es el peor video porque en tu nula experiencia no lo utilizaste y estudia un poco mas
me pregunto, como confiamos en que uuid que manda el frontend es correcto? Creo que puede generar muchas cosas abitrarias que depende de logicas del navegador. Al menos es raro.... jeje
@@davidramentol si lo se, no se si con eso alcanzaría... tenés un montón de posibilidades cuando lo hace un browser y no el server. La verdad que tiene que estar muy justificado para hacerlo asi
Hay una regla de oro en seguridad y es que nada que venga del cliente es confiable en absoluto y hay que tratarlo como la peste 🤣
@@djthdinsessions exactamente, al tomar una decisión de tal magnitud, tenés que estar muy pero muy seguro. Porque cambiar eso puede ser algo bastante complejo.
Creo que de partida el ejemplo está mal porque la entidad de dominio no debería estar en la capa de infraestructura. Si aplicara DDD, la entidad de dominio no tendría el ID nulo, ya que este se crearía en la lógica de negocio. Usar ID autogenerados, permite que los atacantes puedan "adivinar" información, por ejemplo: /user/1, /user/2, etc. Por ahí dieron la idea de usar ULID y me parece una muy buena solución
Me parece un un proyecto pequeńo y puntual pudiera funcionar. Pero a modo generar diría que quieren reinventar la rueda. La base de datos y la generación de los id es cosa del backend y eso tiene miles de ventajas comparadas con un valor null. Qué hay otras alternativas de manejarlo. Allí están pensando en un escenario ideal. Pero en la práctica cuando le metan carga a a eso y existan desconexiones perdidas de datos pues hay 70% de posibilidades de que la base de datos se valla al traste.
Lo entiendo porque una vez en un proyecto de scrapping para insertar en una base de datos para no tener que estar pidiéndole a la bbddd directamente en el conector de la base de datos mandabas la función que te generaba directamente el uuid, la verdad esque son un coñazo pero para son bastante funcionales y muy rapidos
es solo un caso. no se puede decir que todo deba ser así por solo un caso de uso.
me da miedo ver estos videos, siempre me dan ganas de hacer mis apps desde cero jejeje, solución muy interesante para algunos contextos especificos.
Los ejemplos expuestos de problemas con generar los IDs en el backend están muy cogidos con pinzas y todos tienen fácil solución, pero claro entonces este video no tendría sentido.
x2
x3 No se, el de los pedidos, basta con haber trabajado en un ecommerce para entender que no es (o no deberia, si esta bien hecho) ser tan facil llegar a pasar pedidos solo por relanzar la request ¿Que hay de id del carrito de la sesión actual no se desvincula de la sesión cuando has pasado un pedido? ¿Que hay del id del carrito en el pedido, no se valida si ya fue convertido? ¿Que hay del cartId en el pedido, la key no es única? ¿Que hay de la transaccion del método de pago, permites que se repita? Y estas son 4 ideas super básicas de ecommerce que me han venido a la cabeza como en 5 segundos.
Lo que pasa es que esa supuesta app estaba mal hecha y se han aferrado a que el UUID sería la salvación, las cosas hay que pensarlas un poco.
Hola. Me imagino que el caso particular que se han topado, es una alternativa válida, me gusta, sólo que se hubiese agregado una serie de interrogantes como resultado de esta solución, por ejemplo: En aplicaciones con volúmenes de usuarios muy grandes, el hacer filters, joins, etc sobre identificadores UUID es más lento que sobre números (de esto preguntadle a los que hacen los motores de bd, yo no sé porque es asi) y a la hora de realizar reportes, puees, por lo que uilizar el UUID como llave secundaria no estaría mal (proponiendo una solución), manteniendo el primary key de toda la vida, sin embargo, debo aclarar que esta aplicación no sé que tan conveniente sea utilizarla en entornos de servicios, donde se pueden tener muchos front end, y tener duplicidad de código, sin contar con el miedo de que el UUID es generado a partir de la referencia del tiempo (mmmmm), buah, muchas interrogantes sobre esto último, me da cosita por ponerme a validar. Saludos.
los usuarios siempre se deben crear en 1 punto, nunca tendrás 2 iguales, en cuanto a buscar, si vas a tener muchos usuarios ya mejor pasarse a una base de datos no relacional, o tener una capa antes en Mongo y solamente salvaguardar data en la db relacional.
si el id va asr manejado solo por ordenadores vale. Pero imagina que el numero del dni sea un uuid, al pobre funcionario que lo debe digitar en el aeropuerto o el policía que lo transmite por radio, seguro que comete un error
un programador,no tiene criterio propio XD?
MIjos, actualicense , hay muchos problemas en la base de datos por usar GUIDs o UUID . Hay otras técnicas como twitter snowflake. Ademas les hace falta un buen de bases de arquitectura de software, todas las razones que dan son solo síntomas de desarrolladores sin experiencia real en campo y sin bases de programación.
Hola ¿alguien tiene algun ejemplo de una aplicacion opensource creada con DDD? Porque todos los videos o ejemplos que se encuentran por Internet solo sirven para personas que no tienen apellido, los productos solo tienen precio o nunca crean un agregado con mas de 3 campos.
jaja tal cual, es que DDD en realidad te da un idea de como lo deberías hacer, no es un patrón, es solo una guía, por eso hay tantos ejemplos que ninguno te sirve para lo que tu necesitas
Interesante, pero creo que el front se está queriendo tomar demasiadas atribuciones que no le corresponden.
Mirando el test con la mejora del uuid, creo que la función de registrar es incorrecta, ya que no se el envía el id que generé al crear el usuario. Si no lo envío, para que lo creo? o estoy equivocado?
Con la ventaja del modo offline estoy de acuerdo, mas cuando se trabaja con opciones como PWA. Pero como todo, ninguna es perfecta, cada alternativa debe usarse de acuerdo al problema que estemos resolviendo. Por eso esta bueno que mencionen las desventajas para así inclinarse por una u otra según las necesidades
pregunta: que contraprestaciones en seguridad tiene?
Ninguna, o por lo menos a mí no se me ocurre ninguna que no ocurra con el método clásico, es más seguro que con ids autoincrementables, y si usas binarios la indexación tampoco es problema.
@@MinombreesSergio gracias
Que ventaja hay en pasar el uuid al modelo vs que en el constructor del modelo NO se pasa el uuid, el id lo genera el modelo.
vuelve a ver el video bro
Ninguna, que no tienes un null en el código y que no tienes que hacer ifs, confiando ciegamente en que el desarrollador front haya hecho su trabajo y rezando que no haya colisión de UUID's.
Ninguna, un absurdo en todo salvo para proyectos pequeños, cuando estés en un proyecto grande jamas propongas ésta burrada. Ni hablar si el proyecto esta de cara a internet.
@@JohnDoe-cp5nfy confiando tambien en que no hay ningún usuario malintencionado que se ponga a manipular la aplicación y a inventarse uuids (o cosas que no sean uuids xd)
Respecto a uuid... "pesa más un string". Chicos, se os ha ido la pinza, que un uuid son 128 bits, 16 bytes. Luego, como dicen en los comentarios, hay problemas nuevos que se producen.
Se puede hacer modo offline de cualquier forma.😊
A mi no se me ocurriria hacer en el front la generacion de UUIDS en una app publcia, dicho lo cual, en el SGA que hemos hecho la parte del front está hecha con Flutter + MongoDB Realm, al ser una app interna que gestiona 47 almacenes y tener registrado al milimetro quien hace que, pues si, hemos tirado por el camino de crear los ids en el front y simplifica mucho las cosas.
Pero si la app fuese publica, pues bueno, te tendrias que fiar de que gente con mucho tiempo libre no viese un punto en el que reventarte.
En unos meses vamos a rehacer el ecommerce con tecnologias más modernas (hace 2 años empezamos con los microservicios y ya podria decirse que es factible migrar sin anestesia el proyecto más viejo) y ya voy adelantando el el id del carrito se va a seguir creando en el back (en el legacy es en la bdd, eso seguramente si que se mueva al back, y seguramente no sea un UUID porque no todos los identificadores tienen la necesidad de la magnitud que intenta cubrir un UUID, seguramente la mayoria con un ID como los de MongoDB pero soportando todo el abaceradio y mayusculas/minusculas, con solo 12 chars podrian representar el 99% de casos de uso y el 1% problematico hacerlo con un UUID de 32 chars)
Un guid como pk en sql? Hundes la db en 2 días...😅
Cada proyecto nuevo lo hago offline-first, entonces creo los ids desde el front y si el usuario no tiene internet los cambios pasan a una cola, al volver el internet la cola se sincroniza con el backend... que fastidio sería crear ids temporalmente los cuales después tendría que actualizar
ids temporales? wtf. no te ates a las definiciones de otras personas solo porque sí. xD
@@SimaDamian Creo que no comprendiste mi comentario
@@christopherkiessling porque necesitas esos ids en el cliente si no estan salvados? poruqe no quitas esa propiedad y listo?. si usas la estrategia de no generar UUID en cliente no tendrías porque generar nada temporal.
De todas formas, es solo una forma no tiene nada que ver con un fastidio de hacerlo de otra forma ni nada, de hecho si la app puede trabajar sin back es porque ese back tiene poca lógica. Es un caso de uso, una forma, pero no atrase a esas definiciones! Yo trabajo por lo general con aplicaciones que tienen mucha logica de negocio en back y otra distinta en front. y por tanto esa estrategia no sirve (en esos casos). Y en los pocos casos que necesito modo offline no sufro para nada realizando otra estrategia, que sería una stock propio para eso.
@@SimaDamian Los ids si los salvo, offline-first significa que primero cubro modo offline y luego sincronizo con el backend (online), es posible que confundas el concepto con offline-only. A lo que me refiero con que sería fastidioso (futuro hipotético o condicional), es a crear ids auto-incremental los cuales luego de ser generados en backend tendrían que convertirse en mi nueva fuente de verdad, por ende tendría que actualizar/quitar mis ids generados temporalmente por el front. Contrariamente, tal como indica el video, genero los ids en el front los cuales no son temporales sino que persisten, eliminando así la necesidad de actualizarlos luego de sincronizar los cambios pendientes por insertar, actualizar o eliminar en backend
@@christopherkiessling Si, yo estoy totalmente en contra de crear ids en el front, pero en nuestra aplicacion interna SGA que tambien es offline first (flutter + MongoRealm) obviamente debes crear los ids en el front, no se trata de una opción, es lo que hay.
Pero cuando no es offline first, por ejemplo un ecommerce, para que quieres pasar un ID desde el front? No se, nosotros tenemos dos bases de datos, una relacional (un MariaDB que representa un pedido en cerca de 27 tablas) y una no relacional, un MongoDB que repreesnta ese mismo pedido en una sola colección con datos anidado, para mi es una chorrada que te pase desde el front el id del pedido y que hago con las otras 26 tablas que tambien tienen id? Me las imagino? No le veo sentido a que unas entidades si y otras no, lo veo una warrada.
se han vuelto tibios 😥 el codely que yo conozco hubiera puesto: DEJA DE USAR AUTO_INCREMENT, YAAAA!!! c?
pero si el cliente genera el UUID, el usuario no podría falsear la data?
Creo que esa es la idea, para falsear la data en el caso del testing
Por otro lado, también mencionaron que se refiere a crear los identificadores desde el frontend y con una librería de la comunidad bien testeada y no manualmente. Por lo tanto, yo ahora asumo que se refieren a que el frontend es un cliente en quien confías, ya sea por ser una aplicación interna o en general alguna aplicación que pertenezca y sea administrada por la empresa junto con el backend
Lo que sí me preocupa es si se tratase de una api pública donde cualquier persona random fuera de la organización crearía su propio frontend (o cualquier cliente http como postman) y ahí sí podría usar un uuid que pudo encontrar en otro lado, y aunque por lo general aún es difícil que eso suceda pues sí creo que aumentaría la probabilidad convertirse en una vulnerabilidad mayor
@@ferriss_No existe ningun "cliente confiable" cuando se trata de frontend
@@djthdinsessions Mm entonces eso aplicaría lo mismo con los microservicios
Al final ambos son código
Y me estoy refiriendo cuando se trata de aplicaciones que son desarrolladas por equipos de la misma organización
O cómo ves esa parte?
Estoy modo dudoso activado así que trato de mantener la mente abierta y tratar de entender varios puntos de vista :D
@@ferriss_los usuarios no tienen acceso a la implementación del backend. Fallar pueden fallar todos en una organización, sea en back o front. El back no puede saber si lo que le llega es de la aplicación real o de alguien que haya manipulado la llamada
@@falk167 Tienes razón en esos puntos, y sí, todos pueden fallar. Pero ahora me queda otra duda: Sea que se genere o no un uuid desde el frontend, al final si se quiere actualizar un recurso, igualmente pasará por un PUT o PATCH al backend y le tendrá que enviar el identificador, entonces allí también el backend no puede saber si lo que le llega es de la aplicación real o de alguien que haya manipulado la llamada.
¿Cómo interpretas esa parte?
- Los comandos en CQRS pueden retornar indicadores de success o failure por lo que es válido que retornen el ID insertado en la BBDD.
- Usar put con el id creado en el front no tiene sentido, estas indicando que quieres modificar un registro que aun no existe en la BBDD. Basta con usar post, retornar el id y no pasas a llevar CQRS
Estaba buscando una respuesta que indicara por qué han usado PUT en vez de POST. Ya veo que no estoy loco.
@@adolfomartin5456 porque en otro video dicen que no hay que usar POST solo usar PUT. y siguen rodando sobre una reueda semi redonda que ellos mismos inventaron! xD
De esta forma, puedo manipular el frontend para que use un uuid ya existente y sobreescribiendo dicho usuario y su identidad en la aplicación
a ver si puedes hacer eso desde tu API entonces el problema lo tienes en los permisos de tu API, no en cómo generas los ids creo yo
asi funciona cualquier metodo put, si en la api solo se pueden crear y no actualizar ningun objeto, entonces puede que si tenga sentido tu comentario, por que si la api permite actualizar registro (como practicamente la mayoria de apis actuales) ese problema apareceria aun si generas el id en el back
@@alandiazyanez3915 Si, pero en este caso estás habilitando los puts para crear, por lo tanto se abre más posibilidades como la que he mencionado. Ya que los put de normal tienes un validador de propiedad que en este contexto no se podría usar ya que no puedes poner tener una propiedad de algo que no tienes. Como todo, con las protecciones adecuada, se puede evitar.
@@davidramentol Si, el caso es el usar un put para crear/actualizar y que frontend conozca los uuid tan delicados como los de usuario.
@@jose49716 Si usas PUT para crear y actualizar, te puedes encontrar con este caso sino pones las protecciones adecuada. Igual que cualquier otra API, por supuesto.
Ufff rdto es una joya...
Se pueden generar PKs unicas sin usar autoincrementales. Y en muchas aplicaciones la mayor parte de inserciones se hacen con procesos batch. Por lo que generar en front es absurdo.
Veo en los comentarios mucho dogma y pocos argumentos; cuando usamos llaves naturales ya estamos enviando la llave desde el cliente por ejemplo. La ídem potencia del API también es un plus gigante de este método: si se te van dos peticiones con el mismo identificador no hay lío. Los auto increméntales desde la bd son la forma tradicional, pero no garantizan ni ayudan con nada en temas de duplicidad de la entidad que precisamente identifican(los UUID tampoco). Me gustaría ver la opinión de codely con respecto a las llaves naturales.
cuando dices que son problemas cuando en realidad no son problemas jajaja,
totalmente
En efecto, creo que desde hace tiempo el ecosistema de desarrollo se ha planteado resolver problemas que no existen y dejar los verdaderos problemas a un lado
cuando trabajes en aplicaciones grandes con offline vas a ver lo problemas
en offline que es mejor ids generados en cliente o servidor y por que? Por curiosidad (ah ya veo que lo comenta en el vídeo)
@@jose49716 no mms, en modo offline quien consume tu servidor? es como decir que tu cliente una internet explorer en versiones obsoletas, es querer buscar justicacion a un modo sin internet, ademas de que una app puede funcionar sin conexion a internet pero limitada, ninguna app de renombre usa cruds en modo sin conexion, es ridicula el escenario
¿Te imaginas una api como la de MercadoPago dejando que los clientes definan ellos mismos el identificador de un Payment?
Interesante pero incompleto, no es necesario que hagas un insert directo desde la aplicacion a la base de datos, puede crear una funcion en la base que haga eso y que va a retornar el ID, ahi no existe doble query ni nada y se va a mantener la coherencia de datos persistidos con seguridad.
Una base de datos bien normalizada y estructurada servira para muchas cosas mas que guardar datos de esta clase.
Un arquitecto de software debe tener todo en cuenta.
Muy mala practica; Si hablas de un escenario de millones de usuarios, ahi los uuid generan colision y vas a tener mas de un usuario con el mismo ID, lo mejor es usar el id numero autoincremental que lo hace la base de datos.
Por otro lado tu solucion de que el front genere el uuid, lo hace vulnerable a que se envie un uuid de un usuario ya creado y le robe la sesion.
y sobrecargar a la bd? si así nomas con ids numéricos cuando tienes miles de registros la BD tarda en relacionar las tablas, no quiero pensar el dolor de cabeza de relacionarlos con UUID, no lo hagan, esto es mala practica para el rendimiento de la aplicación
Sabia que no estaba loco :D....
Mis amigos programadores me criticaban porque genero los IDs aparte, y los inserto directo, vaya, no uso AUTO_INCREMENT.
Por mi parte lo que hago para aumentar el rendimiento de la aplicacion que esta insertando en tiempo real y evitar que CONSULTE para generar un nuevo UUID, es que tengo un proceso CRON que cada 2 horas crea un bonche enorme de UUIDs y los guarda en REDIS.
Asi despues cuando la app vaya hacer un insert, va y le pide a REDIS un UUID unico.
¿Y porque no creas el UUID en directo? Literalmente puedes crear igual 1 millon en medio segundo. No le veo mucha logica a tu planteamiento, redis no te garantiza que dos personas no puedan acceder al mismo resultado.
¿Que ocurre si dos personas leen en el mismo instante? Pues que tendrian 2 ids iguales, para eso, en el back antes de hacer ninguna operacion la creas.
Puedes creerme o no, yo estoy acostumbrado a día de hoy a trabajar con aplicaciones que generan mucho dato, se me ha ocurrido imaginarme tu solucion en nuestros sistemas y me ha codigo vertigo, no dormiria tranquilo pensando que eso puede ocurrir.
@@user-tt1hr2lk2k con que lenguaje puedes crear 1 millón de combinaciones en medio segundo?.....
En Redis existe el servicio de SCARD que garantiza que ningún dato se repita en la pila de datos, eso eficientiza la hora de generar el UUID e insertarlo, prácticamente porque ya se creo con anterioridad.
está bien, pero no es lo mismo generarlos desde el frontend via cliente o via server, ya que todo lo que se haga en el cliente está fuera de nuestro alcance, un usuario malicioso puede interceptar las requests antes de que salgan del cliente y hacerte un 8 generando un uuid existente o cosas raras... creo que generándolo desde el server se mitiga esto y aun estás en un paso intermedio antes de llegar a la base de datos, pero te fuerza a ser más creativo en los flujos de uso offline... te lo dice alguien que ha aprendido a "crackear" cualquier app de electron, interceptando con un simple debugger las peticiones que comprueban licencias y cosas así (aunque lo hago solo a modo de aprendizaje)
IdemPolencia
MongoDB dejo el chat 🗿
Espera. Ese título más que nada fue un buen marketing. Aún no veo el vídeo pero como ahora es generar "polémica" se la jugaron bien.
Si creas UUID desde frontend me imagino la tremenda brecha de seguridad, si es que estas modificando un usuario y por casualidad te sabes el UUID de otro usuario (supon tu el admin), de tal manera que mandas una petición POST para cambiar el password metiendo el UUID del admin y con eso ya logras acceder al user Admin. Que si que en la teoría cuentan sus historias muy "clean code" pero se les olvida hablar sobre las brechas de seguridad que no les enseñan a los incautos.
Cuando comentas “y por casualidad te sabes el UUID de otro usuario”, creemos que esa misma premisa, en caso de representar por sí misma un riesgo de seguridad, sería mucho más probable en caso de usar IDs autoincrementales que no con UUID. En el vídeo siguiente contestamos esta y otras posibles contraprestaciones de generar IDs desde el frontend: ruclips.net/video/P3bpYv9vdic/видео.html
@@CodelyTV El meollo del asunto es que en el diagrama de flujo, expresan que no envían respuesta al frontend sobre las peticiones realizadas, lo cual significa que el frontend no recibiría ninguna respuesta ni positiva ni negativa, lo cual deja un enorme agujero negro entre lo que vez en el front y lo que en realidad pasó.
¿Desde el frontend? Buena suerte evitando que manipulen la aplicación. Se puede hacer todo eso generando el identificador desde el backend exactamente como se ha dicho y de forma mucho más segura.
Exacto, nunca mejor dicho. No da confianza que sea el frontend quien genera arbitrariamente los ids
@@davidramentol Al acceder a una web cualquiera, se está descargando su contenido y su ejecución se realiza en el cliente.
Aunque es posible ofuscarla, es relativamente simple acceder al código y manipularlo (clic derecho, inspeccionar, sources, etc...)
Si el frontend es en su lugar una aplicación móvil, ya es algo más complicado pero ocurre lo mismo. Anda que no hay apks piratillas por ahí de algunas aplicaciones.
Lo más seguro es hacer, lo que se dice en el vídeo, pero en el backend, que no se ejecuta en el cliente. Tanto identificadores como cualquier tema de seguridad.
@@davidramentol creo que no he terminado de entender esta respuesta. Por lo pronto puedes manipular, y muy fácilmente, la llamada para forzar posibles fallos, cambiando el tipo de dato. Por otra, se fuerza a definir un POST con ID que tampoco es muy buena idea porque en este caso se extrapola un problema de base de datos a la definición (por lo menos más que en la otra opción) y obliga a arrastrar un parámetro adicional. También se añade lógica adicional al front. No hay ninguna desventaja en hacerlo en el backend donde debe hacerse, después de validar los datos y justo antes de guardarlos.
@@davidramentol estoy hablando todo el rato del front, un usuario no va a modificar nada en el backend y no me refiero a nada de permisos (es un tema aparte, y desde luego no se harían en front), me refiero precisamente a que un usuario no va a modificar código del backend como sí puede hacerlo en front, o manipular las llamadas que esté hace muy fácilmente.
Me parece algo más o menos básico en seguridad, casi al nivel de evitar los ids incrementales, y me sorprende que patinen así. Y los autoincrementales aún tienen todo el sentido que puedan existir en base de datos en términos de rendimiento (que igualmente, no deberían exponerse nunca al usuario de existir)
@@davidramentol Lo he dejado bastante claro. ¿Cómo que qué problema hay, acaso no podría modificar la propia generación del UUID, crees que sólo puede tocar los colores de la aplicación? Está en su derecho, claro. ¿Sabes dónde no podría modificar el funcionamiento de la aplicación? En el backend.
A cambio de realizar menos trabajo y sin ninguna contraprestación.
Pero bueno, que la gente aprenda y se acostumbre a hacerlo así, que ya se toparán con problemas tarde o temprano.
Te recomiendo que hagas algún ejemplo antes de ir diciendo por ahí lo primero que has dicho
No entiendo, le estás dando el poder al usuario de generar el UUID que le de la gana si manda una petición él de forma manual...
Ahora me imagino que el siguiente paso es que solo validemos en el Front y no en el Back por rapidez, alta herejía se marcaron con este video :v
El grado de ignorancia que demuestran en este video es suficiente como para jamás, jamás en la vida confiar en ningún consejo proveniente fe estos dos.
Lo que más me preocupa es que de las 19000 personas que vean esto alguna va a creer que esto es buena idea.
La idea de los muchachos es una perspectiva desde el desarrollo de código pero no han tomado en cuenta la arquitectura de la base de datos. Esto claramente repercutirá en el rendimiento y los problemas que tendrá este enfoque va depender del motor escogido.
Les falta experiencia en aplicaciones del mundo real.
Quien dice que los desarrolladores no tenemos sentido del humor. 🤣😂
Si generas los IDs desde el cliente mejor con UUIDs.
imagino esto es desde la inexperiencia
Me encanta vuestro contenido pero a este vídeo en concreto le veo lagunas... No solo la API deja de ser restful, es que además me parece peligroso. Si haces DELETE /user/{uuid} y tienes alguna pantalla por ahí obsoleta de editar esa entidad, no va a tirar 404 (como pienso que debería), va a tirar 201 y te va a crear el objeto de nuevo. La mayor parte de los problemas que se comentan en el vídeo se pueden solucionar perfectamente haciendo que el constructor de User contenga el "this.id = uuid()" (yo nunca le paso el id como parámetro al constructor de mis entidades), con esto obtienes la mayor parte de las ventajas que habéis comentado (no existe un user con y sin identificador, un user siempre tiene identificador), evita doble queries para obtener el lastId, etc, etc. El uuid no debería repetirse nunca, pero si se encarga de generarlos el back, y se repitiera, daría un error o podría reintentar generar otro uuid, si presupones en el cliente que vas a poder utilizar un uuid podrías enfrentarte a otros problemas. No lo sé, supongo que todo se podría resolver, a día de hoy considero indispensable trabajar con uuid, pero lo de que PUT cree el recurso no acaba de convencerme.
🤔
No lo se rick, es un buen tema para conversar, pero los casos a aplicar son muy especiales.
Al árbol B+ de los índices de la BD no le gusta el video
Por curiosidad, por que? Esos índices sólo funcionan con índices numéricos incrementales?
@@jose49716 no es tan simple explicar en un corto mensaje de youtube, pero simplificando mucho, el arbol b+ se utiliza para reducir el tiempo de busqueda de datos, en donde la facilidad de determinar que valor es menor o mayor a otro dentro de los nodos permite que sea más eficiente su algoritmo, esto es más rápido con numeros que con texto, y cuanto más largo es el texto, peor rendimiento.
Correcto, la indexación se pierde y se hace más compleja los inserts
@@cerm88 totalmente, incluso la propia lectura se ve afectada, por cada nodo que tenes que navegar en la lectura no es lo mismo comparar si "86c7c4dc-bc90-45c5-a3b6-4b7d81f69232" estaría en la hoja izquierda o derecha de "86c7c4dc-6b4d-44a4-aa02-79d46e624539" que solo comparar "13123123123" con "13123123121" y este tipo de operaciones cientos de veces
@@jose49716Los UUID no siguen un orden especifico, lo cual los hace muy pesados en ordenar, al contrario de otras alternativas como los ULID, los cuales si siguen un orden al ser creados.
returning id
Entre que no lo haga la base de datos y que lo haga el front no habian opciones no, pero escogeis la peor.
1 - Para que quieres que sepa el uuid el cliente antes si no sabes si se ha creado bien el recurso. Las peticiones quieras o no tienen request y response.
2 - El id no tiene que ser nullable, no es necesario, puede estar vacío.
3 - La arquitectura de capas se basa en RESPONSABILIDADES.
Para mí esto está mal.
Saludos.
Interesante video explicando los beneficios de usar los UUID desde el Front. Este problema tiene varias partes:
* El caso de uso: Gestionar usuarios -> No / Crear una lista tareas -> Si
* Exponer datos sobre la creación de datos sensibles se puede considerar una brecha de seguridad
* Aquí no importa ya que no son datos sensibles
* Responsabilidad simple:
* Si nos vamos por el segundo caso y creamos una aplicación que no gestione usuarios y solo creamos los UUID desde el Front (¿Para qué crear un Backend?) ->El Backend es necesario porque en la mayoría de las aplicaciones necesitamos de una lógica al menos para mostrar algunos datos.
* En términos de tecnología:
* Crear un usuario en este vídeo esta mal generalmente se crea el usuario y no es que el identificador retornado se devuelva en el objeto, para ello usamos el token y JWT con la información necesaria.
* Así sea una POC (Prueba de concepto) o un MVP o un producto grande lo ideal es aplicar la ingeniería de software de la mejor manera posible.
Por favor Rafa habla más despacio 😂
Se intenta, pero a veces me emociona mucho el tema xD
Yo creo que la responsabilidad de generar ids únicos pertenece a la base de datos. Y sí, eso provoca que haya que hacer algo más de trabajo para obtener la información que necesitamos y que sea más lento por ello y todo eso, pero generarlo desde el front me da un poco de desconfianza. Os puedo comprar la solución intermedia de generarlo en el back, pero al final, creo que el front debe enviar los datos conocidos y gestionados por el front y no creo que un UUID sea el caso.
No obstante, como debate, me parece bueno. Hay comentarios muy chulos.
Esto es una batalla perdida con casi todos los devs. Solo hace falta ver el top comment para darte cuenta que a la gente le gusta mas repetir cosas que ha leido que usar lo que tiene entre las orejas.
No se pk no le s gusta los orms un video explicando eso seria genial pk la verdad a mi me solucionan la vida
Es solo reinventar la rueda
estas literamente diciendo que insertar un uuid desde el front te va a facilitar los test y en teoria hacer que no tengas que validar que una opercion no esta duplicada. y esto esta MAL, MUY MAL.
sin mencionar penalizaciones en bd por usar uuid y que en general, esto literalmente genera el problema de las validaciones que supuestamente "arregla". me explico:
En pagos el id siempre se genera en una nueva interaccion, desde bd porque si no lo validas internamente significa que alguien fuera puede modificar el flujo de la aplicacion para insertar, modificar y borrar datos que por mero historico se van a quedar en el bd para posterior validacion de errores si toda la logica de la aplicacion falla o es manipulada.
los test no se enfocan en que solo se devuelva lo que enviaste a bd, tambien que no existan flujos espureos que hagan lo del punto anterior. por ahorrarte unas lineas de codigo y creer que por que sois frontends son expertos en ciencia de computacion y hay que haceros caso es penoso, estas abriendo agujeros de seguridad que ya he visto explotandos anteriormente.
Por muy vagos que seais, siempre se escriben validaciones de datos en el backend y bd, que tambien colabora en el proceso, nunca jamas del lado del cliente que siempre sera sensible a ataques malintencionados
Limitaos a validar si el correo es correo y el string es un string y de un largo razonable, lo ultimo que necesitamos que nos digan a los backends como se hace una aplicacion.
Cuando me llegan "Genios" asi, ya les voy buscando remplazo, el ultimo me djio que deberia enviar toda la informacion por post, que el resto de operaciones me sobraban. se quedo sin trabajo al mes por estar llamando funciones de react que se llamaban a si mismas, como si las vistas de react fueran recursivas. al proximo que me llegue con esta idea tendra un destino igual
Mucho cuidado con este tipo de vídeos amigos developers. Desde el punto de vista más simple esto va en contra de las recomendaciones de OWASP. Se podría dar por cada punto descrito un detalle de como se solucionan estos aparentes "inconvenientes" en el mundo "back", pero creo que sería mejor ir a la fuente de donde han recopilado todo este análisis sobre el cual han realizado el vídeo, ya que quizás sea parte de una solución muy ad-hoc o experimental. Si es investigación propia, sería recomendable que revisen de fuentes confiables antes de brindar una alternativa que va en contra de muchas recomendaciones estándares en el mercado.
No se gana nada la verdad, el enfoque tradicional es el enfoque que se debe seguir... mira, esto son puras pendejadas, solo es una manera de inventarte nuevos problemas... paso de esto.
Todo tiene sus pros y contras. Esto solo es útil cuando tienes millones de usuarios y pequeñas mejoras en rendimiento son importantes. En el 80% de los casos probablemente no sea un problema los ID típicos, pero está bien conocer esta otra opción. Lo que en CodelyTV se habla suele ser arquitecturas enfocadas a grandes proyectos donde los problemas se disparan. Repito, el 80% de los casos probablemente sea sobreingenieria, una arquitectura hexagonal en una APP con 10 pantallas es tremendamente absurdo, pero si tiene 1000, la vas a necesitar
¿Puede ser el video de Codely con más Hate en los comentarios? ☠😂
Mas que hate, me encanta el debate que hay.
Al menos lo que yo veo es que comunidad de Codely tiene mucha gente que le encanta debatir, Es cool.
Porque algunos le echan la razon, otros se la niegan. Otros argumentan excelente y uno aprende mucho de estas cosas.
A diferencia de otros canales, yo veo este porque la gente siempre se arma debates buenisimos Ahahaha.
+1000!! Se ha generado un dejado muy interesante!!
Rafa rapea mejor que Eminem
Usa un Dto sin el ID y muerto el pollo.
Alternativa, pero validando muy bien el usuario: correo *único+ fecha completa+ hora completa con milisegundos
El único sentido que le veo a ordenar por ID es que el orden sea el de inserción en DB.
Para eso mejor tienes un campo created_at DATETIME que se rellene automáticamente cuando se inserta el registro
L take.
mmmm no me compro este metodo
Y todavía te quieren vender un curso 💀
la wea mala
Por favor, vocalizar mejor, muchas cosas no se entienden