filtrando por usuario desu
#55657 La unica dificultad que puedes tener es tener recursos anidados:
#55653 Que estructura tienen los recursos.
Si por ejemplo tienes un recurso Configuration dentro de tu Person, y que tengas endpoints especificos para /POST /PUT /PATCH /DELETE, que se encarguen de hacer attach/detach y modificar estas configuraciones para los usuarios.
Yo te recomiendo que no tengas esto si no necesitas una configuracion dinamica, es un caso de nuevo muy aislado. Lo mejor es que si quieres cambiar la configuracion, esta sea simplemente un campo dentro de Person y no otro recurso (en su propia tabla en db probablemente que necesitaras pasar foreign keys).
{
"Name" : "Fpero"
"Age": 123
"Configuration": {
(...)
}
}
Si tienes una lista de Person y quieres crear y modificar Person existen tres casos de uso.
- La lista de Person, en si, es un recurso y tienes un endpoint /POST listPerson o /PUT listPerson, que le pasas TODOS los Person de tu programa. En tu caso el ID y el recurso seria el ID de la lista de Person, no las person en si.
- Person es un recurso, /POST person y /PUT person, en este caso si deberias mandar multiples peticiones HTTP para cada caso, multiples POST para crear, y multiples PUT/PATCH.
- Tienes un endpoint para operaciones en batch, asyncrono, que requiere un modelado especial y es un caso de uso distinto, esto solo se deberia hacer si haces decenas de miles de peticiones http por segundo.
Yo recomiendo hacer lo segundo siempre, hasta que el numero de peticiones sea un cuello de botella en el servidor, entonces introducir operaciones en batch en tu API mediante 3. Las cuales son una API async tipica. En mi experiencia, hasta decenas de miles de peticiones por segundo puedes hacer 2 sin problema en un stack normal. A partir de esas 10k req/s 24h al dia ya es mucha carga que compensa optimizar. Eso miralo en las metricas.
#55663 Mejor aún, a mí me gusta más.
Pero si algo es un CRUD prefiero usar HTTP como esta pensado, y solo hace RPC sobre HTTP para casos de uso complejos de mi dominio. Al final estas ultimas suelen ser operaciones async todas...
#55664 Esa respuesta está mal porque tu código está mal, la mía está bien.
Arregla tu código de mierda y déjate de cuentos chinos.
Tanta tontería para cuatro formularios de mierda.
#55667 Te he dicho que mandes múltiples peticiones si es un recurso.
¿Cuantas peticiones por segundo tienes?
#55669 ¿Cuantas peticiones por segundo tienes?
PS: Cuando toda la clase de fperos lo ha entendido menos tu, el problema no es el sensei.
#55671Runig666:Si, y yo te he entendido desde el primer momento.
¿Y que problema tienes? ¿Cuantas peticiones por segundo tienes?
#55671Runig666:Tu solución
No es mi solución, es la única manera correcta, no hay otra.
#55671Runig666:Dicho metodo aparte sigo sin saber la respuesta de si lo harías POST o PUT...
Diseñar una API asíncrona ahora mismo escapa a tus conocimientos.
#55673 De nuevo, depende, te lo he explicado antes.
El mayor problema en el sistema distribuido es evitar hacer trigger de muchas operaciones equivalentes, si por ejemplo quieres hacer un delete de [a,b,c] y manda el cliente 3 órdenes (post o put) con delete [a,b,c] el sistema, idealmente, debería solo ejecutar 1 vez esa operación.
Una API asíncrona tiene 2 endpoints, uno para crear y gestionar el estado del job, y otro para obtener el resultado del job.
La manera creo más simple y fácil es hacer un /POST con delete [a,b,c] que devuelva un ID para ese job, y luego mediante un PUT pasar este job a RUNNING y que se ejecute, donde en otro endpoint puedes comprobar el estado y obtener los resultados.
Una modificación que añade complejidad a cambio de evitar duplicados, para evitar múltiples delete de [a,b,c] si es algo que puede saturar tu sistema, es que mediante una transacción al hacer el POST comprobar que el "delete [a,b,c]" es único (no está created o running, pero puede estar completed) en db mediante un hash, y luego de nuevo proceder ejecutando un PUT para hacer run. Pero para ello usas 2 peticiones HTTP y necesitas definir el hash que haga las operaciones únicas.
Ahora en tu caso de uso por ejemplo, imagina que quieres hacer un /PUT de múltiples recursos en batch, que pasa si el usuario me manda múltiples de estas operaciones en batch? Se sobre-escribe el resultado? En que orden se deberían ejecutar? El motivo por el que nunca debes empezar por el batch es porque añade dificultades y problemas de sistemas distribuidos a tu problema, y como nos ha quedado claros a todos, eres un fpero que actualiza 4 formularios de mierda.
Depende del caso de uso concreto, existirán problemas y restricciones de dominio, que al ser un sistema distribuido en lugar de una única transacción deberás gestionar. En el caso de los updates, pues el orden es un claro ejemplo. En el caso de los create, el no crear multiples recursos iguales, o correr hot paths en paralelo que puedan crear inconsistencias en el sistema.
A mis conocimientos no se escapa nada fpero, soy top 0,001% del mundo disenando APIs y HTTP en general, subnormal.
#55676 Juego contigo, desnudo las pocas capas que forman tu intelecto y las acomodo como quiero para burlarme de ti, hacer escarmiento público contigo y llevarte al fango.
Cuantas peticiones por segundo dices que tiene tu formulario?
AHAHAHAHAHAHAHA
En este foro no consideraría a nadie senior la verdad.
Todos sois muy malos, se os atragantan conceptos básicos como el POST o el PUT.
#55728 Hacían POST con los datos de la gente y mandaban sus contraseñas en el body.
Eso de hacer múltiples peticiones y encriptar era demasiado complejo.
je je.
Cuando un fpero os diga que Go es una mierda, que no tiene generics, le enseñáis una captura de código de Rust:
#55750Mubris:#55746 Pero en serio programas así o es coña? xD Me refiero al editor.
A que te refieres? Si, programo así.
El código es un ejercicio de un workshop de google que estuve haciendo ayer.
#55766 hace ya uno o dos años que voy sin sintaxis ni temas, me gusta asi, simple, claro, es más fácil de leer el código cuando te acostumbras.
además mis ojos son capaces de entender el AST de cualquier lenguaje que programe al toque y compilar código tan solo poso mi mirada encima del código.
usar syntax highlight y temas con coloritos, me parece, infantil, fpero, típico de estudiantes de fp o universidad noveles que no saben lo que hacen y tienen dificultades y necesitan guías para no cagarse encima. No tengo ningún problema y os recomiendo que os lo pongáis si aún sois malos programadores, pero llegará un punto en vuestra carrera, o quizás no porque algunos de aquí sois malos a decir basta, donde de manera natural veréis que estas cosas de temas, colores, y plugins para el editor te distraen más que nada.
#55771 vim mode y el lsp para el lenguaje que uses, algún linter, comprobador de dependencias y poco más..
Profesores buenos de universidad yo mismo por ejemplo, seguramente de los mejores profesores que han pisado una universidad en este país.
El futuro de la IA es vender a la gente que necesita sus productos.
Salen startups de debajo las piedras, a nadie le importa lo que hacen, son todo demos y pruebas de conceptos que no valen para nada.
Startups quemando los últimos montones de dólares del último batch de VC bullish.
Cuando pienso en el futuro me miro en el espejo. Yo soy el futuro.
#55811 Estaría bien que cierto top mundial, tuviese un hilo preparado de IA embedded con Rust, te imaginas?
Soy el mejor en todos los pesos. julio cesar.
#55812desu:Estaría bien que cierto top mundial, tuviese un hilo preparado de IA embedded con Rust, te imaginas?
Necesitas que te dé otra master class y te humille fpero?
Reformular la query de los usuarios es uno de los problemas típicos fpero... yo estoy pensando en tener un modelo que me normalice la query.
#55827Runig666:En ningún momento me había parado a pensar que el problema era el puto json que no estaba reducido..
Imagina no comprimir...
Cuanto llevas con esto? Para saber que x10, x20, x100 engineer soy respecto a ti.
Y OpenAI ahora que Sam se ha cargado al calvo de Ilya, a la puta calle, no tardara en irse a la mierda tampoco.
Las empresas tecnológicas están monopolizadas por psicópatas.
Salvar el mundo? Ayudar a la gente? Bueno... hacer un buen producto? Ni eso. Solo quieren dinero dinero y dinero y ser gurus como Steve Jobs.
Manager, directivos, VP y demás c-level son todos unos enfermos mentales. Seguidos por sus perros falderos los middle managers, psicópatas de pacotilla que hacen las guarradas detrás de las cámaras.
#55834 Eres imbécil? Han echado a la calle a todos los ingenieros que han levantado la empresa y quedan cuatro charos enchufadas de PM y vendidos a Microsoft.
Van a exprimir la gallina hasta que no de más dinero, pero a la mierda, ya se ha ido.
