La mejor explicación que veo sobre el tema, me despejó muchas dudas, felicitaciones!!!

Excelente video, los felicito. Muy util

Muchas gracias por compartir esta información, son uno de los pocos videos en español acerca de microfrontend. ¿Van a seguir esta serie de videos? Estaría genial.

Excelente charla, muchas gracias!

Muy buena charla!. Gracias por la información

Consideró que la opción más desacoplada es por medio del los s te deja combinar tecnologías que no se pueden con webpack. Buen video !!!

Disculpen si tardo en responder es que como el canal es de la empresa no me llegan las notificaciones a mi cuenta. Yo soy el que dió la charla

@darioravello2221

2 жыл бұрын

Una consulta, tema seguridad como lo manejan? con JWT y lo guardan en un modulo compartido?

@mauromosconi554

2 жыл бұрын

@@darioravello2221 si se suele utilizar un módulo compartido para lo referido a seguridad, token y http seguro

Primeramente, gracias por el vídeo, excelente. Les comparto mi experiencia con algo parecido a microfrontend: En la empresa en la que trabajo tenemos un monolito, decidimos rehacer con vue y spa+ rest la web por módulos de negocio. No sabíamos nada de microfrontend cuando empezamos, ni se hablaba de esto. Creamos el repo de vue y utilizamos un proxy de nginx para redirigir ciertas rutas de la web al proyecto vue. Funciona perfectamente y manejamos temas de autenticación logueando en el monolito, generando el token y almacenandolo en una cookie, si entras a cualquier página de vue puedes leer la cookie con el token ya que son del mismo dominio. La "consideración" y diferencia con microservicio creo que es la imposibilidad de unir partes de ambos proyectos en la misma vista. Pero tampoco es un proyecto tan grande. Es un proyecto de modernización por llamarle de alguna manera. Saludos. Una pregunta tengo: como se manejan los enritadores de cada proyecto, por ej: /productos iría a la raíz del proyecto de productos? /?

@mauromosconi554

Жыл бұрын

Hola roger, gracias por el comentario, En mis primeros pasos en micro frontend tuve la misma experiencia que vos, nosotros llamabamos a eso micro sitios. O sea teniamos diferentes proyectos que el nginx respondia a los diferentes paths y devolvia un sitio distonto, pero como el header y el footer y navbar eran iguales parecia el mismo sitio, por lo tanto le llamabamos micro sitios. En el caso de micro frontend con single-spa, el contenedor es el que va renderizando los diferentes micro frontend pero dentro del mismo sitio. En respuesta a lo de los enrutadores, en caso de micro frontend, la prier toma de desicion la toma el conenedor activando un micro front dependiendo del router, despues cada micro front tiene su manejo de router, o sea si tu micro front es react utilizara react-router o si es angular ng-route o cual fuere en tu micro frotn, pero el primero que analiza la ruta es el contenedor para poder activar un micro frontend. Aca te dejo la docu single-spa.js.org/docs/configuration. Gracias por el comentario

@tusbackingtrackes

Жыл бұрын

@@mauromosconi554 Gracias por tu respuesta amigo. Estuve probando single SPA y veo que no sustituye esa forma de trabajar que te comentaba antes. No sé si sabes alguna forma de integrar, ademas de SPA, proyectos php u otros legacy. Por el momento es un contra que veo, se que puede ser a mi ignorancia en cuanto a esta tecnología. Saludos.

@mauromosconi554

Жыл бұрын

@@tusbackingtrackes correspondiente a sistemas legacys, yo recomendaría ir migrandolos de a poco o sea, ir haciéndolo como lo planteas pero de a poco ir pasando a single-spa. No sé si con module federation o con web component podrías hacer algo, pero el trabajo es demasiado artesanal. Correspondiente al tema de "unir partes de ambos proyectos en la misma vista" va a depender de como gestiones el container y de tu diseño. Single-spa te permite crear una librería de componentes que se toma como un micro frontend que puede ser accedida desde cualquier micro frontend. Ahora bien recordá que si estás compartiendo estado entre micro frontend o funcionalidad, ya es un tema de diseño que se debería de revisar. Espero haber respondido tu pregunta

Hola podrias compartir la presentacion o diapositiva que usaste en este video

Hola me gustaria aprender más. Por favor podemos hacer una videollamada?

Buena charla. Tengo una duda, que pasa si se necesita reutilizar algun componente que se tiene que ver en cada microfrontend?

@AndresLobaton

3 жыл бұрын

buena pregunta

@willydavid_

3 жыл бұрын

Allí seria una desventaja porque son apps distintas.

@mauromosconi554

3 жыл бұрын

Dependiendo de cómo lo implementes, con single-spa que es un framework para micro frontend, podés armar una librería de componentes, que está desplegada como un micro front end pero es un modulo,y utilizarla en todos los micro front end, también se pueden hacer módulos con funciones para compartir métodos cómo acceso a tokens, seguridad etc. Todo depende de cómo lo implementes.

@ZOEXXI

Жыл бұрын

@@mauromosconi554 Esta es la opción que yo barajaría. Un core donde tienes esos componentes y/o servicios comunes. Good one!!!

@mauromosconi554

Жыл бұрын

@@ZOEXXI si exactamente. Igual como mencione anteriormente, hay frameworks que solucionan esos inconvenientes. Los componentes es recomendable mediante una libreria. Pero el resto, como decis vos es recomendable a travez de un core o bff (backend for front end). Lo unico que se suele hacer con funciones compartidas es el tema de la parte del jwt y los llamados http con el mismo header

Y como se haría para comunicar estos micro frontend osea crear variables globales que se pudiera acceder a cada micro frontend

@mauromosconi554

2 жыл бұрын

Dependiendo de cómo lo implementes, la idea de la arquitectura de micro front end son módulos desacoplados, si estás compartiendo mucha información, tendrías que revisar el diseño. Igual hay implementaciones cómo single-spa que soluciona este tipo de inconveniente mediante módulos dónde se comparten funciones y variables. Pero todo va a depender de tu diseño de arquitectura y de cómo lo implementes. Siempre es recomendable separar los micro front en módulos lo más desacoplado posible

@victorhuayhuapuma1505

2 жыл бұрын

@@mauromosconi554 si entiendo y otra cosa no soy muy bueno en backend pero esas variables globales la podría hacer el lenguaje de servidor ósea el backend serviría como puente entre los microfrontend

@mauromosconi554

2 жыл бұрын

Si, también podrías utilizar los back de los fronts, todo depende de la arquitectura en generar que tenés diseñada, si tenés backs por front(bff) es una muy buena alternativa. Cómo te comente anteriormente va a depender mucho de la arquitectura general de tu aplicación y del diseño de la misma

Tengo una duda respecto a las dependencias, si por ejemplo uso angular material, lo tengo que instalar en todos los micro front pero hay problemas de versionamiento? Ejemplo mf 1 tiene material v11 y mf2 tiene material v13? Y hay forma de no tener que instalar dependencias en que cada mf, sino que el padre sea el único que lo contenga? Al menos al momento del deploy? Saludos.

@mauromosconi554

Жыл бұрын

Correspondiente a los casos de librerías de componentes, es recomendable el uso de una librería como micro fronted, o sea se levanta la librería y se importa en tiempo de ejecución. Con single-spa hay varios ejemplos. Siempre que se necesite compartir algo se hacen librerías o módulos compartidos para no repetir codigo y para no tener problemas de versiones

@mauromosconi554

Жыл бұрын

Por eso recomiendo single-spa ya que facilita mucho este tipo de inconvenientes