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.
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? /?
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
@@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.
@@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
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.
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
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 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
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
@@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
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
