Por qué generar los IDs desde el Frontend y No desde la Base de Datos: FAQs |
Vložit
- čas přidán 25. 09. 2023
- La semana pasada subimos un vídeo sobre por qué no generar los IDs desde la Base de Datos, sino desde el Frontend y se ha generado un debate muy interesante sobre ello. Vamos a ver los TOP comentarios y resolver las dudas.
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🧔🏻 Twitter Javi: / javiercane
├ 💂♀️ Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
└ 📕 Catálogo cursos: bit.ly/cursos-codely - Věda a technologie
Creo que el problema radica generalmente en lo mismo. Somos mucho de "o" y poco de "y". Ya sabemos las ventajas y desventajas de cada uno. Los programadores tenemos que estar una capa por encima de eso. Tenemos que saber implementar los dos correctamente, y saber donde poner cada uno. El debate genial, conocer los dos puntos de vista, pero no decir que lo del otro está mal. Es lo mismo que el tema de arquitecturas. No es buscar la solucion perfecta. Es buscar la solución mejor para un caso en particular. Saludos, y seguid así! 👍
Con la unica ventaja que me quedo de usar UUID creado en el front es el de las operaciones offline. y pues si le tienes miedo a las colisiones, un simple algoritmo de "volver a intentarlo si ocurre un duplicate" lo resuelve y no pasará casi nunca.
También ayuda en la proyección de los eventos, ya que el insert en la bd no debería retornar nada, solo una excepcion en el caso D...
A los que no les gusta el UUID, pueden usar un ID en Base58 así como hace CZcams. Me gusta generarlos en el frontend para evitar problemas con el id opcional, además que un comando no debería retornar nada.
Ventajas:
Simplificas muchísimo el código para poder funcionar en modo offline (Puedes tener relaciones entre objetos n:1, 1:n, n:n en local y sincronizarlas sin tener que preocuparte de los id)
Te evitas tener un campo id nullable en el cliente
Desventajas:
A nivel de db, primero tienes que comprobar si existe para hacer insert o update, con la sobrecarga que tiene tener que revisar el índice para cada operación
Pierdes la capacidad de ordenarlos por id (saber con qué orden se han insertado, aunque lo puedes suplir con otro campo timestamp o autoincrement que no necesitas mapear)
Si hay algún bug, se complica bastante si tienes que hacer consultas directamente a la db, (es mucho más fácil localizar un elemento por un int que por un uuid, pero siempre puedes copiar y pegar)
Si usas uuidv7, puedes ordenar perfectamente, sin necesidad de un campo autoincrement.
Uhmmm no lo sé si puedes ordenarlos y no se con que problema te puedes topar debugeando
La primera desventaja que dices, realmente no te hace falta comprobar si ya existe ese UUID, eso ya lo hace la base de datos, configurar la columna para que sea de valores únicos y simplemente cuando se intente crear un nuevo registro con ese UUID, te devolverá un error la base de datos.
De la forma que tu quieres trabajar offline la mejor forma es utilizando UUID, y bueno en este caso si se tiene que hacer desde el front podrque no queda de otra ya que estas offline, luego al retomar conección se lo manas al back y listo a la db, y como tiene UUID santo remedio no vas a tener problemas.
Ahora en caso de que la db no este estructurada con ids de tipo UUID, se me ocurre que podrias usar el id UUid cuando estes offline, al conectar se manda al servidor y este debe estar preparado para recibir esos ids y pedir a la bd cual es el ultimo id de la tabla a la que se va a insertar esos datos luego se sustituye ese UUID por el que da la base de datos mas incremento y todo esto desde el back, y asi con los datos que se carguen en otras tablas.
Creo que tus desventajas no lo son del todo o son fácilmente mitigables:
La primera eso no lo tienes que comprobar, al dejarla como PK la BD se encargara de lanzar la excepción.
La segunda: hay versiones de UUID atados a la fecha asi que podrias aprovecharte de eso, para no perder el orden aunque como no puedes fiarte del consumidor podrías usar una columna created_at o incluso tener un autoincremental solo a nivel de BD pero que nunca lo expongas.
Tercero: me toco hacer debug de este tipo y la verdad que terminas mirando solo los ultimos 3 o 4 digitos del uuid asi que realmente no es un problema.
Ahora una desventaja que si veo puede ser el espacio en ram por lo indices pero explicaron como solventarlo.
A si que particularmente pienso que las ventajas superan las desventajas.
Desde luego un cambio de paradigma siempre implica una negación, el cerebro es experto en dar justificación o razón de algo de forma no fundamentada. Vuestro vídeo y aportación para mi ha sido muy útil. Gracias
Es de una altanera soberbia justificar la negativa a la crítica alegando falta de razón. El ID, muchas veces es necesario (casi siempre) que tenga un sentido de uso. Si yo quiero darle a mis clientes su ID de cliente, y tengo hasta 9999 clientes, le doy un código de 4 dígitos, yo no le puedo decir "acordate tu código de cliente que es 1212FAD15-12AC15F12475-5652565-568956". Seamos coherentes, primero el "uso", después el fanatismo tecnológico.
@rickkk226 Y porque le darias tu PK al cliente? No me parece buena idea acoplar a tu cliente (persona) con un detalle de implementación de tu sistema. Es más supongamos por un segundo que eso no va a generar un problema en el futuro, la experiencia de usuario me parece horrible. Porque mi usuario tiene que acordarse de un numero que yo le doy? Ya tiene sufientes problemas mi usuario para que yo le de uno más.
@@marcelodf12 por un lado, estoy de acuerdo con tu argumento, mezclar detalles de implementación con la experiencia y el uso, es algo a evitar. Pero por otro lado, si se ve. Ya luego podemos afirmar que no es la norma, pero se ve. Lo he visto en casos como transacciones financieras y rastreo de ordenes
@@rickkk226 quizás soy yo que no lo entiendo bien, pero me gustaría saber por qué piensas que el ID que le das a un registro tiene algo que ver con el identificador que vas a generar para un usuario?
Piensa, por ejemplo en cómo Google Drive almacena los documentos, tienes un identificador único para cada documento de la nube, otra cosa son los metadatos del archivo, propiedades etc. te has preguntado alguna vez qué pasaría si de una entidad como puede ser un documento, ahora necesitas generar una ramificación o un control de versiones rudimentario? Los ids solo identifican el registro(fila,row,etc), lo que ocurre en muchos casos es que las personas utilizan ese identificador más allá del propósito que tiene el propio concepto de índice.
xD bro, esto me hizo recordar ese mítico video de "No uses más MVC" o algo así era el título que en su momento dió sus chicha 😅, es que Frontend no suena precisamente a Controller, pero sin más, se aprecia sus trabajo constante y a seguir adelante 😁
En la empresa donde trabajo tenemos un estándar de desarrollo en Back para todos los proyectos en los que trabajan las distintas células y es que al momento de crear un usuario, se utiliza el verbo POST recibiendo los datos y en el back se genera el UUID que se inserta con ese usuario en la tabla más el ID autoincremental. Luego se devuelve en la respuesta del servicio el json con el usuario nuevo con ese UUID generado. Luego el Front se encarga de enviar ese UUID cada vez que necesite hacer algo con ese recurso.
Same here! Creo que aqui lo generan en front porque no tienen una capa de back tal cual, o eso es lo que entiendo del diagrama inicial que colocan. Generar el UUID es la mejor practica! Concuerto con eso :D
Yo uso la misma estrategia. Generar el UUID en front tampoco me desagrada.
@@techtiendo no para nada, pero generalmente dejamos ese trabajo al back.
Por qué generan id incremental y uuid? Acá lo hacíamos pero no tenía sentido, al final solo usamos uuid
El contenido es muy bueno pero quisiera dejarles mi humilde opinion, deberian si van a grabar videos largos, buscar la forma de separar contenidos para que la gente no tenga que ver un video de una hora para informarse de algo puntual, hay muchas formas de hacerlo, espero lo tomen en cuenta
Me sigue pareciendo mejor crearlos en la db, aunque no he usado CQRS. Dejaria el User con id obligatorio y otra clase con el id opcional (o algo asi, no le he dado muchas vueltas porque ya es tarde)
Yo creo que la razón por la que causo tanto revuelo esto, es porque en el video anterior, dicen que la persistencia es VOID, y que incluso no recibes una respuesta en frontend, por lo que aquí es donde entra la duda que tenia el chico en el directo, de que es raro que te retorne un 200 tu petición a la api, cuando puede que por detrás surgiera algún error, pero como según su diagrama de flujo, el front end ni se entera de que fue lo que paso por detrás, ahí entra toda la inconsistencia de brechas de seguridad, etc.
Os pongo el problema que tuvimos. Se ha generado un proxy que gestiona una aplicación de Drupal, ese proxy al final no es más que una ruta y, al realizar la petición, aunque el nodo final devuelva un error 500, Drupal no puede variar ese status code, porque entraría en la gestión de errores del mismo (no me digas por qué si o por qué no, porque no tengo ni idea de Drupal). El caso es que, todas las peticiones que se realicen sobre esa "API" siempre devolvían un 200. Mi duda es que si ocurre esto en el modo tradicional, aunque devuelva un 200, en la respuesta la aplicación se enteraría de que algo va mal, porque el modelo de respuesta no tiene los datos esperados y puedo controlarlo. Pero si no espero ninguna respuesta, yo recibo el 200 y tiro pa'lante (que es justo lo que nos ha pasado) y hasta llegar a descubrir ese problema nos ha llevado tiempo. Como dije en mi comentario anterior, no es que lo vea mal, es que hay muchos factores en toda la arquitectura de un proyecto que no tiene en cuenta y que conlleva un riesgo. ¿Es algo que no debería ocurrir? por supuesto, de echo, es algo que se ha arreglado, peeeero... ¿sobre quien cayó la responsabilidad de ese error? ahí es dónde un equipo y una empresa pierden tiempo y dinero. Esto es un caso real aplicando el uso de UUID desde el frontal. También es verdad que a partir de arreglar ese problema, la aplicación funciona sin inconvenientes. Un saludo!
Min 5.33 - Pero en node js tenemos el modulo Crypto que ahora si no me equivoco es nativo ya verdad, yo lo estoy usando y esta genial.
Los id una tabla de invoices no tienen ninguna relacion con el autoincrement de las facturas, son datos completamente distintos. Los id de las tablas los generan generalmente los ORMs, o en ultima instancia la DBs que tienen sus propios procedminentos para evitar colisiones. No tengo idea de porque aun se utilizan los autoincrementales, los UUID hace muchos años que son la forma mas común de generarlos. Los ids son internos, si necesitas, como cliente algun identificador adicional como un id de producto, por ejemplo, agregas un campo distinto, con caracteristicas propias. En que caso es util generar los ids manualmente?
claro, cuando lo tengas que digitar es mejor "a812e97c-9ef2-46b0-ae5a-6ff816c5d1b3" que algo como 35. O indexar ese ID en la BD en vez de usar un integer. Las soluciones "universales" son para el universo, pero si tengo una zapatería con 400 modelos no necesito uuid y complicaciones
Bueno, al final puedes hacer lo que quieras si estas desarrollando una App para una Pyme en donde nadie te supervise o cuestione... En lo personal, hay varias razones por las que prefiero que la BD gestiones estos ID o PK auto-incrementables.
Recuerda que un PK también, y de seguro será una FK en la relación entre estructuras de datos y las RDBMS AMAN las PK y FK NUMERICAS ya que son especialmente optimas para ser ordenadas y, en consecuencia, encontrados...
Desde mi punto de vista esta discusión es tan básica y un poquito fuera de contexto como plantear que conviene aprender PHP versus otros lenguajes o plataformas muchísimo mas robustas (y bien pagadas, dicho sea de paso).
Pero que tal si el front manda un json con datos del cliente a cargar, sin id, el back recibe ese json y ahi al recibirlo genera el uuid, se lo agrega al json, luego lo mana a la base de datos para cargar y a la vez manda un req al front con el cliente nuevo y el id generado.
Es lo que están diciendo en este video que no se referían a Frontend si no al Controller (backend) tal y como dices y como yo aprendí hace 5 años y uso en algunos casos
La ventaja es no tener que esperar la respuesta para poder saber el ID? Si no esperas la respuesta de la BDD, cómo sabes que el dato se ha ingresado bien? Y si de todas formas se está esperando la respuesta para ver si ocurrió un error, cuál sería la ventaja entonces?
En geneal, se puede usar los UUID de front end, como una herramienta mixta con los ID index autonuméricos para una política de logs para una db robusta es obligatoria.
Lo lógico sería pasarle un UUID pero la tabla debe ser indexada autonumética.
Con triggers after insert, update deberían crear en una tabla tableName_log con su propio autoindex numérico, el ID index de la tabla tableName y el UUID. Además, de esa manera se le pueden tercerizar datos como el timestamp, el idUserName y el tipo de evento: Insert, Update, etc
Eso genera otra ventaja. Puedo poner un eveneto asyncronico a insertar de un solo bunch, unos 1000 registros y poner otro llamado asíncrono que me de metricas de la tableName viendo cuantos de los UUID se han generado y de paso recuperar los IDs. Con ello, si loopeo en asincrono puedo hacer una progress bar, haciendo solo progresar a aquellos llamados con mayor count que el listado de UUIDs
Las peticiones http tienen un status... Con eso sabes si la respuesta fue correcta o no
En todo caso si la base de datos ya esta estructurada y tal, creo que se podria aplicar esta idea de obtener ese ultimo id de la db, pero desde el back, yo creo que no hay que mezclar roles el front todo lo estético y lindo del sitio, tambien poder hacer valoraciones si, pero el trabajo de bases de datos como es este caso dejarlo al back, que digamos es lo menos expuesto al cliente, nada es seguro pero esta menos accesible. No se es para mi lo mejor. Sino es como empezar a hacer código espagueti.
Es mucho más rápido y como dicen ya hay librerías en muchos lenguajes para trabajar con los uuid sin embarg, qué pasa con los consecutivos, los de una factura por ejemplo. A no ser que el consecutivo sea el uuid(que no sería ideal) se podría tener consecutivos sobre todo generándose de forma asíncrona (offline)?
Una factura tal y como yo lo veo es una consecuencia de. Es decir, es un evento que algo lo desencadena. Desde mi humilde opinión. No veo para este ejemplo, que el cliente tenga interactuar para crearlas/actualizarlas
Cuando genero una factura, es porque antes he finalizado cualquier tipo de pago. Eso desencadenara un evento que envias a una cola. El handler de ese evento es el que se encarga de generar el id, que para este este caso si que podría ser único y consecutivo.
@@kuja69 si, digamos le dije factura, tengo un caso puntual, un sistema que genera propuestas con sucursales, estás sucursales a veces están offline y el consecutivo de la propuesta debe ser único, usando uuid se puede pero para el usuario final un consecutivo con esa cantidad de caracteres no lo veo amigable, así sea sólo una parte del uuid
Hay una cosa que no he entendido y es el cambio de verbo HTTP.
POST es para crear y PUT para actualizar.
¿Por qué cambiar por usar UUID?
Supongo que es porque no estas creando muchas veces un usuario distinto, sino creando o actualizando el mismo, por el UUID
Hola
Los estándares RestFul no están definidos como si de una regla estricta se tratase. Pero en cuanto a los métodos HTTP lo que se ha querido implementar es:
POST para crear recursos
PUT para crear o "remplazar" recursos
PATCH para actualizar parcialmente los recursos
La diferencia entre POST y PUT al momento de crear un recurso, es que el POST se ejecuta contra la colección (/users) y el PUT se ejecuta contra el recurso a crear (/users/guuid). NOTA: para creaciones en lote y para los fines de ejecutar una sola llamada a la API, el PUT se realiza contra la colección (/users)
La diferencia entre PUT y PATCH al momento de "actualizar", es que PUT no está pensado para actualizar, más bien está pensado para remplazar el recurso.
NOTA AL PIE
* Todo dependerá al final de la implementación (GraphQL) por ejemplo, usa POST para casi todas las operaciones.
El motivo de la polémica de este vídeo es que se están mezclando dos casos diferenciados, por un lado, se habla de usar UUID como identificador único de la entidad o recurso, y por otro, el delegar a Frontend la creación de estos identificadores.
Para el primer caso, si en nuestro dominio se habla de identificadores de las entidades, es razonable que esta tarea se ejecute en la misma capa de dominio y no sea una responsabilidad del repositorio, por tanto, UUID es algo que ayuda y no creo que existiera polémica en este punto, obviamente se podría debatir los pros y contras, ej: índices vs latencia.
Ahora bien, en el segundo caso, ¿debemos delegar a Frontend la creación de estos identificadores?, no dudo que en algunas soluciones sea válido, pero el ejemplo indicado en el vídeo no está bien enfocado, y me explico:
A la hora de crear o actualizar, Frontend llamará al mismo endpoint: PUT /entidad/{{uuid}}, entonces, si en nuestra lógica de negocio se habla de la operación crear y la operación de modificar, ¿le vamos a dar al mismo endpoint dos responsabilidades diferentes?
¿Qué ocurre con los parámetros que solo se deben introducir a la hora de la creación? ¿No supondría tener que dejar el OpenAPI más abierto o hacer uso de oneOf para que luego tenga que validar en el handler si es de un tipo u otro?
Y se ha hablado mucho del modo offline, evitando que en Frontend tengamos que tener una entidad con el ID nullable, pero y que ocurre con el resto de campos, ¿Frontend también será el encargado de dar estos valores y luego enviarlos por el body? ¿la fecha de creación también? Sería curioso poder llamar a una API e indicar la fecha de creación de un tweet.
Un saludo!
Si el ID lo tiene que generar el back ¿cómo se puede hacer esto en un patrón CommandBus que no espera devolverlo?
Muy buena técnica x2, y no hacía falta este video, ya que se explicó demasiado bien. De todas maneras, gracias por el mismo (video), ya que debido a mi preocupación por la seguridad, siempre presto atención a todo, por más absurdo que sea, pero ya con esto me ahorro seguir leyendo quizás tonterías. Muchas gracias.
NOTA: Para los demás en esta linda comunidad, por favor, si no saben el tema a profundidad, no aseguren cosas que realmente no saben; a esto se le llama el efecto Dunning-Kruger. ¡Mucho cuidado con esto!... Saludos.
Llevo escuchándolo 20 mins y sigo pensando que es una troleada
Por qué?
@@osvaldocol Los DNI no tienen por qué ser únicos. Un DNI tiene 8 digitos numéricos y el alfanumérico se genera a partir del numérico. En españa hay ~48 millones de habitantes, ~35 millones de nacionalizados.
@aegio76 no creo que sea una troleada, es posible hacerlo pero yo al menos no le veo el sentido... A menos que por temas de performance no quieras claves primareas y foraneas en la base de datos o tengas un NoSQL y relaciones todo por lógica PERO quieras tener un ID para relacionar registros... pero también podrías hacerlo en el Backend y con una buena estructura de datos en el front no necesitarías tener disponible un UUID antes de la creación de la entidad en la base de datos. Sigo sin entender por qué necesitan generar ID's en el front.
@@osvaldocol Una cosa es usar UUID y otra cosa es generar estos desde Frontend. Si usas UUID generados desde Back. Y regresas el id en la respuesta que el front igual tiene que esperar de si la creacion fue exitosa o no.
No tiene por qué, si separas el modelo de la persistencia. Es decir, adoptar UUID como ID *de las entidades* me parece una forma tan correcta como cualquier otra, personalmente pues ni me gusta más, ni menos. Ahora, que no intenten convencerme de que ese UUID sea *además* la columna contra la que se crea el índice clustered en la BD. Para ese cometido, se usa SÍ O SÍ un autonumérico. "Change my mind", como dicen por ahí ;-)
😂😂😂
Dónde se compro la camiseta de 'Más vale feature en prod que cientos en backlog'
dos uno...
viola el principio de responsabilidad única de Solid, el front no es el responsable de la lógica y menos la generación del IDs, me parece una mala práctica debido que cada app que interactúe con la api tendría que detener esta funcionalidad de generación de ids y eso haría que se repita código
Cómo puede ser que alguien intuitivamente piense que de un identificador que tiene matemáticamente más dígitos de los que un cerebro puede imaginar, ahora le vayan a colisionar sus miserables 10.000 pedidos, como si son 10 millones? Creo que hace falta primero entender qué es un uuid, su mecanismo de creación y no es que sea improbable, para mí es imposible.
Y no todo es crear usuarios, porque la gestión offline de los registros es necesaria en apps que sincronizan a posteriori, los eventos en una cola, y un largo etc.
Quien solo tiene un martillo 🔨 todo le parecen clavos.
Y si ves que al hacer una petición con uuid te devuelve una respuesta inesperada puedes manejar para repetir la petición generando uno nuevo puntualmente para el registro erróneo. Este acercamiento tiene claras ventajas, es como pedir a alguien un número de cien millones de millones de dígitos y que intentara repetirlo, ni es coherente siquiera pensarlo. Me da miedo que para los 1000 usuarios me vaya a colisionar, venga ya!😂
Que el UUID sea un buen identificador: SI, lo es.
De que porque es un buen identificador hay que usarlo si o si: NEGATIVO.
@@SimaDamian En eso estoy de acuerdo contigo. La idea es que a muchas personas les cuesta comprender que en una inmensa mayoría de circunstancias un identificador numérico también supone una desventaja frente a esta aproximación, y en especial con grandes volúmenes de transacciones.
Mi comentario va en la línea de no inventarse obstáculos, es decir, si no comprendes el planteamiento quizás tampoco sea coherente decir que van a colisionar unos pocos miles o pocos millones de registros solo porque no son secuenciales.
Y si te fijas incluso pequeños proyectos como pocketbase ya te dan esa posibilidad de usar uuids como índice porque en muchos marcos de circunstancias será más sencillo manejarlos. Habrá casos donde no suponga una ventaja a tener en cuenta.
@@Iron_cryptus pues un tema es que el id sea propio de la infrastructura, sea autoincremental, UUID o lo que sea.
Otra cosa es que lo mandes desde el front. Esa idea no comparto ya que hay muchos motivos en los cuales no funciona
Después, tienes otro tema (sobre todo en las db no relacionales) en las cuales es común el uuid dado que facilita el concepto de datos distribuidos.
Si hay 20 usuarios creando recursos desde el front cómo evitar la colisión de datos? Cómo se asegura la cardinalidad de los registros? Sigo sin estar convencido, es crear problemas donde no los hay.
Segun Chat Gpt cual es la posibilidad que esto ocurra? en términos matemáticos? lanzar un dado y sacar siempre 6 sin fallar durante un tiempo aproximado de miles de millones de años. si trabajas offline es muy beneficioso puesto que la productividad de las personas no debería depender del internet constante.
Si consigues generar 2 uuid iguales ve y juega la loteria 😂
Pero ya en serio, no es inventarse problemas donde no los hay y entiendo que parece una sobreingeniería, pero es que en muchos mas contextos de los que parece puede ser muy útil. Algo tan simple como tener mala señal. Que pasa si pierdes la respuesta desde el backend y tu rest no es idenpotente? Al no serlo tendrias que primero preguntar si el recurso se creó antes de enviar otro post. Sin embargo al usar esta solución tu servicio se vuelve idenpotente significa que si tienes un timeout reenvias el put y listo, no te preocupas de que se te creen dos entidades.
Es casi imposible una colisión incluso para una app con 1 millon de usuarios haciendo registros al mismo tiempo, es casi lo mismo que costaría desencriptar una contraseña de 8 caracteres al azar. Si tienen apps con menos de 10000 usuarios qué miedo tienen con las colisiones?
La unica ventaja que trae es darle una identificacion a entidades en el front sin estar guardadas en la base de datos, pero creo que es algo que igual pudiese manejarse desde el front, y con un buen uso de cache se pudiesen resolver. Definir un ID, es definir la asociacion entre entidades, algo propio del dominio de una aplicacion. es prudente trasladar la logica de un negocio al front?
Nunca. Aparte del hecho de que, si es verdad que es *el front* quien genera ese UUID, te lo pueden "romper" como le parezca a cualquier atacante. Y ahí ya la hemos liado parda.
Es sólo una metodología para uno utilizar autoincrement en la base de datos. Cosa de gustos.
Teniendo en cuenta que el ID debe generarse en front, ¿lo mismo sería para una fecha? Por ejemplo, la fecha/hora de modificación de un elemento/tarea/estado. De ser sí, ¿qué información sí debe ser generada por la BD?
No me dio tiempo de llegar durante el directo :S
No debería, puesto que el usuario podría modificar la query y poner la fecha que quisiera. Imagínate que tu aplicación deja 15 días de prueba gratis, sabiendo eso, podría crearme un usuario desde Postman y poner que la fecha de creación es dentro de 10 años, pues tendré acceso gratis durante 10 años y 15 días.
Mmm no, en realidad los timestamp ya te los generan de forma automática muchos dbms. Y sí no lo hacen, por temas de seguridad tú tienes que definirlos en el back.
¡Gracias por el feedback!
recuerda que es solo una opcion. no se tome a pie de la letra, en software hay siempre muchas formas de solucionar las cosas y de hacer las cosas. Yo entiendo el motivo por el cual lo hacen y lo respeto pero no lo hago y no tengo esos problemas que ellos comentan. Por tanto afirmo que es simplemente una forma de resolver y no "la forma de resolver" saludos
@@SimaDamian Muchas gracias, lo tendré en cuenta.
No entiedo lo que defienden finalmente, el uso de los UUIDs?, Para utilizar UUIDs no necesitas utilizar librerias externas, las DB las utilizan, no era común para MySql, y aun miro miles de ejemplos del uso de autoincrement, pero ya el mismo MySql los ha adoptado hace un tiempo atras.
Lo mas importante en mi opinion es para manejar la Idempotencia como manda Dios. Pocos programadores saben eso.
Si, se ven muchos comentarios en el chat del live, diciendo que se pueden corronper datos mandando a crear varias veces con el mismo id.
tambien creo que la confusion viene del PUT, ya que el standard http dice que POST para crear datos y PUT reemplazar un recurso que ya exista.
Ahora la idempotencia es manejada en front? xD. Por lo menos si crea esos ids en backend estaría un poco mas de acuerdo!
@@SimaDamian de donde sacas que la idempotencia se maneja en front?
@@hck1bloodday pues! el video está planteando usar el UUID desde front en vez de ID de db y @israzulka habla de idempotencia, pero no tiene que ver con UUID del lado del front porque la idempotencia no tiene nada que ver con el front. por eso el sarcasmo, porque un supuesto motivo al final no tiene que ver con el tema en cuestión (UUID desde el ftont)
De todas formas, no le des importancia!
@@SimaDamian la idempotencia no se maneja en el front, solo es la generacion del UUID que se envia al back, alli si se tiene que manejar la idempotencia, imaginate si un user le da mas de un click al boton de pagar, como lo planteas el backend generara 3 pagos y un monton de fallas. Obviamente tienes que implementar el mecanismos correctamente. saludos
¿un poquito de polemica? xD solo un poquito....
hay muchos articulos que hablan sobre el peor rendimiento de los uuid, czcams.com/video/OAOQ7U0XAi0/video.html. Seguramente se pueden aplicar parches y mitigar, pero tiene que estar muuy justificado, no creo que facilitar el testing sea una justificacion suficiente.
Es útil para sistemas distribuidos
Como puedes confiar en alguien que dice "habían" algunas cositas interesantes...
bloqueado rey
Mas videos asi!
Depende del concepto, de lo que busques y el tipo de proyecto que estas haciendo
Ver más haya de lo conocido no siempre es fácil 😂
Si al ver el vídeo te parece un sinsentido, es que aun te falta por aprender. Por ejemplo, no puedes decir que conoces CQRS si no estás familiarizado con este tema.
Esto no se lo han inventado ellos, es un tema en discusión que, aunque no es una solución perfecta, tiene sus ventajas.
y sus desventajas. como si el front siempre conocería todo lo que pasa en back. si asumes que tu back es un pasa mano a db, puedes apostar por estas definiciones pero es solo un caso puntual. lastima que no aclaren correctamente.
uhm que es conocer todo del back? IDs es algo q expone el backend al publico, no es un detalle interno. Que lo genere el front o back es independiente del resto del funcionamiento interno del back, como tampoco es que sea válido solo para CRUDs basicos.
En realidad si es algo basico lo q implementas no vale la pena hacer esto, pero si es un sistema mas complejo te puede dar mas beneficios que desventajas, sobretodo si sigues algunos patrones de diseño y arquitectura.
Tiene las desventajas de rendimiento de usar UUIDs o agregar algo de complejidad extra al cliente, esa parte si! está claro no es un silver bullet.
@@craigwinkler4278 No. por ejemplo si el objeto interno tenes usuario, perfiles, grups, roles, etc. pero el objeto publico (DTO) de creación creas un usuario y su perfil, son 2 ids distintos, tambien tendrías ids de relaciones etc. Es una cuestión de lógica de negocio como se crean esos ids y no es cuestión del front. Este y muchos otros ejemplos son demostrables del porque eso es solo para un caso particular y cuestión de gusto nada mas.
Ojo que la creación de ids no es lógica de negocio, a mí gerenta del departamento de logística no le interesa como creo los ids