Bienvenidos a todos y a todas a un nuevo episodio de What The Front, tu podcast de frontend en
castellano y de frontend va la cosa, pero de frontends pequeñitos, más que pequeñitos,
micro frontends. ¿Pero qué son? ¿Es la arquitectura frontend del futuro? ¿Qué ofrece? ¿Ventajas y
desventajas? Y para ello vamos a tener a Daniel de la Cruz, Carlos Villuendas, David García y un
invitado muy especial al teléfono, Jorge del Casar y como siempre un servidor de ustedes, Miguel Ángel
Durán. Quédate, que empezamos.
Y empezamos aquí con Daniel de la Cruz, muy bienvenido aquí, What The Front, ¿cómo estás?
Hola, ¿qué tal? Muy bien, no tan bien como tú.
No tan bien como yo, ¿en qué sentido? ¿De guapo?
De guapo, lo sano, fuerte.
Fuerte, lo sano. Bueno, ¿y algo más?
¿Qué tal? Pues nada, un placer estar aquí otra vez con vosotros en este podcast de frontend.
Muy bien, muy bien. Y nosotros bien hallados de que estés una vez más aquí. Muy bien.
Vamos a seguir aquí con las presentaciones. ¿A quién tenemos más por aquí? Pues a David García. ¿Cómo estás, David?
Eso soy yo. Pues nada, encantado de estar aquí en el Prat otra vez con vosotros y hablando de cosas pequeñitas como los micro frontends.
Sí, son frontends pequeñitos.
Claro, yo que soy también bastante micro, me siento súper identificado.
Te viene al pelo, ¿no?
Me viene genial.
Te viene al pelo. Al pelote viene a ti. Carlos Villuendas, bienvenido.
¿Qué tal? Bienvenido, ¿cómo estáis?
Pues muy bien.
Bueno, bien hallado, de hecho.
¿Bien hallado?
Pues bien hallado.
¿Nos hemos encontrado bien, entonces?
Sí.
Nos hemos encontrado.
Nos he encontrado bien.
Muy bien. Pues también tenemos un invitado muy especial que está al teléfono, que nos debe estar escuchando ahora mismo, que es Jorge del Casar. Bienvenido, Jorge.
Hola, bienvenido y muchas gracias por invitarme. Es una pena no poder estar ahí con vosotros, pero bueno, en remoto.
En remoto. Bueno, en remoto. Hoy en día casi todo es en remoto, ¿no? Estamos todos de acuerdo, es decir, que ahora mismo todos estamos trabajando en remoto de alguna forma, ya sea un día a la semana.
Pero he estado este fin de semana, ya meto aquí un tema, pum. Este fin de semana está en Extremadura, que he estado en la X-Fest, donde han hecho una conferencia de tecnología, frontend backend y tal.
He dado una charla sobre el frontend futuro, pero lo que más me ha sorprendido de Cáceres, aparte de ser preciosa, es que mucha gente está allí trabajando en remoto. Un montón de gente.
Pues es un sueño hecho realidad, porque Cáceres es increíblemente bonita. Además, a nivel de precio, de coste de vida, mucho más barato que las grandes capitales.
Y una suerte la gente que puede trabajar en remoto desde aquí, la verdad. Me dan envidia muy sana.
Totalmente.
Ya estamos tratando de hacer un podcast sobre trabajo remoto, ¿no? Experiencias, cosas buenas, cosas malas.
Pues me lo voy a apuntar. A ver, hacer un podcast. Totalmente, ¿no? Es que hay un montón de gente. Es una pasada la de gente que hay.
Y es que, de verdad, allí en Cáceres decían, claro, es que, ¿qué pasa? Que hay mucha competencia en Madrid, pero entonces intentan pescar en Extremadura.
Ya la gente que va a llegar a, sale de la universidad y ya le ofrecen directamente trabajar en remoto, porque mucha gente dice, bueno, yo es que me quiero quedar aquí en mi pueblo tranquilo y tal.
Y, bueno, es espectacular.
Es que, claro, tener que trabajar de desarrollador para una de las grandes empresas que normalmente van a estar en Madrid o en Barcelona, o no sé si habrá alguna otra más.
O Java, si tecnológico concentra tantísima gente, pues es una opción increíble, la verdad.
Jorge, ¿tú trabajas en remoto?
Varios días a la semana.
Varios días, ha dicho la palabra varios.
Y un par de días a la semana trabajo desde fuera de la oficina.
Muy bien, ¿podemos saber en qué empresa estás trabajando?
Sí, estoy trabajando en Citibox, una startup.
Sí, yo creo que todos somos súper clientes de Citibox porque creo que todos los paquetes de Amazon me llegan ahí, básicamente.
Oye, pues muy bien, ¿eh?
Bueno, Jorge, que sepas que estamos retransmitiendo en directo en YouTube.
Tenemos aquí como 15 personas que nos estaban viendo.
Vamos a saludar a Adrián Rueda, Jorge Ezequiel, Joandi, Villamán, también...
No, ya está. Ahí se han quedado los que han comentado.
No sabemos quién más está.
Dicía Adrián Rueda que estaba en remoto 365 días desde Zahara de los Atunes.
¿Se puede tener un nombre de pueblo más chulo?
Zahara de los Atunes.
¿Dónde?
Y ahí hay unos atunes buenísimos.
Sí.
¿Pero es de verdad que hay atunos buenísimos o es broma?
Sí, sí. Es de Cádiz y ahí se pesca el atún y es espectacular.
Interesante.
Muy recomendable ir para allá y comerte un buen lomo de atún por allí y todo lo que sea de atún.
Pues creo que también podríamos hacer un podcast sobre los atunes.
O de comer.
Apunta.
Voy apuntando. Muy bien.
Mira, también tenemos a Carlos Azadostre.
Buenas. Pues muy buenas.
Muchas gracias a todos por venir y quedaros aquí un ratito con nosotros.
Hoy venimos a hablar de los microfrontends.
Microfrontends.
¿Alguien se atreve a decir qué son los microfrontends?
Porque yo cada vez que leo una descripción es diferente.
Y eso es súper interesante.
Eso es una de las primeras cosas que podríamos hablar sobre los microfrontends.
Yo tengo que decir que he venido aquí a aprender.
Ah, tú has venido a aprender.
Sí, no tengo experiencia en microfrontends, así que vengo a aprender que alguien me explique qué es esto de los microfrontends.
Yo voy a decir la mía.
Venga.
Yo creo que en principio se le llama microfrontends a una combinación de diferentes librerías de JavaScript principalmente metidas en una misma web app.
Bueno, hemos invitado justamente a Jorge, que sabe bastante del tema, y yo creo que nos puede iluminar su descripción sobre qué son los microfrontends.
Adelante, Jorge.
Pues yo desde mi punto de vista es la metodología o el término microservicio aplicado al frontend.
Obviamente no se utilizan los mismos recursos o las mismas librerías que en backend.
Entonces es cómo traemos ese concepto al frontend.
Y más que hablar de librerías o ese tipo de soluciones, es un poco qué problemas podemos solventar o cómo, qué es la idea que hay debajo, que sobre todo es la posibilidad de componer funcionalidades que están en propiedad de diferentes equipos de desarrollo.
Entonces, bajo esa premisa, pues ya podemos seguir desarrollando todo lo que queramos y sobre todo el cómo queramos.
Muy bien, me parece muy bien, muy buena descripción, porque, claro, justamente creo que uno de los grandes debates, y hablaremos sobre ello aquí, es justamente hablar sobre los microfrontends, donde parece más un libertinaje.
Es, cada equipo hace lo que quiere con la tecnología que quiere, pero no tiene por qué ser tan así.
Claro, es un poco lo que comentaba Jorge, que puede ir un poquito más, que pueda deployar cada equipo de forma independiente, que tenga independencia, pero a lo mejor no significa tanto que cada uno tenga que utilizar la tecnología.
No es como no intento implementar Spotify, es decir, un montón de iframes sin marco y cada equipo es responsable de su iframe, y entonces significa que puedes hacer lo que te dé la gana dentro de ese iframe, porque entonces a mí es una locura, está muy bien para tu iframe, está muy bien para tu equipo de producto, puedes ir tirando millas sin preguntarle a nadie, pero la foto finita es una locura.
Es que esto es donde yo me quedo con microfrontends y tiene que haber algo más, porque no se ha hecho tan popular si solo es eso.
Claro, con el tema de microfrontends, bueno, la estrategia para implementar microfrontends es súper amplia, y Spotify fueron de los primeros que intentaron hacer esto, y su estrategia para implementarlos fue con iframes,
pero hay otras empresas que lo están haciendo también, y algunos los hacen con web components, otros los hacen importando directamente el HTML en su página, otros directamente dividen sus subdominios en páginas o en vistas,
que podría tener más sentido. Yo creo que el problema con el paradigma de microfrontends es que está muy abierto, y mucha gente piensa que lo relaciona con microservicios,
como lo que se decía de microservicios, de que bueno, tú puedes hacer tu API en Node, en PHP y en Java, y como todos exponen una API y se comunican por HTTP o por lo que sea,
realmente da igual la tecnología que tienen ahí. En microfrontends no pasa exactamente lo mismo, porque todo ese código acaba en el cliente.
Entonces, a lo mejor puede ser una solución si ya tienes pequeños, pequeñas UIs hechas en Angular, en React, en Bue, y las quieres integrar con el mismo estilo,
pero obviamente no es lo óptimo, porque no puedes optimizar librerías comunes, no puedes optimizar bundles, a la hora de comunicarse, pues cada uno expone paradigmas diferentes,
hay frameworks que son reactivos, hay frameworks que son más imperativos. Entonces, no es tan así, yo creo, el libertinaje para permitir cualquier tecnología,
sino que tiene que haber cierta coherencia y estrategia, porque todo acaba en el mismo producto. No sé, Jorge, qué opinas, cómo lo estáis implementando vosotros.
Sí, efectivamente. La idea idílica de que todos los microfrontends podrían estar desarrollados en diferentes tecnologías,
y orquestarse entre sí es muy hílico y sobre el papel funciona, porque, bueno, teóricamente es aceptable, ¿no?, ese acercamiento,
pero como bien dices, a nivel de performance, de rendimiento, de velocidad de carga, etc., pues sería horrible.
Entonces, hay que limitar un poco todo ese libertinaje y, por ejemplo, yo pongo así sobre la mesa,
pues los problemas que hay que solventar o los problemas a los que nos enfrentamos y así podemos ir abriendo el debate
por esa zona. El primero de ellos es la orquestación, que orquestar, que aplicaciones, ya habéis comentado un poco,
pues con e-frames, con subdominios, con rutas, que es como cómo orquesto todos esos microfrontends,
o microaplicaciones, ¿no? Otra de ellas es el routing, que va bastante relacionado con el anterior,
que es cómo delego las rutas a los microfrontales, cómo hago que cada ruta cargue un microfrontal u otro,
y cómo me comunico con esa orquestación. Otro punto a tener en cuenta que hay que ponerse en común es,
pues cómo aíslo esas aplicaciones, que puede ser ya sea con Vue, una microaplicación, con Angular,
con Web Components, etcétera, es cómo mantengo ese aislamiento. El cuarto punto sería la comunicación entre sí.
Afortunadamente, yo ahí defiendo, ya meto aquí yo mi opinión, que ya se ha hablado de reactividad y demás,
bajarnos al estándar, usar la plataforma, que es eventos van hacia arriba, propiedades van hacia abajo,
y simplificamos en ese sentido, y luego ya dentro de la aplicación que cada uno haga lo que,
como el framework dice o demás, pero hacia afuera, sobre todo eventos y sete de propiedades.
Y el último punto, que es de los más complicados, y sobre todo para mí, que yo estoy más desconectado del mundo
interfaz de usuario, es la consistencia de esa UI. Es cómo comparto estilos, cómo comparto variables de CSS, etcétera,
y cómo hago que un botón, una lista se vea igual en los diferentes frameworks y no termine haciendo
Frankenstein de interfaz de usuario, porque cada framework tiene su forma de importar los estilos,
de emplearlos, etcétera.
Claro, es súper interesante este punto, porque a mí me parece, de todos los desafíos que has dicho,
el más complicado de solucionar, porque yo siempre he visto, tanto las arquitecturas de microservicios,
como las arquitecturas de microfrontings, como una solución tecnológica para escalabilidad organizacional.
Darle a cada equipo el encargo de un área de negocio, de un dominio, y que ellos sean autónomos
para poder desplegar sin tener que hacer grandes integraciones y eliminar dependencias.
Pero cuando estamos hablando de una experiencia de usuario, que es algo que tienes que ser consistente,
aquí está el desafío cuando haces microfrontings.
¿Cómo garantizas que lo que desplegan todos los equipos es consistente a nivel de una única experiencia de usuario?
Jorge, una pregunta. ¿Tú hacéis en Citybox, estáis haciendo microfrontings?
¿Hola? ¿Hola? ¿Me escuchas?
Sí, dime, dime.
Sí, decía que si estaréis haciendo en Citybox, estaréis haciendo microfrontings,
porque veo que como has tenido una experiencia al respecto de utilizar microfrontings.
Efectivamente, estamos... Mi idea es aplicar todo a microfrontings,
y dentro de poco empezaréis a verlo, ya que sois usuarios.
Y como habéis dicho, hay mucho libertinaje en ese sentido, porque no hay nada,
no hay un framework, no hay una librería que te simplifique o te ayude o te oriente en ese sentido.
Entonces, nos está costando un poquito, porque entre que somos pocos y hay eso de planes y demás,
pero bueno, estamos intentando crear esa arquitectura y todo lo que estamos desarrollando está basado en microfrontales.
Y la idea viene porque queremos reutilizar todo lo que podamos en una aplicación y en otra,
y toda nuestra idea de desarrollo está basada en componentización,
para no tener que repetir código de una aplicación a otra,
y que podamos ir más rápido y con cada aplicación que desarrollemos podamos ir cada vez más rápido,
porque ya tenemos mucho hecho.
Pero teniendo en cuenta que, entiendo que la componentización como tal te la puede dar una librería como React, como Vue,
o sea, que entiendo que esto de los microfrontings lo hacéis por algo en concreto, algo más allá,
porque a lo mejor queréis que los equipos sean independientes a la hora de deployar su trocito o...
Exacto, ahora todo el equipo de producto estamos divididos en squad y tanto backend como frontend no somos un equipo tan grande
como para tener squad multidisciplinares completamente, pero ya hemos orquestado todo el equipo de desarrollo para eso.
Y a nivel de front, esa es la misma filosofía, queremos que podamos hacer funcionalidades en to end en un squad
y no tener dependencias entre nosotros, y que podamos desplegar una parte de la aplicación,
por ejemplo, mejorar, yo qué sé, la parte de recogida de introducir el código en el buzón,
solamente esa parte la queremos mejorar sin tener que afectar a todo lo demás
y poder trabajar solo en esa página o en esa microfrontal y no afectar a lo demás, sobre todo.
Cuenta, Carlos.
No veo claro, y esto es porque digo que vengo a aprender, porque de verdad que no sé muy bien
cómo este efecto práctico, cómo se baja a la realidad, porque lo que comentaba Dani, por ejemplo,
creo que un design existente da esa consistencia de experiencia de usuario a lo largo de todo el funnel del usuario.
Y lo que comentaba Jorge, a mí me suena que simplemente es una página hecha con web component,
que cada equipo es responsable de un web component.
Yo soy responsable del web component, que es la cajita de búsqueda con los resultados de búsqueda,
y no del web component, que es la información del usuario.
Pero la página en sí es única, es una SPA única que se deploya de forma atómica.
Es decir, si tú cambias algo en el buscador, tienes que deployar toda la página entera.
¿Es esto o lo estoy entendiendo mal?
En un primer acercamiento, sí.
Ahora mismo hemos empezado a hacer web component independientes para pequeñas funcionalidades.
Lo que estamos empezando a construir ahora es que las aplicaciones sean un conjunto de mini,
que cada página sea independiente, no desarrollar la aplicación end-to-end usando un framework como Angular o React o demás,
sino desarrollar la página home como un componente independiente para poderlo testear todo de manera unitaria
y que esa página incluso podría irse a otra aplicación porque es igual en otra aplicación,
pues coger ese mismo componente página y usarlo en otra aplicación.
O sea que tienes un componente que se llama homepage component, ¿no?
Esto es así.
Y lo pones como un tag HTML en tu sitio, en donde quieras ponerlo, ¿no?
Exacto.
Luego en la aplicación lo que hago es una aplicación progresiva que la ruta al caer en la página home
me dice importa el componente home.
También por consistencia y por asegurar los test de integración,
lo que hacemos es que la app va a hacer un npm install de los paquetes que necesita,
que son las 5, 10, 20 páginas que tenga y la página va a orquestar qué componente carga
y va a escuchar los eventos que emiten esos componentes página
y va a decidir a qué otro URL va a navegar.
Porque también lo que no quiero es que desde una aplicación, desde una página,
tú cliques y digas vete a la página del perfil de usuario,
que es barra user, barra no sé qué.
Entonces, no, el componente no tiene que saber eso, sino lanzar un evento de
oye, me han clicado en tal botón o me han dicho que vaya a la página de usuario
y la app es la que orquesta eso y te redirige a la página de usuario,
carga tu componente correspondiente y no se comunican entre sí,
sino que es un poco un patrón mediador la aplicación la que hace eso.
Es un poco el patrón de actor, ¿no?
O sea, tienes ahí algo a orquestando, que está escuchando eventos y le envías,
o sea, supongo que tienes en la app lo que orquesta los eventos y hace las rutas.
Lo que, claro, eso, yo estoy pensando un poco en el caso de Vinta,
donde estamos trabajando aquí Carlos, David y yo,
y claro, algo así no, supongo que a vosotros no os preocupa tanto el SEO, me imagino.
Pero claro, hacer el tema del routing a base de eventos y enviar y tal,
pensando más en nuestro caso de Marketplace.
¿Tenéis Anchor vosotros? Esa es la pregunta, si tenéis un Anchor o no.
No tienen, no tienen.
Es como la app en la que orquesta y tú le das a un botón,
lanza un evento y en la app escuchan ese evento y, bueno,
obviamente, claro, según las necesidades, pues...
Especialmente, cada uno aplica el concepto en función de sus necesidades
y me imagino que habrá que hacer, claro, yo llego a un approach,
cada uno con los requisitos funcionales que me imponen, ¿no?
Pues tomas unas decisiones u otras y habría que hacer a lo mejor algunas modificaciones en ese sentido.
A lo mejor un approach para vosotros sería que la app te dote de una serie de enlaces
como una propiedad a ese microfrontal y ese microfrontal ya tiene su lista de rutas
y ya las puedes poner en los Anchor.
A ver, David.
Por ejemplo, podría ser una solución para vosotros.
Sí, yo hasta ahora lo que he estado escuchando es un poco así en temas de implementación,
pero a mí lo que me gustaría ir un poco es a entender cuál es la motivación que lleva un equipo
a decidir por los microfrontal, ¿no?
En plan, bueno, ¿qué es lo que nos va a hacer a nosotros que seamos más productivos?
Porque hemos hablado de tener una especie de pipeline, de que un equipo tenga un dominio
y diga, vale, pues nosotros nos vamos a encargar, por ejemplo, de consumir este endpoint
y que ya venga de un microservicio donde sea y vamos a montar nuestra parte de la app en Frontend
y la vamos a deployar automáticamente, ¿no?
Y vamos a ser el equipo que se dedica, pues yo qué sé, a lo que tú comentabas, ¿no, Jorge?
El equipo que se dedica a mejorar todo lo que es la parte de coger el código este
que te envía el usuario para abrir el buzón, ¿no?
Entonces, eso yo de ahí lo que veo es que es una ventaja, pero más que a nivel técnico
es como un concepto que va muy bien para un equipo orientado a una misión
y para un product owner, más que nada, más que una decisión técnica, ¿no?
Porque todos estos puntos en los que hemos estado hablando, toda esta orquestación, todo esto
veo como una complejidad añadida y además que tiene unos traídos bastante importantes
como lo de ahora ver cómo compartimos los mismos componentes entre diferentes páginas
porque yo me veo a lo mejor desarrollando el mismo componente en tres tecnologías diferentes.
Bueno, yo imagino que ahí utilicen ellos un design system, ¿no?
Es para compartir, ¿no?
Sí, pero realmente el equipo, si por ejemplo, tú imagínate que tú tienes una misión que es tal
y el otro equipo tiene otra y deciden de que van a utilizar diferentes tecnologías,
pues uno será Vue, otro React, lo que sea, y aunque el design system sea el mismo,
la implementación de ese design system va a ser diferente para cada uno de ellos.
Ah, bueno.
A la hora de compartir...
Sí, claro.
Pero entiendo que no es el caso, que vosotros no...
Bueno, yo ahí...
No, no, pero por eso estaba ya hablando un poco a nivel conceptual de lo que es el microcontent.
Luego las implementaciones entiendo que cada uno...
Pero yo lo que digo es que el concepto en sí de microfrontend permite empoderar al equipo
para decir, oye, vamos a utilizar nosotros Vue, porque nosotros queremos atacar este endpoint aquí
y vamos a hacer nuestros componentes en Vue.
Y eso le va súper bien al product owner para que él diga, ostras, pues me parece genial
porque yo tengo un equipo que aquí a todo el mundo le gusta hacer Vue
y lo va a hacer a toda pastilla y lo van a poner en producción ellos solos
porque son autónomos, independientes, multidisciplinares y tal
y me van a permitir a mí llegar a mis OKRs, pero súper bien, ¿vale?
Entonces vamos a hacer un equipo súper productivo.
Pero luego está esa parte de orquestación que no sé en quién cae responsabilidad de quién, ¿no?
De todo esto.
Entonces ahí es donde veo yo ese súper trade-off que...
Bueno, a ver, yo por lo que ha dicho Jorge me parece súper interesante
los deploys independientes.
Me imagino que esa es la razón máxima por la que utilizamos microfrontends
porque si no, con monetización lo tendríamos con React.
Pero me gustaría que debatísimos un poco y escuchésemos la opinión de todos
y ya que estoy voy a empezar yo, sobre el tema este que comentabas, ¿no?
Del hecho de la independencia, hemos hablado del libertinaje...
Yo la verdad es que estoy súper en contra de los microfrontends.
He entendido cómo la posibilidad de hacer cada trozo de la página...
Ahora mismo estamos hablando por microfrontends por rutas,
pero lo podría ser perfectamente por cachitos de la misma página web.
Y yo entiendo que no se debería entender como la posibilidad de decidir
la tecnología que vas a utilizar en cada trocito o en cada cacho.
Yo estoy totalmente en contra de eso justamente porque hablaba muy bien Dani
sobre la experiencia del usuario.
Es verdad que podríamos llegar a hacer los componentes con web components
para que se lo puedan reutilizar independientemente de qué tecnología utilizas,
pero claro, la experiencia del usuario también la performan.
Y obviamente eso va a tener un coste muy grande.
En el caso de Jorge, que ha comentado, entiendo que no están utilizando diferentes tecnologías.
No sé si estoy equivocado, Jorge.
No, efectivamente. Ya hemos puesto el requisito de usar web components
para evitar que cada microfrontal esté hecho en una tecnología
y que podamos reutilizar código de manera real.
¿Y utilizáis solo y exclusivamente web components?
Quiero decir, yo la verdad es que hace poco me he enfrentado a un desarrollo solo
y exclusivamente web components y así a pelo es muy a bajo nivel.
No, a pelo.
Claro.
No, usamos Little M.
Vale, vale, vale.
Como librería para facilitar el manejo del trabajo.
Ya es una ayuda.
Sí, sí, porque es que si no los web components están muy bien sobre el papel
y parecen muy potentes y lo son.
Lo que pasa es que, claro, están muy a bajo nivel de la plataforma
y a veces incluso para un estado interno o para cualquier cosa de manipulación
que quieras para actualizar el componente, no veas.
Entonces, vamos a hablar sobre este tema, si os parece,
un poco de los microfrontends entendidos como la posibilidad
de que cada equipo decida la tecnología que quiero utilizar,
Vue, Angular, React,
porque esta es una de las razones por las que mucha gente,
y David lo ha dicho, ¿no?
Que hay mucha gente que dice, no, yo quiero utilizar microfrontends
porque así cada equipo utiliza lo que le da la gana.
De hecho, una de las descripciones, y así empezábamos al principio,
que hablan de los microfrontends es justamente esto,
la posibilidad de utilizar diferentes tecnologías en el mismo cliente.
Entonces, ¿estáis de acuerdo con esto?
¿Os gusta esa idea?
¿No os gusta esa idea?
Vamos a darle caña.
Yo, si quieres, me empiezo a mojar.
Y yo creo que hay veces que puede tener sentido.
Lo que no tiene sentido para mí es que dentro de una misma vista,
de una página, haya componentes hechos en diferentes tecnologías
y desarrollados por diferentes equipos,
porque acabas teniendo un cristo.
Imaginaos cómo haces test de integración ahí,
cómo hacer los deploys,
cómo mejoras la performance, etc.
Es muy difícil optimizarlo,
ya no solo a nivel tecnológico,
sino a nivel de...
de comunicación entre los diferentes equipos, etc.
Lo que pasa es que hay casos de uso
en los que puede tener sentido
que un microfrontend esté hecho en otra tecnología
que no sea la del resto de tu site.
Por ejemplo, imaginaos
el típico...
el típico blog corporativo
o la típica página de soporte.
Ahí a lo mejor tiene sentido
usar alguna especie de framework
o out of the box
que esté hecho en PHP, por decir algo.
¿Por qué?
Porque está optimizadísimo para ese caso de uso.
Y eso forma parte de tu página,
de tu página o de tu sitio.
Y a lo mejor el resto de páginas
están hechas con React
porque hay un buscador
o porque hay una lógica de negocio, etc.
Y la coherencia la das
a través de un design system
que solo expone estilos.
Pero obviamente no tiene sentido
reutilizar los componentes de React
en un WordPress en PHP.
A lo mejor te resulta más fácil
hacerte tu tema
y ya está.
¿Pero eso realmente son microfrontends?
Esos pueden ser microfrontends.
Es que eso se ha hecho toda la vida.
Claro.
Eso, por ejemplo,
el fotocasa.es, vale.
Pues la experiencia del usuario
de home, parrilla y detalle,
está hecha con React y tal,
pero entonces entras al blog
y no deja de ser un WordPress.
No sé hasta qué punto,
entiendo lo que quieres decir,
pero no sé hasta qué punto
ahí es donde estaría la gracia del...
¿Tú te refieres a eso
o a tener un cacho de la página de...
O sea, de la home de fotocasa
que un cacho fuera una parte de WordPress?
Es que precisamente
el viernes pasado estuve en un webinar
de Luca Mezzalira
que es el VP of Architecture
de The Zone,
que es una especie de Netflix deportivo
que ha salido hace poco en España.
Y él explica
cómo han organizado su página
en microfrontends
y este tío es un evangelista
de microfrontends
de los primeros
que ha empezado a hacerlo.
Y los subdominios
que él explica que tienen
es, por ejemplo,
la homepage.
La homepage tiene características
que tiene que ser muy rápida cargando,
tiene que ser muy optimizada para SEO,
no tiene que tener
toda la parte de lógica
de usuario autenticado, etcétera.
Luego tienen otro subdominio
que es toda la parte
de registro de usuario
y autenticación.
Ahí puedes tener diferentes páginas,
puedes tener Redux,
React Router
y una lógica orientada a eso.
Y eso carga en una plana distinta.
Entonces, en el webinar
él también decía,
imaginaos la típica imagen
que veis en todas las charlas
de microfrontends
en las que sale
una tienda online
con la lista de productos
y en esa imagen te pone
la lista de productos
hecha con React
y el carrito de la compra
con Bue
y la cabecera con Angular
y todo en la misma página.
Él decía,
esto es un antipatern
porque lo que estás creando aquí
es un árbol de dependencias
para desplegar una página
y cómo optimizas eso.
Él desaconsejaba
pensar en microfrontends
como cachitos pequeños
que acaban en la misma página.
Dice,
si tienes todos estos tres componentes,
a lo mejor tiene sentido
desarrollarlos como componentes aparte,
pero los hace el mismo equipo.
Porque ese equipo
es owner
de la experiencia de usuario
de buscar y comprar un producto.
Yo es lo que veo aquí
a nivel de concepto
con esto que comentas, Dani,
es que entonces
el microfrontend
lo que se tiene entendido
es como una división
más vertical
de horizontal
como hemos hecho siempre.
De decir,
el backend,
si lo hacemos en horizontal,
el backend
es lo que queda por debajo
y el frontend
lo que está por encima.
Y de esta forma
lo que harían serían
cortes más transversales,
más verticales
que incluyen los dos.
Tanto el frontend,
ya sea un microservicio
o cualquier otra API
que exponga lo que sea,
y algo que consuma
esos datos
a nivel de frontend
y tenga su propio pipeline
de deploy
con continuous integration
o lo que sea y tal.
Entonces,
ahí cada equipo
o cada web app
decidirá la estrategia
de esplitado
para todos estos microfrontends.
Claro.
Pero no dejan de pertenecer
todos a la misma web app
y yo veo el microfrontend
como entendido
como que forman parte
de la misma web app
y que cada uno
se encarga
de diferentes dominios.
Ya sea, por ejemplo,
en el funnel nuestro
en AD Vinta
que tenemos
en todos los marketplaces
del self-find and contact,
pues ahí lo veo claramente
que cada dominio
o cada URL,
ya sea para buscar,
para encontrar,
filtrar, etcétera,
o para ir al detalle
y contactar,
pues tendría su dominio,
tendría su propio arquitectura
de microfrontend.
Lo que pasa es que...
Perdón,
dale, dale.
Iba a decir,
otro ejemplo
que además tiene la charla
publicada en YouTube,
la podéis ver,
es el de Trulia,
que se parece mucho
a lo que hacéis vosotros.
¿Tulia utiliza microfrontends?
Trulia utiliza microfrontends
y lo hacen con Next.js y Now.
De hecho,
ellos ayudaron
al equipo de Shade
a desarrollar
lo que ellos llaman
como zonas
y cada zona
es un microfrontend
que se pueden linkar
entre ellas
con links
dentro de la página.
Ellos tienen un link
que te redirige
a un subdominio
pero acaba cargando
un frontend
que se despliega
por sí mismo
y al que puedas acceder.
De hecho,
si entras en Trulia
ellos explican,
ellos le llaman islas,
no microfrontends.
Pero acaban siendo microfrontends.
Entonces,
ellos tienen la isla
de la home,
la isla del buscador
por mapa,
la isla del buscador
por lista,
la isla del detalle,
la isla de la zona
de usuario
y cada una de ellas
las mantiene un equipo
y le dan
una coherencia a todo
con el framework
multipropósito
que le llaman ellos
que es el de Next.js
que además te permite
enlazarlas entre ellas
y compartir cosas
con la típica librería
que a lo mejor
se encarga
de la autenticación
y de gestionar
el token de usuario
y de cosas
que son más transversales.
Claro,
pero es que
qué complicado.
Estamos hablando
como estamos
yendo más
a dividir nuestra página
por rutas
y eso tampoco me parece...
No por rutas,
por dominios.
Sí,
pero es que el dominio,
sí,
pero tenemos
la isla home,
por ejemplo,
la isla de búsqueda
por mapa.
Eso puede ser más rutas
que otra cosa.
Por ejemplo,
si entendísemos bien,
bien exactamente
los microfrontends
y el ejemplo
que ha puesto David,
el equipo de contactar
debe incidir
y debería ser capaz
de deployar su parte
de contactar
tanto en home,
parrilla,
detalle,
en todos esos sitios
donde se puede hacer
un contacto.
Exacto,
porque los equipos,
la división ya no es técnica
de home,
parrilla,
detalle,
sino que son divisiones
de equipos orientados
a misiones
que llevan unos OKRs,
unos KPIs,
inciden directamente
sobre ellos
y como dice Miguel,
pues ahí tú puedes contactar
en la página home
en el detalle.
Claro,
entonces,
¿cómo los microfrontends
ayudarían a ese equipo
o a esos equipos
por misiones?
Porque,
por ejemplo,
también habría un equipo
de buscar
o de encontrar,
¿no?
Pues eso lo puedes hacer
en home,
parrilla,
detalle,
parrilla por mapa y tal,
pero la gracia justamente
entiendo de los microfrontends
que sí que lo veo muy claro
por rutas
y por rutas
y puede ser mucho más fácil,
pero ¿cómo un microfrontend
le puede encajar
a estos equipos
para deployar esa parte
por muy pequeña que sea,
¿sabes?
Y que impacte de golpe
en 17 rutas distintas.
Es que yo creo que eso
es un error
y las charlas
y webinars
que estoy viendo
de microfrontend
desaconsejan hacer eso
y aconsejan
que si tú tienes que contactar
en dos sitios distintos
y esos dos sitios
están mantenidos
por dos equipos,
que se haga el código
dos veces.
Es mejor hacer eso
para no crear
esa dependencia
entre el equipo responsable
del formulario de contacto
que tiene que desplegarlo
en siete microfrontends.
Pero ¿no sería mejor
tener un componente
de contactar
que lo reutilizan
todos los equipos?
Quiero decir...
Claro, por eso tú y yo
estamos en contra
de los microfrontends, Carlos.
Bueno, yo...
Claro, es que lo que...
Lo que estoy viendo
es que los microfrontends
si es como...
Como tendría que ser así,
la única solución técnica
posible que yo veo
es crear un iframe
que sea la parte de contactar
que esto cuando yo lo cambio
se cambian todas las páginas
de golpe.
Yo lo que estoy diciendo
es no hacer eso.
Claro, claro.
No hacer un formulario
de contactar
a un componente
de contactar reutilizable.
Claro, Dani.
Es lo que estoy diciendo.
Tú lo que dices es
vamos a duplicar
la misma funcionalidad
en dos componentes
y vamos a hacer
doble mantenimiento
o triple
o cada vez que tú quieras
iterarlo
y añadir una nueva funcionalidad
lo vamos a hacer
que N veces
tantas veces
esté explicado
ese componente.
llegue a todos los equipos
y ahora imagínate
algo así como
en la Devinta
que no es un solo vertical
sino que son
siete verticales
siete marketplaces
que solucionan
el mismo problema
en N veces.
Vamos a ver aquí
que nos están comentando
por YouTube
en directo
tenemos aquí
decía Jesús
holaza
goitia
wow
decía que los web components
pueden ser para el frontend
como una API
para el backend
no sé si estamos de acuerdo
en eso
que nos puede servir
como para lo mismo
yo creo que los web components
pueden encajar
sobre todo con la idea
de micro frontends
o no
incluso para cualquier tipo
de componentes
porque están cerca
de la plataforma
pero como hemos visto
Jorge incluso
pues dice
que web components
así por sí mismo
siempre vas a necesitar
tener una pequeña librería
que te pueda ayudar
Diego Reimi
comenta
nosotros trabajamos
con micro frontends
pero en todas las squads
trabajamos con las mismas
tecnologías
que son Angular
y Java
soy nuevo en el proyecto
pero creo que
lo que buscan
es alta productividad
en equipos pequeños
y multidisciplinares
bueno
tiene sentido
¿no?
sí
la verdad
Dani
yo venía un poco
a defender los micro frontends
pero después de lo que me has comentado
me estaba convenciendo más
Jorge
Jorge que no sé si
el pobre se nos ha quedado frito
Jorge ¿estás ahí?
sí, sí
sigo por aquí
vale
¿cómo ves todo esto?
¿cómo vais...?
porque entiendo que ahora
lo tenéis muy muy muy claro
y es muy fácil de ver
por rutas
yo creo que aquí
lo estamos viendo todos
clarísimo
pero cuando empieza ya
una misma ruta
puede ser la home
puede ser lo que sea
lo que nos ocurra
tengas dos equipos
que impacten
esa misma ruta
por ejemplo
yo sé que dentro
de nuestro equipo
en Noruega
tienen un framework
que básicamente
te permite hacer
server side rendering
e inyectar
diferentes micro frontends
en la misma ruta
pero es verdad
que lo que dice David
está añadiendo una complejidad
que habría que ver
si eso está
de alguna forma
dando suficiente beneficio
respecto al trabajo
que está generando
yo no sé si este problema
lo vais a afrontar vosotros
Jorge
el hecho de que
en una misma ruta
vayáis a querer
que dos equipos
impacten
¿puede ser?
¿tiene sentido?
¿o cómo habéis pensado
en dirigir esto?
claro
nosotros sí que
usamos como base
los web component
para toda esta parte
de reutilización
entonces cada
web component
independientemente
de que sea
un botón
o que sea
toda una página
completa
tenga su
propio ciclo de vida
su integración
continua
y despliegue
continuo
y
un
perdona Jorge
lo haces por url
es decir
la barra
es
todo
con integración
continua
barra listado
es
otra integración
continua
distinta
y tienes
algo por encima
que vaya redirigiendo
a cada uno de ellos
bueno
en este primer momento
tenemos
una app
que puede ser
el dominio
pongamos
citybox.com
vale
y
ahí es donde
tengo
yo todo
el orquestador
que
en caso de que
entre
citybox.com
barra
recogidas
por ejemplo
esa app
grande
lo que va a hacer
es
importar
y instanciar
la aplicación
recogidas
que a partir
de ese momento
se le pasa
la ruta
lo que haya pasado
recogidas
y ya
orquesta
él
porque va a parar
los eventos
que hagan
los componentes
inferiores
los va a frenar
la aplicación
recogidas
y nunca van a llegar
a la aplicación
padre
y entonces
se va a quedar
como desactivado
como que
no va a escuchar
no va a ver
qué está pasando
ahí debajo
porque te va a encargar
todo la micro app
recogida
lo que pasa
es cómo consigues
hacer un ciclo
de integración
continua
con rutas
distintas
si
yo como estoy imaginando
es una web app
enorme
o sea grande
que es la que
recibe como dependencia
todos los
todos los componentes
páginas
pero
es decir
ahora mismo
no puedes
deployar
cada página
por separado
no
deployas
la aplicación
entera
y si quieres
deployar
cada página
por separado
tendrías que
cambiar la arquitectura
para poder
decir
tengo algo
por encima
que me balancea
entre
home
listado
y demás
y cada uno
de ellos
serán
a su vez
pequeñas
aplicaciones
porque
ahora mismo
no podrías
deployar
de forma
independiente
o
me estoy perdiendo
lo desplegamos
y versionamos
la página
o la aplicación
de manera
independiente
si es cierto
que
como no hemos
llegado todavía
a ese nivel
tenemos
el
pues eso
el wrapper
que es la aplicación
que es el que hace
en EPM
instala los paquetes
de la versión
que toca
pero
si que tengo en mente
de alguna manera
tener un
un CDN
que en lugar
de yo
importarlo
de no de módulos
importarlo
del CDN
directamente
el microfrontal
y que
pues yo diga
oye
dame la aplicación
la página
recogida
y se lo pido
un CDN
entonces lo que está
en el CDN
es lo que me descargo
y
si en el CDN
se ha desplegado
versión nueva
pues me descargaré
versión nueva
eso será
a futuro
lo que
lo que pretendo llegar
pero
step by step
vale
claro
una de las ventajas
que tienes
por tu parte
y mucha gente
que utiliza
microfrontal
seguramente
es que
os podéis permitir
el client-side rendering
puro
solo tenéis que hacer
que align-side rendering
¿por qué decimos esto?
porque me imagino
que muchas empresas
que necesitan
service-side rendering
el hecho de intentar
utilizar microfrontal
es mucho más complejo
una vez que lo haces
todo en el cliente
bueno pues puedes llamar
a una API
que te devuelva al chunk
que tiene que descargar
y bueno
lo puedes ir actualizando
de alguna forma
pero
pero también se puede
sí, sí, sí
no
se puede
pero es una complejidad
añadida
claro
que de hecho
es lo que digo
nosotros tenemos
una empresa ahí en Noruega
que tiene un framework
que se llama Podium
que hace justamente esto
con service-side rendering
pero
hombre
hay una complejidad
bastante
escala
¿sabes?
en el cliente
es mucho más sencillo
ir bajando de forma síncrona
y que se vaya montando
la página
y ya está
pero el servidor
que tienes que hacer
de una forma conjunta
respuesta HTML
hay complejidad añadida
eso
además es un problema
si en una misma página
insisto
intentas cargar
microfrontends
que vienen
de diferentes
servicios
cada uno
con su tiempo
de respuesta
y todo
eso al final
si lo intentas
renderizar todo
en el servidor
esperas
lo que tarda
las requests
que más tarda
pero si eso
lo mantiene
un unique key
pues se deploya
todo junto
en esa misma página
pues puedes optimizar
a nivel de carga
de esa página
hay una cosa
que me ha sorprendido
mucho de los microfrontends
y tal
leyendo información
al respecto
y es
dos puntos
bastante claros
sobre los microfrontends
el primero es
el ataque frontal
respecto a los monolitos
como que los microfrontends
vienen a solucionar
los monolitos
¿qué tiene de mano
los monolitos?
lo que te dicen
es que cuando
desacoplas
un monolito
de backend
que tiene
gustado ahí
el frontend
que no vayas a crear
luego tú
otro monolito
de frontend
también
yo soy súper fan
de los monolitos
eso es un poco
para que no tengas
que deployar
todo entero
para cambiar
una pequeña funcionalidad
eso es un poco
la lucha frontal
que tienen
los microfrontends
pero yo no sé
si el trade
tan gigantesco
que yo le veo
compensa
compensa
no sé
a mí no me acabáis
de convencer
pero no venías
a defenderlo
yo que escucho
los argumentos
de aquí
de Miguel
cuéntanos
los argumentos
yo pensaba
que Miguel
nos iba a comentar
yo también
porque me dijo
no voy a comentar
así que no
tengo decidido
si yo
a ver
no tengo decidido
eso es que se está
trolleando
es que creo
que justamente
el caso de uso
que comenta Jorge
tiene todo sentido
del mundo
para su empresa
y creo que
como decía Dani
pues puede haber
en otros aspectos
que tengan sentido
a mí me gusta muchísimo
el pensar en la idea
de que los equipos
sean totalmente
independientes
a la hora de deployar
sus funcionalidades
en las que deben
impactar
pero
claro
cuando ya se le añaden
ciertas complejidades
que pueden tener
en tu empresa
como necesitar
server server rendering
bueno pues es una
complejidad añadida
que obviamente
no sé si lo compensa
ya
lo que te da
esto de hacer
un deploy independiente
cuando ya hay
deploys por ejemplo
que pueden tardar
un minuto y medio
dos minutos
y que con test de integración
pues ya lo puedes hacer
puedes hacer
diferentes aplicaciones
como
hemos comentado
en Now
que te hace
deploys por rutas
eso podrías lograrlo
podríamos
por lo que
yo no entendía
eso tanto
como micro frontends
pero bueno
veo que
se entra
de esa de
podemos entrar
que eso es
para mí es trampa
pero
puede ser
micro frontends
de deployar por ruta
pues bueno
eso es algo
que está al alcance
de por ejemplo
un monolito
como tal
podrías hacer
porque ya Now
te lo hace
casi automático
te lo hace de gratis
entonces creo
que algo así
me parece fantástico
pero no
no creo
en los micro frontends
con diferentes
tecnologías
me parece que eso
es pegarse un tiro al pie
nos quejamos de un monolito
pero esto podría ser peor
que un monolito
tener
n número de tecnologías
conviviendo
y esto
a mí
hay esto de repetir
la funcionalidad
más que nada
porque he vivido
en esa parte
de repetir
en más de una página
y eso
me da miedo
más que otra cosa
¿sabes?
eso cuando dices
no quiero volver ahí
no quiero volver a abrir
esa caja
pues es eso
pero me parece
que tiene cosas interesantes
es verdad
que se está poniendo de moda
pero también es verdad
aunque le deseo
toda la suerte del mundo
a Jorge
y espero que nos comente
cómo le ha ido
y tal
creo que el que más
se acercó
a intentarlo
fue Spotify
que lo hizo
a partir de iFrames
pero más adelante
pues dio un paso atrás
y dijo que no
que iban a apostar
por React
y por Redux
creo que va a tener sentido
en algunos sitios
pero no sé yo
si va a ser tan mainstream
no lo sé
no lo sé
Cliential Rendering
eso yo creo que
si solo tienes
Cliential Rendering
nada de SEO
pues eso te puede ayudar
pero bueno
le veo cosas buenas
pero demasiadas desventajas
para mis casos de uso
yo hay algo también
que quería añadir
y es que
al igual que microservicios
y insisto
creo que lo he dicho antes
la arquitectura
de Microsoft Frontends
viene a solucionar
un tema
de escalabilidad
organizacional
nunca
debería ser
la primera opción
cuando tu empresa
es
pequeña
cuando estás empezando
con tu producto
cuando
cuando no tienes
el problema
de muchos equipos
tocando una base
de código
y
dependencias
entre ellos
ahí
siempre hay que ir
a por lo más sencillo
que es
un monolito
y tirar millas
con eso
hasta que realmente
se convierta
en un problema
porque
el trade-off
es esa complejidad
tanto a la hora
de desplegar
como a la hora
de testear
y de repartir
las funcionalidades
entre subdominios
monolito
monolito
y acoplamiento
no tiene por qué
ser lo mismo
lo digo porque
la palabra monolito
está como muy
estigmatizada
pero monolito
y acoplamiento
no tiene que ser
lo mismo
de hecho nosotros
deployamos monolitos
pero cada
cada cacho
de la página
es un paquete
NPM independiente
entonces
me gusta la idea
de
lo que comentaba
Jorge
me gusta la idea
de
que es un poco
se lo ve como
muy natural
de decir
voy a darle
uno en el chip
de un componente
de la página
a un equipo
ellos lo están haciendo
casi a nivel de página
pero es un componente
que según yo he entendido
al final acaba dentro
de
ahora mismo
acaba dentro
de un gran orquestador
una web app grande
eso tiene más sentido
y como decía
Miguel Ángel
yo lo que no veo
y creo que
nadie en esta mesa ve
es esto de los iFriends
con 20.000 tecnologías
y tal
Odium me parece
que no tiene iFriends
pero lo que hace
es meterlo todo
en la misma página
es decir
como alguien tenga
dos versiones de React
yo no sé qué va a pasar ahí
pero
obviamente
todo en la misma página
eso tampoco
eso ya sí que no lo veo
porque eso puede romperte
si no tienes cuidado
sé que tiene como
un sistema
de
resolución
de dependencias
que son la misma
y tal
pero le estuvimos preguntando
sobre el hecho este
de oye
qué pasa si tienes una versión
que justamente
por ejemplo
pues tiene React 16
pero una tiene la versión
con hooks
y otra no tiene la versión
con hooks
entonces
y él decía
bueno pues
resuelves con la
mejor
pero
claro
pero
y hay breaking changes
y hay
él decía que mayors
no
no se resolvían
de forma igual
o sea
tenías dos mayors
pero entonces yo le decía
ostras
pero si tienes dos mayors
entonces tienes el problema
de
y con los hooks
eso ya no es tan fácil
sí
a mí el hecho
creo que estamos todos de acuerdo
y Jorge
creo que también
en esto podemos estar todos de acuerdo
incluso
creo que Jorge
en esto sí que está de acuerdo
nosotros
que
diferentes tecnologías
pues es
es muy complicado
y es una pena
porque los micro frontends
muchas veces se venden por ahí
mucha gente
ha hablado con ella
me dice
no es que así
cada equipo
puede hacer lo que quiera
bueno yo no sé
si el libertinaje
es algo positivo
en el tema
de micro frontends
no sé si suena muy duro
pero
no
no suena muy duro
la web es muy sensible
es que es muy sensible
claro
claro
y pensar también
a nivel de
yo que sé
de cambiar de equipo
de hacer onboarding
de todas
esas cosas
eso para mí es clave Dani
porque
yo una cosa que veo
es
no lo digo porque yo
haya cambiado de equipo
pero por qué me lo tienes que sacar
Carlos
si has sido tú
el que me liaste
bueno
yo lo que quería
esto es súper importante
Dani
porque
yo lo que veo
en la implementación
de micro frontends
es que
conlleva más
a la fragmentación
a que cada equipo
diga
ah mira nosotros
vuelvo un poco
a lo de antes
que
el micro frontend
entendido
como que tú puedes coger
y utilizar tu propia tecnología
pues claro
de esta forma
un equipo puede coger
y decir
pues mira nosotros
nos dedicamos a esta tecnología
ya estás
nuestra responsabilidad
o estás
ha petado algo en producción
pero bueno
tranquilo
que esto es del equipo
de los de React
¿sabes?
claro
ahí
y además
que todas esas sinergías
que creamos entre nosotros
por ejemplo
en la de Vinta
que hacemos estos meetings
de compartir conocimiento
etcétera tal
pues yo ya veo
que sería mucho más difícil
que se creasen
¿no?
serían muy
a líneas muy generales
¿no?
ya no tan en detalle
o tan de implementación técnica
y eso también lo veo
un trade-off
súper importante
entonces
realmente no
no acabo de ver
ahí esa ventaja
de utilizar estos microfrontends
porque creo que
aunque tú tengas
tu propio dominio
si has llegado ya
a unas
a unas reglas
y a
y a tener
una serie de consensos
entre todos los equipos
para utilizar una tecnología
pues ya te puedes encargar
de tú
de hacer tus propios pipelines
si quieres
de
de deploy
y de
ganar esa autonomía
que tendría el equipo
sin necesidad
de entrar en este sistema
de
microfrontends
bueno pero
es que justo comentábamos
que los microfrontends
no te inhabilita
a hacer eso
o sea puedes llegar
a todos esos acuerdos
puedes tener
una tecnología común
puedes tener esta cultura
pero puedes tener microfrontends
que eso yo creo que
es por lo que abogamos
todos
entonces
es como que te está restando
libertad
porque eso es lo que dice
yo creo que no
yo creo que lo que te habilita
es que
si en algún subdominio
tiene sentido
por ejemplo
utilizar un framework reactivo
tipo RXJS
por ejemplo
imagínate que tienes
en el caso de Netflix
¿vale?
tienes el buscador de películas
ahí tiene sentido
hacer un framework reactivo
no necesitas llegar
a un acuerdo
con toda la comunidad
para
meter esa librería
la metes en tu subdominio
en tu microfrontends
porque es lo que tiene sentido
obviamente no vas a hacer
todo el estar tecnológico
diferente
pero sí que te habilita
en esos casos de uso
donde tienes que tomar
una decisión
la puedes tomar
a nivel local
de equipo
no creas esas dependencias
bueno eso no es un siglo
de conocimiento
bueno puede ser
un siglo de conocimiento
pero
pero
pero a la vez
ese equipo
está desbloqueado
no tiene
no tiene que llegar
a un gran acuerdo
entre
entre
entre toda la comunidad
imagínate también
en escenarios de equipos
deslocalizados
¿cómo
como acabas llegando
a ese consenso?
a lo mejor no se hace
simplemente
porque no hay acuerdo
o por temas de discusiones
si tú eres responsable
de esa parte
y ves que tiene sentido
pues ¿por qué no lo vas a hacer?
bueno
vamos a
despedir a Jorge
Jorge no sé si quieres decir
algunas últimas palabras
al respecto
pues suscribo a la parte
de
de que
varios frameworks
en un
en una misma aplicación
es un poco locura
aunque
bueno
puede tener sentido
en
en empresas grandes
pero no
que lo desarrolles
desde ahora
sino empresas
que ya tengan
diferentes aplicaciones
hechas en diferentes
frameworks
entonces
puedes
mediante esta
mediante microservicios
podrías integrar
todas ellas
y poco a poco
irlo evolucionando
sin tener que
tirar por tierra
todo a una aplicación
y reacerla de nuevo
entonces puedes ir
metiendo pequeñas features
poco a poco
entonces
esa es el único
la única justificación
¿no?
de hacerlo
en diferentes tecnologías
y
y se me ha ido
lo otro
se ha ido
por otro
deploy
que has hecho
se me ha ido
por otro deploy
y que
poco más
que yo
ah bueno
sí esto
que
la parte de comunicación
al final
aunque estén los equipos
deslocalizados
y demás
siempre
es bueno
firmar un contrato
como se hace
con la ZAPI
y
igual que firmas
un contrato
con backend
de
nos vamos a comunicar
de esta manera
tú me vas a mandar esto
y yo te voy a devolver esto
lo mismo puede suceder
entre
microfrontales
con
con el seteo de propiedades
y el evento
y el envío de eventos
yo voy a enviar estos eventos
y voy a esperar
estas propiedades
para
para funcionar
entonces de esa manera
pueden comunicarse
y hacerse independientes
los desarrollos
siempre que hay un contrato
de comunicación
y se puede crear
un escándalo
de prefijos
de eventos
con
custom event
y después
yo voy a
prefijar todos los eventos
con el nombre del componente
seguido de no sé qué
o con el nombre de la acción
seguido de
no sé
se puede fijar
un convenio
claro
y este tipo de cosas
facilita
la comunicación
entre ambos
y no
ocasiona caos
claro
pero lo guay
de lo que dices
un poco
por rematar
es que
la comunicación
se dirige
a los contratos
en los extremos
y no
a los detalles
de implementación
¿verdad?
no te entendí
creo
sí
en los extremos
de tu dominio
tú defines
cómo tu dominio
se habla con los demás
¿no?
ese es el contrato
que defines
igual que en las APIs
pero no vas a los detalles
de implementación
no vas a
cómo estás estructurando
el interior
de tu dominio
ahí no tienes que llegar
a ningún consenso
claro
la idea es
efectivamente
llegar a
caja negra
de lo que pase
dentro de ese
micro frontend
a mí me da igual
puedes usar Redux
RX
lo que quieras
para gestionar el estado
o nada
es como
bueno
yo te voy a aceptar
esta propiedad
que es
lo que me han dicho
que diga
que es
añadir al carrito
a la compra
te paso un objeto
ni idea
de cómo vas a gestionar
tú ese objeto
y a la vez
cuando tú me haces
el checkout
clicas en el checkout
si eso ya se sale
de tu responsabilidad
pues lanzas
hacia arriba
el micro frontal
obtiene ese evento
que puede ser interno
y dice
ostras
este no sé
yo gestionarlo
lo lanzo hacia arriba
de una manera estándar
para que
el micro frontal
el patrón mediador
el actor
que esté por encima
me entienda
porque yo no he sido capaz
de resolver
este evento
que me han mandado
desde abajo
muy bien
bueno pues nada
Jorge
ahí quedan
tus últimas
indicaciones
te deseamos
la mejor de las suertes
con la implementación
de los micro frontends
seguramente te llamaremos
más adelante
para ver cómo ha quedado
en todo esto
y se ha ido
para ver cómo ha ido
si lo implementaste
algo que cambiaste
porque supongo
que la experiencia
luego al final
uno empieza por un lado
y luego termina
por otro
Jorge ha sido
un verdadero placer
tenerte hoy aquí
en What The Front
muchas gracias
por pasarte aquí
un ratito
igualmente
muchas gracias
y ahora os sigo
viendo por el streaming
muy bien
Jorge
pues nada
hasta luego
un abrazo
pues nada
este era Jorge
del Casar
muchas gracias
por estar aquí
pues nada
micro frontends
no sé si queréis decir
las últimas palabritas
sobre todo Carlos
lo he visto muy triste
muy abatido
muy apagado
con el tema
de los micro frontends
no te veo
hay algo como que
no te excita
es que no te excita
yo pensaba que me iba a volar
la peluca aquí
con los micro frontends
digo porque
me estoy perdiendo el chiste
porque está todo el mundo
muy loco
con los micro frontends
y no
no me ha volado la peluca
sigo con mi peluca
pero le ves
o sea quiero decir
las ventajas que ofrece
o que puede ofrecer
se las ves
por ejemplo
el deploy independiente
¿tú crees que eso
no podría molar mucho?
el deploy independiente
podría molar mucho
me gustaría verlo funcionando
o sea me gustaría verlo funcionando
el deploy independiente
o sea quiero decir
si es por su dominio
obviamente si ya está
pones un engine arriba
y ya está
nada más
pero me gustaría verlo funcionando
todo debajo de
no sé qué punto com
y que a partir de ahí
que todo esto funcione
el deploy independiente
esto me gustaría verlo funcionando
porque todavía no sé cómo
es que
a mí es
ahí es donde está
el reto
ver esto funcionando
en el 80%
de la página
en ese 80%
donde está
toda la funcionalidad
de tu página
porque obviamente
yo no tengo ninguna duda
que puedes hacer
el back office
con la tecnología
que te dé la gana
no tengo ninguna duda
de que vas a
preguntas frecuentes
y lo haces en Angular
si quieres
pero yo quiero ese funnel principal
que tienen todas las páginas
ese 80%
en el cómo dividir
esos pequeños trocitos
de la misma página
y poder deployarlo
de forma independiente
yo creo que ahí
ver esa demo
y ver que tenga sentido
la experiencia del usuario
que sea sencilla
la implementación
que esté bien resuelto
la comunicación
a mí
la solución de Jorge
por supuesto funciona
pero me da a mí
la sensación
que nos cara
me da a mí la sensación
por experiencia propia
de trabajar con eventos
los convenios
pueden ayudar
por supuesto
pero soy bastante
no me termina
de convencer
esto de lanzar eventos
bueno
es el patrón
de actor
típico
que es complejito
de que al final
escale bien
eso
al final
no sé si tiene tantos eventos
porque creo que los eventos
son más
de cambios de página
y tal
creo que después
internamente
no creo que
tantísimos eventos
lo que acabas compartiendo
en una sesión de usuario
es a lo mejor
el token de autenticación
la cultura
ese tipo de cosas
que son
definitiva
es el estado global
de la aplicación
el estado global
exacto
no creo que no
mi preocupación
no es tanto
mi tema no es tanto
que no escale
porque creo que
más o menos
es un tema controlado
es que no veo
cómo salía
o sea yo quisiera
verlo funcionando
mira funciona así
más allá de
ahora entiendo
ahora veo que tiene
un montón de componentes
pero cómo lo haces
para que diga
yo cambio este componente
hago un deploy
y sin tocar una línea
de código
en ninguna parte
de la aplicación
sin volver a redeployar
nada
en ningún otro sitio
el siguiente usuario
que venga
está viendo la nueva
aplicación
pero eso
eso es que ya
por ejemplo
en nuestra empresa
estamos haciendo esto
nosotros en alguna forma
tenemos micro fronters
porque tenemos
widgets
hechos con react
que lo podemos deployar
de forma totalmente independiente
estamos
¿qué pasa?
que esos widgets
son un poco especiales
en el sentido
de que son claras
el rendering totalmente
son totalmente asíncronos
y son totalmente diferentes
respecto a cómo funciona
lo demás
porque lo demás
sí que tiene que ser
el rendering
pero eso es un micro fronter
en sí mismo
le estamos diciendo
mira en este trocito
tú de forma totalmente
independiente
no solo al deploy
sino al funcionamiento
general de la página
tú tienes que poner aquí
un widget
con las últimas ofertas
pero los widgets
sí que nos calan
los widgets
sí que creo que nos calan
pero la idea es la misma
en realidad
los micro fronters
no dejan de ser
un widget
a lo mejor más trabajado
glorificado
pues
no porque
con los widgets
te abstabes
de todo el problema
de la implementación
de algo mucho más complejo
como de toda la aplicación
entera
de todo esto
de orquestación
toda esta orquestación
ya no la tienes que hacer
con el widget
entonces
bueno
ahí
digamos que es
completamente diferente
yo lo veo así
pero lo podrías hacer
un widget podría hacer
exactamente la misma
la misma orquestación
podrías tener una aplicación
más arriba
que orquestre
exactamente igual
pero entonces
ya tendríamos
una serie de problemas
tú el widget
o sea
¿qué es lo que te inhabilita
a que el widget
la hace un evento?
ninguno
puedes lanzar un evento
cambiarla
podrían hacer exactamente
lo mismo
es que es exactamente
lo mismo
solo que estamos pensando
que un widget
es como un átomo
o algo
una molécula
algo muy chiquitito
y entendemos que
los micro fronters
tienen que tener
más sentido de organismo
porque bueno
tienen que tener
un objetivo
una misión más grande
pero en realidad
no deja de ser eso
tienes ahí
el deploy independiente
podría ser la tecnología
que quisiésemos
que en este caso
pues estamos utilizando
la misma tecnología
de toda la arquitectura
pero
claro
sería lo más parecido
los iFriends
es esto
básicamente
yo me quedo con esto
con esta parte buena
de los micro fronters
esto de
poder tener
deploys independientes
esto la verdad
es que me gusta
pero no acabo de ver
esa complejidad
subyacente
que viene
incorporada
con el tema
de orquestación
es lo único
y también
como dice Carlos
me gustaría ver eso
implementado
en un caso de éxito
y que no suponga
algo demasiado complejo
de mantener
pues ahí tenemos a Jorge
que nos lo demostrará
en un ratito
Dani
últimas palabras
sobre los micro fronters
pues nada
que como todo
hay que ver
el caso de uso
que no es una bala de plata
que sirva para solucionar
todos los problemas
obviamente tiene
sus trade-offs
a nivel de complejidad
pero si está justificado
para dar autonomía
a los equipos
resolver cuellos de botella
y conseguir que tu organización
sea ágil
pues por qué no
al final la tecnología
tiene que estar al servicio
de todo esto
me gustaría recomendaros
que siguierais
a Luca Mezzalira
de The Zone
y que vierais esta charla
de Trulia
explicando cómo lo han implementado
con Shade, Now
y Next.js
porque os quitará
mucha mitología
que hay alrededor
de los micro fronters
sobre todo
por esta página
microfronters.org
que yo creo que está
llena de antipatterns
y esto es opinión
ha hecho mucho daño
no me parece
no, no sé si ha hecho mucho daño
pero sí que yo tenía
una idea
equivocada
inicial
y después de
escuchar a gente
que lo ha implementado
y lo ha puesto
con éxito en producción
pues puede llegar
a tener
bastante sentido
en muchas organizaciones
es micro-fronters.org
sí
esta es la que
os digo que miréis
con escepticidad
con cuidado
hay que mirarla con cuidado
porque es verdad
que yo también
es una de las primeras
que me leí
y creo que tiene ideas
no sé
lo enfoca
como lo que comentaba
diferentes tecnologías
diferentes
y me parece muy enrevesado
cuidado
ojo cuidado
pues con estas recomendaciones
de Dani
nos vamos a ir
ya
y
no
no
no
no
no
¡Suscríbete al canal!
¡Qué hambre hay! ¡Qué hambre hay!
Dejadme que salude a toda la gente que nos ha estado acompañando hoy aquí en YouTube, en directo.
Muchas gracias, chicos, por estar ahí.
Al otro lado, Adrián Rueda, Jorge Ezequiel, Joan D. Villamán, voy a ir a ver, Carlos Azaustre,
Adrián Durán, Antonio Jaén, que ha dicho, un chupito cuando digan la palabra interesante.
Esto me lo dice cada dos por tres, Dani, que yo siempre estoy diciendo, es súper interesante, muy interesante.
Yo hubo un programa que las llegué a contar. Cuando llevaba 40, dejé de contar.
¿Y no te tomaste un chupito por cada una?
No, no.
¿Qué más? Estaba aquí Jesús Olazagoitia. Yo creo que se pone esta gente en estos apellidos a posta, ¿no?
Para fastidiar.
Jesús, un saludo, que además lo conocí en la Frontfest, hizo una charla sobre Custom Properties, muy buena, me gustó muchísimo.
Cristian, Sam, hola, Miguel, Miguel, sin L, ese es andaluz, y todo el equipo.
Saúl Rodríguez, Diego Reimi y, guau, guau, creo que Yao Bansuita y Sergio Eric, que nos da saludos.
Y Adrián Rueda termina diciendo, gracias a vosotros, chavales, sois unos cracks.
Qué bonito. Es lo más bonito que me han dicho desde mucho tiempo, ¿eh?
Madre mía.
Lo dice por vosotros, ¿eh?
No, no, no. Lo dice por ti, hombre, lo dice por ti.
Pues nada, estos han sido los microfrontings, chicos. No sé si nos vamos a comer más tristes o más contentos.
Vamos a ver, una ronda rápida, Dani. ¿Cómo te vas? ¿Más triste o más contento?
Yo me voy igual.
Yo me voy con hambre, ¿no?
Tú te vas con hambre.
Carlos.
Un poquito triste.
Te vas un poco triste.
Te vas un poco triste. Muy tío, gris, taciturno.
Taciturno, David.
No, a mí me habéis...
No me habéis convencido del sistema de esto, pero sí que me habéis dado un nuevo punto de vista que yo no contemplaba,
por lo que tú comentabas esto de la página de microfrontings.org, que te deja bastante ñe.
Y dices, pero bueno, no.
Pero esto...
Además es un poquito feo.
Claro, es que esto no puede ir a ninguna parte.
¿Quién va a implementar esta cosa?
Pero luego, escuchas gente como Jorge, que tiene una aplicación súper chula, de verdad, que yo la recomiendo a la de Citibox porque, sobre todo, el servicio de atención al cliente es súper bueno porque, oye, tienes un chat, les dices, oye, tal, y actúan súper rápido.
O sea que...
Eso está hecho con microfrontings.
Exacto.
El chat.
Y yo digo, pues si esto está hecho con microfrontings, pues no puede ser tan malo.
O sea, y bueno, la verdad es que con todo lo que hemos comentado creo que está muy bien.
Muy bien, pues Dani, ¿dónde te pueden seguir? ¿En Twitter?
A mí en Twitter, ¿cómo era?
Dani Dev.
Dani Dev con un 4 en la A.
¿Un 4 en la A? ¿De verdad tú también?
Sí, sí, sí. Está de moda ahora.
¿En serio?
Sí, sí, sí.
Bueno, pues vamos a aprovechar con David porque ya como tú también tienes el mismo problema en el nombre, pues...
No es un problema, es una virtud, ¿eh? O sea, es Dave Carter cambiando a la primera A por un 4.
¿Pero por qué la segunda A no se cambió por un 4 y sigue la primera? Es que, ¿por qué? Eso me parece muy arbitrario.
Es que quiero decir, ¿en qué momento uno decide, no, vas a ir la primera porque la segunda no?
Te he respondido con mi silencio.
Sí, entiendo que no tienes respuesta a ello. Vale, pues la primera A con un 4, la segunda no,
porque la segunda considero que era oportuno que tuviese una A.
¿Carlos?
Pues nada, como siempre, en Carlos Villu, ahí estoy en Twitter, en YouTube y la A es una A y es latina, romana, normal...
¿Pero por qué tu A tiene que ser una A y por qué no puede ser un 4?
Como la de Dani, como la mía.
¿Una roba o...?
A ver, porque hay 10.000 millones de usuarios en Twitter y ya estaban todos los nombres cogidos, ya está.
¿Pero estaba cogido también el que tenía las dos A como 4?
Sí.
Vale.
Ah, lo está revisando ahora, pero suelta el móvil.
Bueno, y a mí me podéis seguir en mi DUDEF, en Twitter, en Instagram, en Facebook, en YouTube también.
Y de hecho, los que nos estéis escuchando por iVoox, por iTunes, por Spotify, por todos los sitios esos que tenemos,
que sepáis que lo podéis ver, podéis ver el vídeo como lo habíamos grabado, como estábamos aquí en directo.
Y a la próxima, pues que sepáis que también intentaremos ofrecerlo.
Así que nada, chicos, muchas gracias a todos y a todas por habernos escuchado y darle fuerte al fronte.
¡Gracias!
¡Gracias!
¡Gracias!
¡Gracias!
¡Gracias!