Este vídeo es un pequeño repaso a todo lo que vemos en detalle en el curso sobre comunicación entre microservicios. Más información: 🚀 Curso comunicación entre microservicios: bit.ly/curso-microservicios 📕 Catálogo completo de cursos CodelyTV Pro: codely.tv/pro/cursos 💸 Descuento 111€ gratis: codely.tv/pro/celebramos-5k-subs
Hola muchas gracias por el curso, estuvo genial, lo tome hace un tiempo, hoy volví a ver este vídeo, quería preguntarles que libros sobre este tema me pueden recomendar?
COmo escuché un día "Que camión de información" super genial este tipo de vídeos, una lastima que sea tan por encima pero igual es super instructivo. Mil gracias y ganais un nuevo suscriptor :D
Muy buenos videos, soy Front end developer y actualmente convivo con backends que están haciendo microservicios, me sirve mucho porque asi entiendo todo el ecosistema completo. Gracias por los videos, esperamos mas de Front End también :D Saludos desde México...!!!!
A la gente que quiera aprender un poco más, les comparto un link a un doc Microsoft donde explican muy bien y además también incluyen explicación de los servicios requeridos (como RabbitMQ) por la nueva infraestructura. docs.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/microservice-application-design
Excelentes videos y explicaciones. Muchas gracias. Tengo una duda respecto al caso de que yo necesite saber que videos pertenecen a un determinado usuario, para evitar relaciones o llamadas HTTP entre servicios, lo que se haría es en cada registro de video agregar la información del dueño del mismo, ¿cierto? ¿Es decir, replicaria en cada base de datos la información que se necesita?
No replicarias datos ya que no hay necesidad de ello, consultarias los datos al servicio que corresponda. Para replicar datos se necesitarian otras razones, no por eficiencia
Me pregunto si la alternativa 2 no se solucionaría simplemente poniendo una base de datos distribuida en Comodity Hardware, se evitan sobrecargas en la BBDD, la complejidad en el desarrollo no se dispara, se puede escalar añadiendo mas nodos a la BBDD en caso de aumento de peticiones, y el coste no se dispara. También recordar que las BBDD's también se pueden caer y con una BBDD distribuida el servicio no deja de funcionar en ese caso ya que siempre hay otros nodos disponibles. Por poner un par de ejemplos... Cassandra o ArangoDB (del cual soy muy fan). En todo caso la explicación del caso es muy interesante.
Pero esto sería "hacer trampa", claro que puedes multiplicar el número de esclavos de Mysql o usar Cassandra (buena suerte configurando una política de source of truth o manteniendo integridad referencial), igual que puedes multiplicar el número de monolitos (con máquinas o contenedores), pero la ingeniería busca resolver problemas de forma eficiente con el mínimo de recursos, no poniendo más dinero
Una consulta y que pasaría si todo esto está montado con contenedores dentro de un cluster de kubernetes. Y tenemos 3 réplicas definidas para el microservicio de usuario, al momento de publicar el evento de video creado mis 3 réplicas estarían suscritas a ese evento y por ende leerían el evento y podrían actualizar 3 veces el campo total de videos creados. ¿Cómo se gestionaría esto?. Pensé en mandar el campo ya actualizado al evento; sin embargo de todas maneras esto se estaría actualizando de acuerdo a la cantidad de réplicas que tenga el microservicio.
¡Buenas Edgar! Respondiendo a tu pregunta: La gestión de consumir 1 única vez el evento vendría dada por el sistema de publicación y suscripción de eventos que usemos (RabbitMQ, Kafka, AWS SNS->SQS, etc.). Es decir, una vez 1 consumidor que está suscrito a los eventos de esa cola recoge el evento, el propio sistema marca ese evento/mensaje como "transmitido" a la espera de un ACK del consumidor o un timeout para volverlo a hacer visible a otro consumidor. Esto evitaría en un primer momento que otra instancia de nuestros consumidores leyera el mismo evento. Dicho esto, hay sistemas como SQS que no garantizan el orden de los eventos/mensajes de la cola al consumir, ni tampoco que no puedas llegar a consumir un evento por duplicado. Ahí entramos en temas de hacer nuestros consumidores tolerantes a este tipo de casos a través de idempotencia o similares. Todo esto lo explicamos mucho más en detalle y con ejemplos concretos a nivel conceptual y de código en el curso: pro.codely.tv/library/comunicacion-entre-microservicios-event-driven-architecture/about/ Si te interesan estos temas… ¡te esperamos! 🙂
Que buen vídeo, gracias!! Tengo una pregunta... Si se quisiera agregar un servicio de usuario más...por cualquier motivo. Los dos servicios empezarían a duplicar info en la db?. Los dos servicios recibirian la misma cantidad de mensajes?
Tengo una consulta, al hacer que el procesamiento de la cantidad de videos lo haga el servicio del usuario, no estoy agregando columnas innecesarias? es decir, con este enfoque estaria creando una columna por cada calculo a realizar sobre otro servicio.
Perdonar tengo unas dudas ... si no necesitamos tablas ni BBDD relacionales ... ¿donde se guarda la información de los usuarios? ... si tenemos por ejemplo 30 entidades de domino ¿necesitaremos 30 instancias de la BD? ... que sea (MongoDB, MySQL, etc) ... un saludo un gran video!!
genial la presentación 👍👏 sólo una aclaración de la parte de los subscribers. en el caso de que aumenten x1000 la creación de vídeos, tb habrá x1000 invocaciones al callback del user service... y eso ¿no perjudica porque va directo por el id del usuario? pero aún así hay x1000 peticiones PUT complas qué procesar... no? un abrazo!!!!
¡Buenas! En el caso de un x1000 de creación de vídeos, si el consumidor de eventos del servicio de usuarios no puede procesarlos, simplemente la cola actuará como buffer. Es decir, como comentamos en el minuto 24:10, los eventos quedarían retenidos en la cola hasta que el servicio de usuarios poco a poco fuera capaz de procesarlos y ponerse al día. Aquí es cuando se produce lo que se conoce como "consistencia eventual". Es decir, el servicio de usuarios devolverá un total de vídeos creados que no será el real durante un espacio de tiempo. Le pongo las comillas a "consistencia eventual" porque realmente sería una mala traducción del término en inglés _Eventual consistency_. En inglés, _Eventual_ significa que algo tarde o temprano tendrá lugar. En cambio, que algo sea eventual en castellano quiere decir que está sujeto a circunstancias y que por lo tanto no es seguro que pase o que sea constante en el tiempo. A pesar de esto, se suele traducir como consistencia eventual y de tanto usarlo a nivel técnico ya nos entendemos 😅 Un saludo y gracias por la pregunta. Es algo que no tratamos a fondo en el vídeo y seguro que le sirve a alguien más 🙂
Buenas! Tengo una duda, puede la arquitectura por eventos en algún caso hacer posible que sea conveniente duplicar información? Por ejemplo, guardar el nombre del video en ambas base de datos, imaginando que tenemos dos pantallas que usan ese dato
La arquitectura orientada a eventos tiene dos cualidades (entre otras): la resiliencia (que se explica en el video) y el desacoplamiento entre el que llama y es llamado (consumidores y productores). No implica que debas duplicar tus datos.
@@asier6734 Gracias por responder. Me cuesta mucho imaginarme escenarios que conozco donde un microservicio necesita el dato de otro para su respuesta con EDD . por ejemplo, front web y front mobile utilizan el mismo dato, cada uno de los front tiene su propio servicio al que llaman para pedirselo. En mi experiencia estos servicios suelen comunicarse con el mismo servicio "core" que tiene el dato , cada vez que lo necesitan en EDD esto no seria posible, entonces, cada servicio deberia almacenar el dato que necesitan para cuando los front los consulte, pero de esta forma triplicarias la información. Es un patrón comun en EDD o es un mal caso de uso para el patron y en este caso seguiriamos usando los tipicos microservicios y consultas http? Saludos!
@@federicomarilungo los datos asociasos a un microservicio no tienen relacion con que sea de eventos o sincrono. Sino con como se hayan definido los microservicios y lo que cada uno sirva y datos que gestione en su bbdd. A microservicios mas pequeños mayor escalabilidad. Es comun que unos microservicios hagan uso de datos de otros microservicios. EDD solo modifica como se comunica e impone algunas condiciones (para gestionar un evento repetido etc) pero no supone un cambio en que datos gestiona cada microservicio
@@asier6734 Bueno creo que no supe explicar donde aparece el duplicado de datos. Microservicio A hace uso de Microservicio B para pedir dato 1 Escenario 1) Usamos arquitectura de comunicacion http El microservicio A llama cada vez que necesita el dato a microservicio B Escenario 2) Usamos arquitectura EDD El microservicio A se entera cuando el dato cambia (cuando el microservicio B lanza un evento) y tiene que almacenarlo para cuando el front se lo pida. En este ejemplo se puede ver como en el escenario 2, con EDD, necesitas duplicar la información. No hay forma de comunicar los servicios por EDD sin duplicar la información para este caso de uso. O si? Esa es mi pregunta Gracias.
@@federicomarilungo ok, entiendo. Tal y como lo veo almacenaria el dato pero no es necesariamente un duplicado. B puede no guardar el total ya que puede no necesitarlo (o si). Lo que hace es lanzar el evento para que lo procese A, recalculando el total y almacenandolo). No tiene por que haber duplicados, aunque puede haberlos en EDD. Esto tb tiene relacion con event sourcing, una tecnica donde se registran todos los eventos para el calculo de datos (donde lo que se registra son los eventos en si mismos y no los datos)
Solo tengo un pequeña duda, el servicio de creación de videos es un PUT y no un POST, porque esta vez los clientes de la aplicación son los que generan ese identificador único para el video y en el caso de los usuarios también debo usar un PUT? como genero un identificador único para el caso de video?, un algoritmo amarrado al id del usuario?
Lo que planteas es correcto. Para la generación del identificador lo haríamos de forma aleatoria usando UUIDs. UUID es un formato de identificador único aleatorio bastante estándar. Encontraras librerías para generar UUIDs en los principales lenguajes de programación sin problema. Te recomendamos el vídeo de preguntas frecuentes de CQRS donde justamente comentamos el tema de la generación de IDs desde el cliente: th-cam.com/video/auEhX4WfCRA/w-d-xo.html Saludos!
Está muy buena el contenido, pero me gustaría que hablaran muchísimo más claro porque a Javi se le entiende lo que habla y habla con fuerza y claridad peor al otro chico no se le entiende casi nada hablas muy, pero muy nasal y sin fuerza y es superimportante que hables muy bien me quede asta el final porque Javi me engancho Gracias Javi sos un Genio
No me parece razonable, ese ejemplo del contador de videos. Si por ejemplo abro youtube y quiero ver cuántos videos ha publicado un determinado usuario, estan asegurando que no se necesitara hacer un conteo de los videos. Alguien me puede decir entonces cómo se logra esta cuenta de manera más eficiente?
@@xabierm1609 no, soy ignorante en ese tema. Pero creo que hay un "bus" a donde van las notificaciones y así en teoria seria mas eficiente llevar la cuenta de algo. Pero me parece que eso implicaría más recursos porque un servidor debe recibir el dato y notificar, y la aplicación recibir y actualizar el contador en el cliente, lo cual es más complicado que lo tradicional donde solo se obtiene el conteo en el momento que se necesita conjuntamente con otros datos que puedan ser utiles.
![[Live สด] การออกรางวัลสลากกินแบ่งรัฐบาล งวดวันที่ 16 ธันวาคม 2567](http://i.ytimg.com/vi/dNTiBBthKgQ/mqdefault.jpg)
Este vídeo es un pequeño repaso a todo lo que vemos en detalle en el curso sobre comunicación entre microservicios. Más información:
🚀 Curso comunicación entre microservicios: bit.ly/curso-microservicios
📕 Catálogo completo de cursos CodelyTV Pro: codely.tv/pro/cursos
💸 Descuento 111€ gratis: codely.tv/pro/celebramos-5k-subs
Hola muchas gracias por el curso, estuvo genial, lo tome hace un tiempo, hoy volví a ver este vídeo, quería preguntarles que libros sobre este tema me pueden recomendar?
Que buen video, justo la explicacion que buscaba ❤
He enganchado con su contenido, me viene muy bien saber de arquitectura, soy desarrolladora frontend :) nueva suscriptora ✌🏻🇨🇱
colle me ajudaron mucho a entender algunos detalles y entender mejor como tomar decisiones de arquitetura mas sabiamente, muchas gracias
trabaje en un banco y usabamos circuit breaker y era un desmadre, demasiadas capas, saludos
De los mejores canales en mi criterio 🙌🏻
Muy buena explicación y los diagramas ayudan a entender mejor todo 🫡
Muy grande la explicación cracks. Pareciera que se iba a besar cuando se miraban a los ojos JAJAJAJA. Las mejores energias. Saludos desde Colombia.
Muy buena introducción y la explicación, es genial ver como explican estas cosas poniendole una buena cuota de humor.
excelente video, creo que es la mejor explicación de architecturas de software que he visto hasta ahora.
Esto de los microservicios es una pasada y sobre todo es sencillo si lo planteas en un folio :)
Tienen temas avanzados y vigentes.. excelentes creadores de contenido !
COmo escuché un día "Que camión de información" super genial este tipo de vídeos, una lastima que sea tan por encima pero igual es super instructivo. Mil gracias y ganais un nuevo suscriptor :D
Jajaja que divertido y educador video.
Super like.
Que genial , clara explicación . Saludos desde Perú.
Hablan de temas que me interesan muchisimo y, a demás, me entretiene su forma de contar las cosas. Parece una charla educativa entre amigos
las animaciones son tan buenas q me distraían de la explicación, jaja. Muy bueno!
Muy buenos videos, soy Front end developer y actualmente convivo con backends que están haciendo microservicios, me sirve mucho porque asi entiendo todo el ecosistema completo. Gracias por los videos, esperamos mas de Front End también :D Saludos desde México...!!!!
Esa es la actitud! 🙌🙌🙌
Gracias por tu comentario!
Uno de los mejores videos de codely. Me imagino el curso!
Muchas gracias este video me ha dado mucha visibilidad sois geniales
Me encanto el video !!!, ideas claras y me han iluminado el camino para entrarle a los microservicios
Muchísimas gracias! Son muy buenos profesionales, excelente explicación.
Justo lo q buscaba
Muy informativo y se ve que la están pasando bien.
Muy buena explicación, muchas gracias....
Excelente video.. haré los cursos
Hola! tienen alguna guia de las arquitecturas y como combinarlas? quiero usar arquitectura hexagonal y EDA pero no sé si seria conveniente
A la gente que quiera aprender un poco más, les comparto un link a un doc Microsoft donde explican muy bien y además también incluyen explicación de los servicios requeridos (como RabbitMQ) por la nueva infraestructura. docs.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/microservice-application-design
Excelente, genial explicado, like + subscriptor nuevo.
Excelente análisis y explicación!!
Buenisima la explicacion, clara y sencilla.
Muy buena energia!
Muy buena explicación y ademas entretenida :)
Muy buen video. gracias por tanto conocimiento.
Esto es genial! Gracias!
Cracks!
Tambien esta la carga de balanceo en los microservicios?
Muy bueno y entretenido muchachos!
¿Hola, una pregunta, como se llama el programa que usan en el minuto 24:53 para simular las comunicaciones de la infraestructura?
Buenas Johan!
Es tryrabbitmq.com 😊
Excelentes videos y explicaciones. Muchas gracias. Tengo una duda respecto al caso de que yo necesite saber que videos pertenecen a un determinado usuario, para evitar relaciones o llamadas HTTP entre servicios, lo que se haría es en cada registro de video agregar la información del dueño del mismo, ¿cierto?
¿Es decir, replicaria en cada base de datos la información que se necesita?
No replicarias datos ya que no hay necesidad de ello, consultarias los datos al servicio que corresponda. Para replicar datos se necesitarian otras razones, no por eficiencia
tienen cursos en udemy?
Me pregunto si la alternativa 2 no se solucionaría simplemente poniendo una base de datos distribuida en Comodity Hardware, se evitan sobrecargas en la BBDD, la complejidad en el desarrollo no se dispara, se puede escalar añadiendo mas nodos a la BBDD en caso de aumento de peticiones, y el coste no se dispara. También recordar que las BBDD's también se pueden caer y con una BBDD distribuida el servicio no deja de funcionar en ese caso ya que siempre hay otros nodos disponibles. Por poner un par de ejemplos... Cassandra o ArangoDB (del cual soy muy fan).
En todo caso la explicación del caso es muy interesante.
Pero esto sería "hacer trampa", claro que puedes multiplicar el número de esclavos de Mysql o usar Cassandra (buena suerte configurando una política de source of truth o manteniendo integridad referencial), igual que puedes multiplicar el número de monolitos (con máquinas o contenedores), pero la ingeniería busca resolver problemas de forma eficiente con el mínimo de recursos, no poniendo más dinero
Una consulta y que pasaría si todo esto está montado con contenedores dentro de un cluster de kubernetes. Y tenemos 3 réplicas definidas para el microservicio de usuario, al momento de publicar el evento de video creado mis 3 réplicas estarían suscritas a ese evento y por ende leerían el evento y podrían actualizar 3 veces el campo total de videos creados. ¿Cómo se gestionaría esto?. Pensé en mandar el campo ya actualizado al evento; sin embargo de todas maneras esto se estaría actualizando de acuerdo a la cantidad de réplicas que tenga el microservicio.
¡Buenas Edgar!
Respondiendo a tu pregunta: La gestión de consumir 1 única vez el evento vendría dada por el sistema de publicación y suscripción de eventos que usemos (RabbitMQ, Kafka, AWS SNS->SQS, etc.). Es decir, una vez 1 consumidor que está suscrito a los eventos de esa cola recoge el evento, el propio sistema marca ese evento/mensaje como "transmitido" a la espera de un ACK del consumidor o un timeout para volverlo a hacer visible a otro consumidor. Esto evitaría en un primer momento que otra instancia de nuestros consumidores leyera el mismo evento.
Dicho esto, hay sistemas como SQS que no garantizan el orden de los eventos/mensajes de la cola al consumir, ni tampoco que no puedas llegar a consumir un evento por duplicado. Ahí entramos en temas de hacer nuestros consumidores tolerantes a este tipo de casos a través de idempotencia o similares.
Todo esto lo explicamos mucho más en detalle y con ejemplos concretos a nivel conceptual y de código en el curso: pro.codely.tv/library/comunicacion-entre-microservicios-event-driven-architecture/about/
Si te interesan estos temas… ¡te esperamos! 🙂
@@CodelyTV Excelente, gracias por el detalle de la respuesta. De todas maneras llevaré el curso.
Que buen vídeo, gracias!! Tengo una pregunta... Si se quisiera agregar un servicio de usuario más...por cualquier motivo. Los dos servicios empezarían a duplicar info en la db?. Los dos servicios recibirian la misma cantidad de mensajes?
Tengo una consulta, al hacer que el procesamiento de la cantidad de videos lo haga el servicio del usuario, no estoy agregando columnas innecesarias? es decir, con este enfoque estaria creando una columna por cada calculo a realizar sobre otro servicio.
Asi es, añadirias a los datos del microservicio los derivados de procesar los eventos
Perdonar tengo unas dudas ... si no necesitamos tablas ni BBDD relacionales ... ¿donde se guarda la información de los usuarios? ... si tenemos por ejemplo 30 entidades de domino ¿necesitaremos 30 instancias de la BD? ... que sea (MongoDB, MySQL, etc) ... un saludo un gran video!!
genial la presentación 👍👏
sólo una aclaración de la parte de los subscribers. en el caso de que aumenten x1000 la creación de vídeos, tb habrá x1000 invocaciones al callback del user service... y eso ¿no perjudica porque va directo por el id del usuario? pero aún así hay x1000 peticiones PUT complas qué procesar... no? un abrazo!!!!
¡Buenas!
En el caso de un x1000 de creación de vídeos, si el consumidor de eventos del servicio de usuarios no puede procesarlos, simplemente la cola actuará como buffer. Es decir, como comentamos en el minuto 24:10, los eventos quedarían retenidos en la cola hasta que el servicio de usuarios poco a poco fuera capaz de procesarlos y ponerse al día.
Aquí es cuando se produce lo que se conoce como "consistencia eventual". Es decir, el servicio de usuarios devolverá un total de vídeos creados que no será el real durante un espacio de tiempo.
Le pongo las comillas a "consistencia eventual" porque realmente sería una mala traducción del término en inglés _Eventual consistency_. En inglés, _Eventual_ significa que algo tarde o temprano tendrá lugar. En cambio, que algo sea eventual en castellano quiere decir que está sujeto a circunstancias y que por lo tanto no es seguro que pase o que sea constante en el tiempo. A pesar de esto, se suele traducir como consistencia eventual y de tanto usarlo a nivel técnico ya nos entendemos 😅
Un saludo y gracias por la pregunta. Es algo que no tratamos a fondo en el vídeo y seguro que le sirve a alguien más 🙂
Super interesante !!
Buenas! Tengo una duda, puede la arquitectura por eventos en algún caso hacer posible que sea conveniente duplicar información? Por ejemplo, guardar el nombre del video en ambas base de datos, imaginando que tenemos dos pantallas que usan ese dato
La arquitectura orientada a eventos tiene dos cualidades (entre otras): la resiliencia (que se explica en el video) y el desacoplamiento entre el que llama y es llamado (consumidores y productores). No implica que debas duplicar tus datos.
@@asier6734 Gracias por responder.
Me cuesta mucho imaginarme escenarios que conozco donde un microservicio necesita el dato de otro para su respuesta con EDD .
por ejemplo, front web y front mobile utilizan el mismo dato, cada uno de los front tiene su propio servicio al que llaman para pedirselo.
En mi experiencia estos servicios suelen comunicarse con el mismo servicio "core" que tiene el dato , cada vez que lo necesitan
en EDD esto no seria posible, entonces, cada servicio deberia almacenar el dato que necesitan para cuando los front los consulte, pero de esta forma triplicarias la información.
Es un patrón comun en EDD o es un mal caso de uso para el patron y en este caso seguiriamos usando los tipicos microservicios y consultas http? Saludos!
@@federicomarilungo los datos asociasos a un microservicio no tienen relacion con que sea de eventos o sincrono. Sino con como se hayan definido los microservicios y lo que cada uno sirva y datos que gestione en su bbdd. A microservicios mas pequeños mayor escalabilidad.
Es comun que unos microservicios hagan uso de datos de otros microservicios. EDD solo modifica como se comunica e impone algunas condiciones (para gestionar un evento repetido etc) pero no supone un cambio en que datos gestiona cada microservicio
@@asier6734 Bueno creo que no supe explicar donde aparece el duplicado de datos.
Microservicio A hace uso de Microservicio B para pedir dato 1
Escenario 1) Usamos arquitectura de comunicacion http
El microservicio A llama cada vez que necesita el dato a microservicio B
Escenario 2) Usamos arquitectura EDD
El microservicio A se entera cuando el dato cambia (cuando el microservicio B lanza un evento) y tiene que almacenarlo para cuando el front se lo pida.
En este ejemplo se puede ver como en el escenario 2, con EDD, necesitas duplicar la información. No hay forma de comunicar los servicios por EDD sin duplicar la información para este caso de uso. O si? Esa es mi pregunta
Gracias.
@@federicomarilungo ok, entiendo. Tal y como lo veo almacenaria el dato pero no es necesariamente un duplicado. B puede no guardar el total ya que puede no necesitarlo (o si). Lo que hace es lanzar el evento para que lo procese A, recalculando el total y almacenandolo). No tiene por que haber duplicados, aunque puede haberlos en EDD. Esto tb tiene relacion con event sourcing, una tecnica donde se registran todos los eventos para el calculo de datos (donde lo que se registra son los eventos en si mismos y no los datos)
¡Buenisimo!
Solo tengo un pequeña duda, el servicio de creación de videos es un PUT y no un POST, porque esta vez los clientes de la aplicación son los que generan ese identificador único para el video y en el caso de los usuarios también debo usar un PUT? como genero un identificador único para el caso de video?, un algoritmo amarrado al id del usuario?
Lo que planteas es correcto. Para la generación del identificador lo haríamos de forma aleatoria usando UUIDs.
UUID es un formato de identificador único aleatorio bastante estándar. Encontraras librerías para generar UUIDs en los principales lenguajes de programación sin problema.
Te recomendamos el vídeo de preguntas frecuentes de CQRS donde justamente comentamos el tema de la generación de IDs desde el cliente: th-cam.com/video/auEhX4WfCRA/w-d-xo.html
Saludos!
Con esto me ha quedado clara la diferencia entre PUT y POST. Gracias!
20:24
Se agradecen los chascarrillos y las explicaciones previas, pero lo bueno está en ese punto.
Cómo hago para dar más de un like?
que mas muchachos como va todo, hey tenes el cupon para inscribirse al pro? estoy usando este CODELYCQDXP y nada tio, la ostia con esa interfaz
Acá estaban mas didácticos, menosacelerados, traten de hacer todos asi. pd: Gran canal.
Gracias por el contenido, me da una duda, son pareja? digo, por la forma en la que se miran, se ve raro, perdón si esto les ofende.
Nos queremos.
@@CodelyTV pues tambien la comunidad los queremos por tan buen material de ayuda, saludos!
Está muy buena el contenido, pero me gustaría que hablaran muchísimo más claro porque a Javi se le entiende lo que habla y habla con fuerza y claridad peor al otro chico no se le entiende casi nada hablas muy, pero muy nasal y sin fuerza y es superimportante que hables muy bien me quede asta el final porque Javi me engancho Gracias Javi sos un Genio
No me parece razonable, ese ejemplo del contador de videos. Si por ejemplo abro youtube y quiero ver cuántos videos ha publicado un determinado usuario, estan asegurando que no se necesitara hacer un conteo de los videos. Alguien me puede decir entonces cómo se logra esta cuenta de manera más eficiente?
Yo tambien tengo esa duda, lo lograste solucionar?
@@xabierm1609 no, soy ignorante en ese tema. Pero creo que hay un "bus" a donde van las notificaciones y así en teoria seria mas eficiente llevar la cuenta de algo. Pero me parece que eso implicaría más recursos porque un servidor debe recibir el dato y notificar, y la aplicación recibir y actualizar el contador en el cliente, lo cual es más complicado que lo tradicional donde solo se obtiene el conteo en el momento que se necesita conjuntamente con otros datos que puedan ser utiles.
Enormes gracias a mi pareja lgtb favorita
Una charla muy interesante, me.ayudo a complementar lo que sabía th-cam.com/video/N95W6I_DoRs/w-d-xo.html
Saludos y seguiré viendo el bueno contenido.
En caso de que requieran la herramienta. del video: tryrabbitmq.com/