Feda /dev/ - No Javascript allowed

#51154eXtreM3:

Puedes tener tu aplicación funcionando perfectamente síncronamente y si el día de mañana, por lo que sea, quieres implementar colas, no debería afectar absolutamente a nada de tus capas intermedias, mucho menos a las reglas de negocio ni a los casos de uso que ya tengas.

Si tu aplicación cambia de sync a async y no tienes que cambiar absolutamente nada más que la infra, escribe un libro y publícalo porque te haces de oro.

#51155 a ver, a ver. Hablamos de que ya tengas al menos tu aplicación orientada a eventos.

Cuando quieras pasarla a asíncrona (con Rabbit, que es lo que conozco y tengo en producción en varios proyectos), lo único que tienes que hacer es la implementación de Rabbit configurando el exchange correspondiente y las clases consumer y publisher.

También puedes controlar el tema de eventos duplicados.

Estoy bastante seguro de que si cambiase rabbit por sqs o cualquier otro gestor, lo único que habría que cambiar sería esta implementación y quizás, las clases de los eventos para cambiarles el nombre y la clase de la que extienden (por ejemplo DomainEvent que se encuentra en un único sitio Shared) para garantizar el mismo formato del payload. Y FIN.

#51156 haha x'D

introducir HAHAs x4

No sabía que el precio de los tokens se había disparado tanto.

Bromas a parte, ¿Alguna recomendación de bibliografía sobre el tema tratado? Como FPero que soy admito que habría tirado por el punto que defiende eXtreM3, me gustaría saber cómo se suele afrontar ese tipo de decisiones desde empresas más... profesionales.

#51157eXtreM3:

Estoy bastante seguro de que si cambiase rabbit por sqs o cualquier otro gestor, lo único que habría que cambiar sería esta implementación

Y yo te aseguro que no porque lo he hecho, o al menos lo he intentado, y no sólo tuvimos que rehacer toda la capa de comunicación, sino que tuvimos que tirar media aplicación a la basura porque no es lo mismo trabajar con mensajes que con eventos. Cosas tan sencillas como que si enchufas dos consumers a la misma cola en Rabbit el mensaje sólo lo procesa uno de ellos y el otro no lo recibe nunca, mientras que en Kafka lo pueden consumir todos los consumers del grupo, te joden la vida si montas tu app pensando en eventos y luego tienes que pasar a mensajes.

#51158 Desde la ignorancia (dado que en el sector que yo me muevo la asincronía apenas existe), ¿Es posible que algo sea 100 % asíncrono?

¿No debe haber al menos un thread siguiendo una ejecución principal?

Por ejemplo, una web, aunque tu primer llamada sea una función asíncrona que ya te monta toda la web y dispare más funciones asíncronas que hagan lo que tengan que hacer, ese primer punto en el que llamas a esa función es síncrono y ahí se va a quedar, ¿no?

#51162 Te pongo un ejemplo.

Tengo una app de ecomerce. Quiero que cuando se añada un item al carrito (evento 1) se actualice el stock del item (acción A), el carrito (acción B), y le envíe un correo al supplier si el stock queda por debajo de una cantidad mínima (evento C). Es decir, necesito 3 listeners. Listeners, no consumers.

Puedo hacer que mi app implemente un servicio addItemToCart (capa de servicio) que al añadir un item llame a UN (mayúsculas para reiterar) producer (capa de infra), el producer envíe UN evento a UNA cola y TRES consumidores lo procesen y llamen a los servicios (capa de servicio) correspondientes. Eso en Kafka. Ahora imagina que cambias a Rabbit.

En Rabbit, mi servicio tiene que llamar a UN producer (capa de infra) que envíe UN mensaje a un exchange, que lo convertirá en TRES mensajes, los enrutará por topic (o por fanout) a TRES colas para ser consumidos por TRES consumers. Porque no puedes hacer que un único evento sea leído por múltiples consumers, para N consumers tienes que enviar N mensajes por N colas.

De momento, ya tienes el triple de colas en Rabbit que en Kafka, y sólo va a ir a peor. Si quieres añadir más acciones (D, E, F, etc) en la versión Kafka sólo tienes que crear el nuevo consumer y que consuma del mismo topic, mientras que en Rabbit, para cada evento nuevo, necesitas un consumer, una cola y un topic. Si quieres que el mismo evento lo consuma más de un consumer tienes que empezar con mierdas como consume.add.to.cart.and.do.x, consume.add.to.cart.and.do.y, etc.

En cuanto la aplicación te crezca un poco, te lo prometo porque me costó el empleo, es INMANEJABLE la cantidad de colas y topics que tienes que gestionar para hacer lo mismo que hace Kafka con incluso sólo un topic, lo que significa que tu app está mal diseñada y te toca tirarla a la puta basura.

Sólo porque has cambiado el sistema de comunicación.

#51167 que la gestión de colas de rabbit sea más follonera que los topics de Kafka no hace que una abstracción no funcione, hace que la gestión de Infra sea un infierno, son cosas diferentes.
El concepto de producer lo puedes mantener abstraído para un servicio a “me llega el mensaje y lo meto aquí y ya se publicará”
El concepto de consumer lo puedes mantener a “me conecto a X sitio y me llegan mensajes que convierto a DTOs que entienda”.

#51160desu:

#51158 pues hazlo todo async... hoy en dia absolutamente todo el codigo debe ser async en user space. te diria que el 100% del codigo esta capacitado para serlo que alguien me corrija. alguna excepcion y truquitos raros hay a nivel de kernel pero dudo que programes kernels a mano.

que tienes que hacer?

Resumiendo un poco estamos modernizando una app antigua que no escala bien y necesitamos que escale. La idea es hacerla async como todo lo nuevo que estamos haciendo con Java 21 y Rust.
Nos hemos encontrado problemas a nivel de librerías antiguas que tendríamos que modificar para que funcionasen de manera asíncrona (librerías que no son nuestras, las nuestras la mayoría hay versiones nuevas que se usan en servicios asíncronos).
Hay un poco de debate de si dejarlo como está y rehacer la app de manera modular y bien hecha para lo qu enecesitamos o modificar la antigua.

#51165 A nivel interno siempre vas a tener hilos chequeando el estado de otros hilos, el tema está (muy por encima) en que las operaciones asíncronas no bloquean los hilos cuando están WAITING y si necesitan esperar sueltan el hilo y ya seguirán cuando se termine lo que están esperando, así los hilos siempre están trabajando y no hay hilos parados.
A nivel de una web realmente lo veo sencillo, haces la petición al server y te mandan la info, esta info te la mandan según el servidor la vaya pillando de la cache, si en algún momento el hilo qu ese está en cargando de eso tiene que hacer una petición a base de dato para algo, ese hilo se ocupa en otra tarea hasta que el proceso obtenga la info para enviártela.
El punto de entrada que comentas es simplemebte un punto de entrada, la asincronía empieza ahí (o yo no te estoy entendiendo bien xD)

Todo esto muy por encima y sin darle muchas vueltas.

#51167 Tío me fascina leeros y no me entero de una valiente mierda xD
¿Todo este tipo de cosas las vais aprendiendo con el paso de los años en el trabajo o cuando utilizáis alguna herramienta profundizáis al máximo en ella y por eso aprendéis tanto? Que yo como buen FPero siento que no estoy ni cerca de saber cosas así.

#51174 haz tier top y bottom del hilo va

yo ya se que soy un power bottom porque genero energía desde abajo