2024-03-28 Frontend Working Group Meeting Notes: Piral vs Webpack Module Federation

 Date, time, location

 Discussion topic(s)

One, maybe two topics to be presented or discussed in depth in the upcoming meeting.

@David Joy - Module Federation

  • Piral vs Webpack Module Federation

    • Might be beneficial to go “a step down” and directly use module federation instead of adding another framework/library (Piral)

🎥Recording

Please be advised: Frontend Working Group meetings are recorded and transcribed.

 Participants

  • @Brian Smith

  • @Chintan Joshi

  • @David Joy

  • @Fox Piacenti

  • @Hina Khadim

🤖 Summary

A summary of the meeting, generated from the transcript by ChatGPT4.

The Frontend Working Group Meeting focused on discussing the potential adoption of Webpack Module Federation for front-end composability, moving away from Piral or other frameworks. Here's a summary of the key points discussed:

  1. Introduction to Module Federation:

    • David Joy shared insights on exploring Webpack Module Federation as a direct, less invasive approach for front-end composability, contrasting it with adopting another layer like Piral on top of existing frameworks. The goal is to achieve similar benefits but with a simpler and more direct method.

  2. Demonstration and Technical Details:

    • David provided a live demo showing how an MFE (Micro-Frontend) can load content from another MFE at runtime using Module Federation, without iframes, highlighting the ease of integrating CSS and ensuring a seamless user experience. He showcased the minimal webpack configuration needed and discussed the potential for incremental adoption by exposing specific components for module federation.

  3. Benefits of Module Federation:

    • Simplified architecture: The approach allows for a significant reduction in code and complexity compared to Piral, focusing on leveraging webpack's capabilities.

    • Decoupling and Independence: MFEs can be developed and operated independently without tight coupling to a shell application, enhancing modularity and flexibility.

    • Incremental Adoption: The method supports gradual integration, allowing parts of an application to be migrated without a complete overhaul.

  4. Considerations and Challenges:

    • Authentication and Config Management: Discussions highlighted the need to ensure authentication and runtime config management work seamlessly within this architecture, considering how front-end platform libraries could be shared or independently managed across MFEs.

    • Development Workflow: Considerations on how development workflows might change, particularly around hot module reloading and maintaining independence between the shell and MFEs during development.

  5. Next Steps:

    • Further Exploration: The group discussed the need for more in-depth proof of concepts to explore how existing MFEs could be integrated within a shell using Module Federation, specifically looking into authentication, configuration, and other technical challenges.

    • Community Engagement: There was a conversation about staying more closely connected with the broader JavaScript and front-end development community to ensure alignment with industry standards and practices.

  6. Feedback and Concerns:

    • The group expressed interest in the simplified approach but also noted the importance of identifying potential pitfalls and ensuring that the adoption of Module Federation would not lead to significant rewrites or over-complication of existing infrastructure.

In conclusion, the meeting was productive in introducing and discussing the potential of Webpack Module Federation for improving front-end composability. The attendees agreed on the need for further exploration and testing to understand the full implications and technical details of adopting this approach.

 Action items

 Decisions