Voy a analizar los primeros 8 minutos.
Primera pregunta del minuto 0 al 3:05
Preguntan si los DTO de comandos son immutables, porque se ponen getters? porque no hacerlo publico y ahorrarte ese codigo?
Su respuesta: un sin sentido, un sin sentido de bobadas por no entender que cojones es un getter/setter ni su motivación histórica. Hablan de clean code, buenas practicas y tradeoffs ... no lo transcribo. miradlo vosotros mismos. las tonterías de SOLID y demás bobadas de siempre.
respuesta correcta: el motivo por el cual se usan los getters es por las librerias y frameworks de reflection de lenguajes como java, c# y demas... hoy en dia no son necesarios. de hecho en lenguajes modernos son malas practicas porque no tienes oop como en go o rust. en go i.e lo que se fuerza es a poner el nombre del field como te llegara en el DTO para que el serializer/deserializer lo haga bien.
type User struct {
Name string `json:"name"`
Type string `json:"type"`
Age int `json:"Age"`
Social Social `json:"social"`
}
en rust teneis https://blog.logrocket.com/json-and-rust-why-serde_json-is-the-top-choice/
Es decir, hacer getters/setters solo depende del lenguaje, si es un lenguaje viejo lo utilizaras, pero no para proteger tus dtos o tonterias asi. es por motivos de reflection que se arrastran desde hace 20 a;os... Mejor no hagas estos patrones anticuados. Yo recomiendo el estilo de go y no usar reflection.
segunda pregunta en 3;18
como hacer un login o peticion, cuando "no esperas una respuesta" al usar "commandbus"
La pregunta la re escribo. La cola es async, si algo tarda o envias un command a un bus, no puedes bloquear y esperar. Es la gracia de la cola. Por tanto como harias un login o algo del estilo?
su respuesta: primero el ricitos no ha entendido que es un commandBus y dice una chorrada. su amigo pelado le corrija al instante... "que el commandbus es asíncrono y es la puta gracia de nuestros cursos ricitos".
Justo después me he perdido, de repente el ricitos le da la razón al otro, el otro dice hay commandbus sincronos y asincros y esa es la clave, el ricitos dice exacto, como si esa hubiese sido la respuesta que quería dar cuando la cara de gilipollas mientras le contestaba no decía lo mismo e inmediatamente se va por la ramas.
Se va por las ramas el ricitos pero mucho, se pone ha hablar un caso donde el cliente le manda toda la info de un usuario para el caso de uso. El calvito, en lugar de corregirle, le sigue le rollo.
Se siguen liando, el calvito le sigue echando le;a al fuego. La pregunta no era esa. La pregunta era como gestionar un login en un bus asíncrono... Pero se lían y se lían. Nada que decir.
"Pues perfecto, siguiente duda".
respuesta correcta: el servicio devuelve un id para consultar y luego lanza la petición a la cola... que es el protocolo asíncrono habitual. podéis consultar por ejemplo el dise;o de api de google https://google.aip.dev/151 https://google.aip.dev/152
Otra alternativa es tener stream/sse/sockets. aunque por defecto la guia de google no recomienda estas estrategias pueden tener sentido en ciertas peticiones.
la respuesta mas correcta seria. depende del caso de uso. en algunos puedes tener un sse abierto esperando la respuesta o error. otros te devuelve la id con info y metadatos para que el cliente decida como actuar.
Dos preguntas en 8 minutos sobre sus cursos y su contenido. Dos respuestas completamente erróneas donde no han respondido lo que les preguntan ni han dado argumentos sólidos. Y no lo han hecho porque no entienden ni lo que les han preguntando ni lo que en sus cursos explican.
NO TIENEN NI PUTA IDEA.
