Y hoy continuamos, porque es que vamos de nivel a nivel.
Y ahora tenemos a la gente de Codely.
La gente de Codely nos va a explicar cómo van a hacer programación reactiva de 0 a 100.
Si no conocéis a Codely, madre mía, no sé a qué estáis esperando,
porque estamos hablando seguramente de la mejor plataforma para que subas de nivel en programación.
¿Por qué? Pues porque no hacen los cursos típicos.
Lo que están haciendo son cursos realmente que marcan la diferencia.
De testing, de arquitectura, de cómo hacer plataformas mantenibles, escalables, arquitecturas agonales,
que tenéis un montón, temas de buenas prácticas.
Y todo esto basado en el mundo real.
Así que no os podéis perder esta charla de Codely.
Y sobre todo después, cuando terminemos, que vayáis directamente a la página web.
Así que le voy a dar la bienvenida a nuestros amigos Rafa y Javi.
Y los tenemos por aquí.
Hola amigos, ¿cómo estáis?
Buenas.
¿Cómo estamos?
Disfrutando de esta Midoconf. Espectáculo el sarao que han montado, señor. Felicidades.
Muchas gracias. Sí, la verdad es que todavía no me lo creo mucho.
Yo estoy aquí como en un sueño que ya Guillermo me diga, me acuerdo de ti y de la charla que tuvimos.
Ya me he puesto hasta nervioso. Digo, por favor, ya. Llorando casi, llorando.
Bueno amigos, pues os dejo aquí todo esto para que dais vuestra charla.
Javi, creo que se te ha escuchado muy fuerte. Un poquito fuerte.
Se me escucha.
Ahora mejor. Ahora te lo han arreglado.
Creo que te lo han arreglado.
Perfecto, muchas gracias.
Perfecto. Pues os dejo a vosotros todos, ¿vale?
Dadle cañita a programación reactiva de 0 a 100.
Y ojo, cuidado, que no solo son Rafa y Javi que me han dicho que es más gente.
Así que, atentos, atentos.
Por cierto, Midu, por favor, si puedes pinchar el audio también de Carmen y de Dani,
que iremos intercalándonos y también intervendrán en el streamyard.
Pues así cuando entren ya tienen el audio pinchado y ya pueden hablar.
Se agradece enormemente toda la producción que estáis haciendo el curro. Espectacular.
Y si queréis, le damos.
Vale, pues perfecto.
Id dándole y ahora activo el audio y hablo con Dani Carmen en Hecha Privado.
Perfectísimo.
Pues bienvenidos y bienvenidas.
Vamos a hacer un repaso súper rápido en 15 minutos a reactividad en web de principio a fin.
Es decir, vamos a ir desde la concepción de una página web en Figma a nivel de diseño,
a nivel de UX y vamos a llegar hasta arquitectura de servicios más micro, menos micro.
Eso ya lo hablaremos luego, pero el que es la cuestión es tan que empezamos por el principio.
Así que...
Vamos a ir de eventos, de eventos en forma esa, eventos en dominio.
Vámonos primero con Carmen que nos va a explicar qué está haciendo a nivel de Figma.
Carmen, por favor, todo tuyo.
Muy buenas.
Pues como siempre por aquí atareada con mi herramienta favorita, que os tengo que confesar
que no fui yo quien tomó la decisión de utilizar Figma en Codely.
La razón principal de utilizar Figma en Codely es que todo el equipo puede trabajar en un mismo archivo,
facilitar el trabajo en Pairing y tomar decisiones en conjunto.
Esta es la community de Figma donde podéis encontrar un montón de materiales como un GitHub para diseñadores,
para que os hagáis una idea, donde nos podéis encontrar también, que estamos subiendo bastante contenido.
Aquí nos tenéis, esta es nuestra página.
Y os voy a enseñar Structure.
Este Structure es un plugin que hemos recién subido porque además de encontrar un montón de templates de diseño en Structure,
puedes crear una estructura de páginas que hemos definido para poder tener cohesión en nuestros archivos de diseño y en los proyectos.
Así cuando cualquier persona entra, pues sabe dónde encontrar todas las cosas que necesita.
Es una funcionalidad muy guay tener plugins desde poder utilizarlos desde el community a desarrollarlos,
como es el caso del curso que hemos publicado recién de desarrollar tu plugin con TypeScript.
Y os voy a enseñar cómo funciona Structure.
Aquí lo tenemos, le damos a Run y lo que nos genera es una estructura de páginas que nos sirve para saber dónde están los diseños y dónde está cada cosita.
Nos hace la vida más fácil a todo el equipo.
¿Qué más cositas?
Nuestro Design System.
Ahora veíais que mi DUDEP nos estaba enseñando la landing.
Vale, Figma nos ha ayudado en trabajar de una forma nueva.
Ha hecho que mejoren mucho los flujos de trabajo, sobre todo todas las iteraciones de diseño.
Gracias a este Design System que tenéis aquí, que en una primera instancia hizo soluble,
nos ha ayudado a iterar componentes, todos estos componentes de aquí,
para crear, como es el caso que os vamos a enseñar, la landing, que es el caso de uso de suscripción.
¿De acuerdo? La tenemos por aquí.
Aquí podéis verlo, de suscríbete.
Y hemos decidido poner este CTA de suscríbete en el flujo de experiencia de usuario,
antes de clicar en este de aquí, que es el de comprar cuentas, que es el trigger,
que este botoncito de aquí, que parece que hace poco, que tenemos aquí cuando llegamos a la landing y damos a suscríbete,
este botoncito que parece que hace poco, es el que triguea todo lo que ahora nos van a explicar.
Y ahora es nuestro maestro de ceremonias y el encargado de generar la reactividad que Javi y Rafa nos van a explicar ahora.
Perfecto. Pues vamos al turrón, señor Rafa, llevando la reactividad al backend.
Hemos visto este botón ahora de comprar cuentas que nos enseñaba Carmen.
Este botón incluye una cosa que es la línea más importante del frontend,
hay una línea del frontend que es la que nos desploría con esta reactividad.
¿Cuál creéis que es? Por el chat. Comentad cuál creéis que para vosotros es la línea de más importancia del frontend.
En este caso tenemos todo el formulario, en que llegamos con componentes con React, como prefiramos.
Tiramos mucho todos nosotros también en SGS, así que todo lo que está pasando hoy aquí.
Entonces, significamos la línea que nos habilita esta reactividad, en este caso es este on-summit.
Vale, perfecto. Entonces, este on-summit al final lo que va a triggerear es el hecho de que haya un event listener aquí.
Entonces, esto es algo que venimos haciendo tradicionalmente y que esperamos, Rafa, que te acerques un poquito al micro, comentan por ahí.
Y pasamos ahí de slide y ya vemos.
Que esto puede ser el formato clásico de on-summit o puede ser con una event listener o puede ser como queramos, como si es jQuery.
Cualquier cosa es la que acaba habilitando este event-driven, en este caso, en el frontend.
Perfecto. Entonces, hasta aquí tenemos claro un poco cuál es el kit de la cuestión cuando hablamos de reactividad en el frontend.
Esto es algo clásico que es como, bueno, pero si esto lo vemos cada día en el canal de Midudep, de decir, pues esto es súper básico.
Vamos a elevar la categoría de reactividad, vamos a llevárnoslo más que elevarlo, vamos a llevárnoslo al backend.
Y vamos a ver cómo podremos evolucionar una arquitectura a ese nivel.
Entonces, primero, etapa 1. Empezamos nuestro servicio, lo que queremos es validar negocio, lo que queremos es ir rápido con aplicaciones CRUD, Active Record y Amolar.
Entonces, metemos ahí un Laravel de turno o lo que sea que nos permita ir rápido, monolito, única base de datos tradicional, MySQL, que es con lo que tenemos experiencia.
Una hay fallo, fase 1, tiramos millas.
La cosa va evolucionando y queremos desbloquear escalabilidades a nivel de aplicación.
Tener múltiples equipos. Oye, pues queremos que lo de Codel y tira, por cierto, Twitch.tv barra Codel ITV, Noticias de la Semana, Mundo Tecnológico y YouTube.com barra Codel ITV.
También vídeos de todo este tipo de cosas que vamos a ver ahora.
Entonces, lo que hacemos es, ese monolito lo dividimos en dos equipos.
Que si MOOC, Massive Online Open Curses, la plataforma de cursos y que si el Companies Backoffice.
Es decir, la sección para empresas para que gestionen sus licencias de la plataforma de cursos y demás.
Ahí hemos ganado cosas porque hemos ganado autonomía de esos dos equipos.
Pueden desarrollar features, pueden optimizar el ecosistema en el que desarrollan para sus casos de uso.
Si hubiera procesamiento de vídeos, por ejemplo, pues oye, la aplicación en Python, que es lo que mejor rendimiento tiene para ahí.
Pero seguimos teniendo problemas porque atacan a la misma infraestructura.
Si hacemos una campaña de anuncios orientado a empresas y se empiezan a dar de alta,
eso va a saturar también la plataforma de los usuarios que intentan acceder para hacer cursos porque atacan las queries a la misma base de datos.
Entonces, pasamos fase 2.1, ese microlito lo acoplamos.
¿Y qué estamos haciendo aquí?
Pues si nos fijamos, lo que estamos haciendo es esos servicios que tenemos divididos los tenemos que comunicar.
¿Por qué?
Porque ahora hemos dividido también la infraestructura.
Cada servicio tiene su infraestructura aislada para justamente evitar esos cuellos de botella que decíamos antes
y evitar que cuando una aplicación reciba muchas peticiones y se sature su infraestructura,
redunde en efecto dominó y que también tumbe los otros casos de uso.
Pero, a pesar de esto, MOOC va a seguir necesitando datos de Companies Backoffice.
Por ejemplo, el registro que veíamos ahora de Carmen.
El registro que veíamos de Carmen, ahí van a suceder acciones de que se cree una empresa
y eso, en el Companies Backoffice, la empresa va a poder reasignar sus licencias o cosas así
que eso va a tener que redundar en la aplicación de MOOC para que en su base de datos tenga
que, oye, este usuario ya no puede acceder, ahora debe poder acceder a este otro.
Y, aparte, que le ponga el perfil, oye, que sepa que Javi trabaja en Codel.
Exacto.
Entonces, ¿eso cómo lo hacemos?
Oye, ¿en qué empresa trabaja esto?
Pues hacemos un GET.
Estamos acoplando esos servicios, con lo cual, realmente, a efectos prácticos,
sí que seguimos teniendo ese efecto dominó que teníamos antes derivado de la infraestructura,
pero ahora derivado de esa comunicación, de ese acoplamiento API HTTP, ese GET,
sí, está saturado.
El Companies Backoffice, MOOC, ese GET va a dar un 500.
Podríamos meter un circuit breaker como Hystrix o cosas así que están deprecated.
El problema lo seguiríamos teniendo.
¿Por qué?
Porque esto no es un problema de latencias.
Y lo importante del mensaje es eso.
Esto es un problema de gestión de equipos y de autonomía.
Ahora, Companies Backoffice, en la fase 2.1, va a tener que estar exponiendo cierta información
como ese endpoint de dame en qué empresa trabaja este usuario,
solo, única y exclusivamente por las necesidades de MOOC.
Entonces, ahí está el problema.
Llega una user story a MOOC, quiero que se vea la empresa,
esa user story redunda en otro Gira que le abren al equipo de Companies Backoffice o Companies.
Total, fase 3, Eda, cuéntame.
Llegamos a la magia donde de verdad nos desacoplamos lo que vienen a ser nuestras aplicaciones
con esta llamada asíncrona que estamos haciendo.
Ah, no, no, esto es asíncrono.
Y si por lo que sea se cae Companies Backoffice, pues MOOC sigue funcionando,
no hay efecto dominó y cuando se vuelva a levantar publicará más eventos
y ya los podrá consumir MOOC.
Esto lo hemos hecho eliminando esas comunicaciones sincronas por API HTTP
y pasando esa redundancia de información a través del evento de dominio este
que estamos viendo ahí en amarillito, Companies Credited.
¿A qué nos recuerda esto?
Pues si nos acordamos de Solid, al final uno de los principios de Solid
era el de inversión de dependencias, dependencia, inversión, príncipe, la D.
Entonces, aquí tenemos un diagramita que a muchos os sonará, ¿no?
Tenemos, por ejemplo, una clase que representa el caso de uso a nivel de la capa de aplicación.
Si hablamos en terminología de arquitectura hexagonal.
Hostia, es que se me escapan todas las palabras que están diciendo estos locos aquí súper rápido.
Cursos de arquitectura hexagonal en pro.co.dl.com.
El que de la cuestión está en que tenemos la clase esta de Video Creator
y en Solid, dependencia, inversión, principal, portion adapter, llámalo X.
Lo que hacemos es que para evitar ese acoplamiento directo a MySQL Video Repository
y ya no que dificulte el hecho de ¿qué pasa si mañana la base de datos está en Postgre o en Redis?
Porque el contraargumentario, si ese es el principal beneficio, es muy fácil.
Es ¿cuántas veces has cambiado la base de datos tú de tu sistema?
Y entonces ya te tumban el argumento.
No, aquí el principal beneficio es por testing.
Entonces, tenemos que establecer algún punto de corte que nos permita aislarnos en nuestros test unitarios
de las latencias derivadas de usar una infraestructura de verdad
y que los test unitarios puedan testear, validar todos esos corner cases
sin necesidad de levantar bases de datos.
Con lo cual, lo que hacemos es invertir esa dependencia con una interfaz Video Repository.
Una magia que te permite también hacer mocks muy fácilmente,
te permite actualizar versiones de librerías que utilicemos muy fácilmente
y sobre todo lo centralizas en un punto.
No tienes esto repartido en 80 sitios.
Total, que esto es lo que ya sabemos de Solid
y aquí el key de la cuestión está en pensar.
Ostras, lo que estamos haciendo en esta fase 3 de Event Driven Architecture,
de arquitectura dirigida por eventos, justamente es lo mismo.
Es decir, si nos fijamos en este diagrama
y lo trasladamos al diagrama de servicios que veíamos antes,
en vez de hablar de una clase y otra, estamos hablando de un servicio y otro
y tenemos el servicio de usuarios o de MOOC
y el servicio de vídeos o de Companies Backoffice.
Entonces, ese acoplamiento, ¿cómo lo podemos invertir?
Pues lo que hacemos es establecer un contrato,
igual que representa el contrato, la interfaz esa que veíamos de Video Repository,
pero en este caso el contrato es ese JSON,
que es simplemente ese evento de dominio de,
oye, el servicio de vídeos ha publicado,
el evento de, se ha creado un vídeo.
Esto puede ser en algo más sofisticado y complejo,
como un RabbitMQ, un Message Broker,
o un SNS y derivado de ahí un SQS que esté suscrito,
si usamos AWS,
o puede ser algo simplemente que lo escribo en una base de datos
y hay gente que está haciendo pooling.
O bien eso, en JavaScript, donde me de meter el Note y para adelante.
Entonces, el key de la cuestión está a nivel conceptual,
invertir esa dependencia para que la responsabilidad al final
de Video Service,
y aquí entra también otro de los principios de Solid,
que es Open Close Principle, abierto a extensión, cerrado a modificación.
Yo, si en general de todo mi sistema quiero aumentar las funcionalidades,
no tengo que modificar las partes ya existentes.
Si quiero mostrar esa ficha de perfil de usuario donde muestro a la empresa,
ya no me hace falta modificar el servicio de back office
para tener ese endpoint get,
porque lo único que necesito es que ese servicio de usuarios
esté escuchando los eventos de empresa registrada,
licencia resignada, etcétera.
Con lo cual, lo importante aquí no es lo técnico,
lo importante aquí es lo organizacional
y cómo fomentamos la autonomía de los equipos
para que no dependan unos de otros.
Y que esto sí que tiene una ventaja técnica después.
O sea, esto se deriva en que si por lo que sea,
ya hemos dicho, se publica el evento cada vez que se crea una compañía,
entonces la parte del MOOC que tiene que devolver
de a qué empresa pertenece esta persona,
pues puede escuchar este evento y traerlo.
Entonces, ¿qué pasa si ahora estamos nosotros en un directo de Midudev
con muchísima gente y, mira, os apuntáis a Codely?
Pues que hay un por mil en peticiones,
pero al tenerlo todo en un sistema por eventos,
no pasa nada porque ya no hay como el efecto dominó,
que si se cae company back office se cae todo,
o si se cae la base de datos de company back office se cae toda la base de datos,
¿no?
Al estar por separado, vivimos en un mundo mucho más relajados.
La base de datos de company back office sí que entraría en fuego por mil de peticiones,
pero lo que redundaría es que en la cola se encolarían esos eventos
y eventualmente, es decir, más tarde o más temprano,
la base de datos de MOOC se sincronizaría.
Con lo cual, ahí no hay ese efecto dominó,
ahí se corta, gafitas, todo guay.
Pero hay una gran pregunta, es, ¿vale?
Hasta ahora teníamos un caso de uso que estaba en un sistema monolítico
y que yo tenía ahí todas las acciones derivadas del hecho de que se registrase una compañía.
Ahora ya lo tengo distribuido en distintos sistemas.
Entonces, ¿qué pasa con el testing?
Señor Dani.
Dani, por favor.
¿Nos cuentas?
Vamos ahí, porque hemos metido muchas capas.
Hemos metido eventos de dominio, equipos autónomos, un event base.
Entonces, ¿cómo podemos testear todo esto?
Al final, lo que vendría a ser es que tenemos ese company back office
que comentábamos, ¿no?
Que va a lanzar ese evento.
Y tenemos otros sistemas, otros equipos que se están encargando de suscribirse a eso
para hacer reaccionar a eso, ¿no?
Sistema de notificación para enviar un email
o crear una compañía en otra parte del sistema, ¿no?
Entonces, ¿cómo testear todo esto a nivel de cuando ya hemos hecho equipos autónomos?
Lo importante es mantener esos equipos autónomos a la hora de testing.
Es decir, el equipo de companies back office en todos sus tests
no va a hacer ninguna referencia a mock,
no va a hacer ninguna referencia a notification
de asegurarse de que el email se ha enviado ni nada.
Simplemente lo que se va a asegurar es a nivel de test unitarios en el caso de uso
asegurarse de que ese evento, el company created, se envía al event base.
Por ejemplo, moqueando el event base en caso de test unitarios para que vayan rápido.
Y otra cosa que nos tenemos que asegurar es que a nivel de test de integración,
pues que cuando miramos este evento a nivel, al event base de infraestructura,
al rapidMQ, al Kafka o a lo que sea,
pues que eso realmente se acaba publicando, ¿no?
tendríamos esta vertiente, pero nunca hacemos referencias a los suscriptores.
Y desde el punto de vista de los suscriptores, tenemos la película, pero a la inversa.
Es decir, no vamos a testearlo pasando por el equipo de companies back office
haciendo ahí una petición.
No, no, no.
Nosotros nos centramos en el evento,
nos aseguramos de que cuando se envíe eso a un event base,
en nuestro caso de uso, en el caso de mock o en el caso de notificación,
en el equipo que estemos, se acaba ejecutando.
Así tendríamos separado como esa independencia,
no solo a nivel de equipos, sino también a nivel de enfocar el testing.
¿Cómo se llevaría cada uno de los test, no?
Si yo estoy en equipo de mock, o estoy en equipo de companies back office,
¿cómo desde Codely vemos un poco el testing, no?
Nosotros actualmente estamos utilizando NextyGest,
pues la petición, por ejemplo, esa petición que mostraba Carmen, ¿no?
De suscribirse a Codely, entraría por el app.tsx,
sea en Next o sea en otra cosa, ¿no?
Ahí entraría.
Esto no lo vamos a testear.
Ahora, seguro que la gente de Next lo tiene perfectamente testeado,
así que por ahí eso nos testeamos.
Pero esto llega a nuestro formulario.
Nuestro formulario con todos sus campitos que veíamos ahí,
es un componente, en este caso de React,
que tiene otros componentes, ¿no?
Que necesarios, por ejemplo, el sector de precios
o cada uno de los input fields.
Luego veremos un poco cómo esto lo percibimos a nivel de test unitarios,
pero quedarnos, ¿no?
Que el componente de subscribe form necesita de otros componentes también
para, digamos, poder suscribirse.
Y finalmente tenemos como una interfaz de, oye, quiero poder suscribir,
decir al backend de que se envían estos datos, ¿no?
Y finalmente, pues haremos un fetch o de la forma que queremos comunicarnos
con el backend para llamar a un controlador dentro del backend.
Tenemos esa separación ahí.
¿Qué ocurre en el backend?
Pues, bueno, arquitectura hexagonal.
Tenéis los cursos de Codely de arquitectura hexagonal.
Si queréis ver un poquito qué significa toda la parte esa de la diana de ahí arriba,
dominio, aplicación, infraestructura, del código de colores.
Pero básicamente un controlador va a llamar a un caso de uso,
company subscriber, que se va a encargar de transaccionalmente crear esa empresa
y asegurarse de, importante, que el evento ese que decíamos,
el company subscribe, por ejemplo, realmente se envía a Levenbass, ¿vale?
Es muy importante que en este caso de uso se encargue de eso.
Entonces, a nivel de test unitarios, tendremos que encargarnos en este punto
de testear que eso llegue a Levenbass.
Entonces, esto creará a nivel de objetos de dominio una empresa, una company
y también tendremos el concepto de repositorio de datos, ¿no?
De poder guardarlo a nivel de interfaz de dominio.
Y luego tendremos nuestras implementaciones.
Por ejemplo, nosotros estamos hablando Supabase, así que, bueno,
Supabase company repository o Postgre,
que es lo que se usa por debajo, company repository.
Este sería un poco el esquema general de frontend y backend.
Hay simplificaciones por ahí, pero, bueno, un poco a nivel general.
Entonces, ¿dónde enfocaríamos los tests?
Pues, a nivel de frontend unitario, nuestros tests unitarios irían aquí,
en el subscribe form.
No testearíamos las apps, directamente el formulario.
Y aquí un punto importante, lo testeamos con Testing Library
y lo que hacemos es renderizar todo el formulario
y entenderlo como un caso de uso.
Es decir, no renderizaríamos aparte de forma aislada
el Price Selector y testeamos unitariamente eso
o un Input Field, sino que entendemos que el caso de uso es completo, ¿no?
El poder rellenar ese formulario, tener todas las padecinas completas
y ahí estarían todos nuestros tests usando Testing Library en este caso.
Y a nivel de integración, pues, sí que podríamos añadir un test
que asegurarnos de que cuando llamemos al backend, con este caso con Fetch
o con la herramienta que usemos, realmente eso está funcionando guay,
levantando el sistema y demás.
Por otro lado, a nivel de backend, seguimos la misma filosofía.
Testeamos el caso de uso y seguimos con este test que es sobrendomear test sociales.
Es decir, no testean solamente una clase o una función,
sino que a nivel de caso de uso.
Quiero asegurarme de que cuando el usuario envía unos datos,
en este caso, una intención de suscribirse, realmente se suscribe,
realmente el evento de dominio se envía a mmbus y ocurre todo transaccionalmente
y todo guay.
Entonces, testeamos todo conjuntamente y finalmente tendríamos nuestro test
de integración para testear esa piecita de Postgres para asegurarnos
que realmente cuando vayamos a decirle, ¿no?
En los test unitarios habremos moqueado el company repository,
pues, para asegurarnos de que cuando realmente vayamos a guardar en Postgres,
por ejemplo, en este caso una company, eso funciona guay.
Entonces, para allá, para acabar, nos falta el test de aceptación,
el test de que valide que esto va todo guay, ¿no?
Entonces, ¿qué hacemos en Codelea, a nivel de Codelea?
Hacer un test de aceptación de todo.
Por ejemplo, con Cypress, levantar toda la aplicación y asegurarnos
de que desde el frontend hasta el backend todo funciona.
¿Por qué lo hacemos así?
Porque trabajamos como un equipo conjunto.
Es decir, todo frontend y backend trabajan conjuntamente en una feature.
Creemos en esta filosofía de equipos autónomos con una parte del producto
y, por lo tanto, testeamos todo.
Nuestros backend son backend para un frontend.
No tenemos un backend genérico donde vamos a tener múltiples frontends.
Ahí sí que podría quizá tener un sentido, un aceptantense de backend
porque crearías un contrato para múltiples frontend.
Pero nosotros nos quedamos a día de hoy con esta estrategia de testear todo
a nivel de aceptación.
Y os devuelvo a Javi y a Rafa, que ya llevamos aquí una buena tunda
de idas y venidas.
Javi y Rafa, ¿qué contáis?
Perfecto.
Muchas gracias, Dani.
Muchas gracias, Carmen.
El que da cuestión, todo esto, si queréis ver detalles de implementación,
primero, sin barrera de entrada, sin pagar nada,
lo tenéis en github.com barra codelea.v.
Tenéis todos los repositorios de todos los cursos y todo lo pensó
que publicamos día tras día.
Y estamos en redes sociales como Twitter, Instagram, YouTube, Twitch y demás.
Y si queréis ver cómo explicamos todo esto con detalle de implementación,
bajando al código y con casos reales de, vale,
pero toda esa infraestructura de Rapid&Q,
cómo se crea en tiempo de build de forma automática en base a leer
qué clases implementan la interface de EventSubscriber y demás
y automatizar todo ese proceso que se torna demasiado complejo.
Si no, pues lo tenéis implementado.
Todo esto basado gracias a las empresas en las que hemos estado,
donde hemos tenido estos retos de escalabilidad como Letgo,
Acamo, Lubinum, etcétera.
Y tenéis 5 euros gratis por la MiduConf y MiduDev.
Te dejamos ya.
Maldas arriba.
¡Chaca, pam!
¡Madre mía, impresionante!
O sea, increíble.
Amigos, oye, perdona que os he cortado, perdón.
Ya, ahora.
Muchas gracias.
Increíble.
Había mucha gente en el chat que decía,
oye, ¿qué pasa?
Que Javi le den un vaso de agua.
La velocidad que estaba teniendo Dani.
Carmen también lo ha explicado súper bien.
Mucha información en muy poco tiempo,
pero de verdad, una información de primerísimo nivel.
Lo que están diciendo la gente de Codeli,
que ahí tenéis codeli.com barra pro,
barra MiduDev,
que además tenéis un descuento.
Y vamos a hacer un sorteo.
Ya en el chat está diciendo,
oye, Midu,
tráete a esta gente otro día,
que lo expliquen más lentito,
y además con código.
Y yo les he dicho, a ver,
si esta gente es colega,
o sea, que ya lo traeremos, por supuesto.
Vamos a hacer un sorteo.
Vamos a sortear 5 suscripciones de un mes
para codeli.com, ¿vale?
Y tenéis que poner en el chat la palabra Codeli.
Así, poned en el chat la palabra Codeli,
bien escrita, ¿eh?
Codeli con Y, no con Y latina,
porque si no, no funciona.
Ese es el Codeli del bazar que tenéis abajo de casa.
Ese no funciona.
Estamos hablando de codeli.com barra pro,
que es el pro.
Oye, pero muy bien, ¿eh?
Muchas gracias por la pedazo de charla.
La velocidad que la habéis imprimido
ha sido espectacular.
Y pero yo, al menos,
he sido capaz de entenderla bastante bien, ¿eh?
Bastante bien.
O sea, es que...
De eso se trata.
Si no, si no lo habríamos hecho muy mal.
No, no, no.
Pero que a lo mejor hay...
Había gente que decía,
es que soy junior y no me entero.
Es que no sé qué.
Y es verdad.
A ver, claro, obviamente,
es difícil porque no te pueden explicar aquí de repente
qué es un servicio.
¿Sabes?
Se van a parar.
Bueno, un servicio es,
un caso de uso,
un event emitter.
Pero yo creo que es un contenido.
Obviamente, la plataforma,
justamente lo que decíamos,
es una de las mejores plataformas
para contenido ya muy de senior,
de arquitecturas,
muy enfocado,
una cosa en concreto,
pero que está súper bien.
Así que, pues nada,
ya tenemos aquí un montón de gente.
¡Wow!
Dos mil y pico personas participando.
Vamos a sortear estos cinco suscripciones de un mes.
Así que mucha suerte a todo el mundo.
El primero se va para Wong Jorge.
Wong Jorge.
Ese es el primero.
Vamos a darle otra vez.
¿Vale?
Wong Jorge, felicidades.
JS Code.
JS Code le ha tocado la segunda.
La tercera.
Vamos a por la tercera.
Gongali, 97.
La cuarta, L Fernand CS.
Y la quinta se la queda,
RBN Hunter.
Así que, felicidades a las cinco personitas
que le ha tocado.
Muchas felicidades.
Haremos más suscripciones,
más sorteos de suscripciones de Acodele
a lo largo del directo.
Así que, no se preocupen.
Tenemos cinco suscripciones más de un mes.
Tenemos algunas suscripciones de tres meses.
Y también hasta de un año.
Si no me equivoco, ¿no?
De un año, sí.
Tengo por ahí apuntada.
Tengo demasiados premios.
Bueno, pues fenomenal.
Oye, Javi, Rafa, Carmen, Dani.
Impresionante.
De nuevo, muchísimas gracias a los cuatro.
Habéis hecho una presentación increíble
en súper poco tiempo.
Tanta información.
Así que, enhorabuena.
Espero que podáis venir un día aquí a Twitch,
a Midudev.
Y lo explicamos con más calma
y con código por medio, si queréis.
Totalmente.
Cuenta con ello, señor.
Muchísimas gracias.
Un abrazo.
Muchísimas gracias, Cracks.
Hasta luego, Cracks.
Que va, muy bien.
Chao.
Pues era Codely.
Ya sabéis, Codely.
Programación reactiva de 0 a 100,
pero espectacular.
El ritmo, la información,
todo.
O sea, es increíble.
Es verdad, culpa mía.
Lo siento que solo teníamos 15 minutos
para que lo hicieran,
pero han intentado condensarlo
y lo han hecho impresionante.
Por suerte va a quedar grabado,
así que no os preocupéis.
Pero ahora...
Gracias.