marcos-nunes-dev / Microfrontends-Boilerplate-Module-Federation

Complete module federation boilerplate | Cypress, jest, testing library, MUI 5, styled-components, Husky, Zustand and others.

Complete Module Federation Boilerplate

Cypress, jest, testing library, MUI 5, styled-components, Husky, Zustand and others.

IMPORTANT!

just use app1 as a template. app2 is in this repository for presentation purposes only. The Boilerplate and all its respective settings are only inside app1.

What is Module Federation?

It is basically a JavaScript architecture. It allows a JavaScript application to dynamically load code from another application (a different Webpack build).

Getting Start

Run the following commands in your terminal

yarn

To start the development:

yarn start

some others commands

yarn build //production webpack build
yarn serve //deploy to local dist folder
yarn lint //eslint
yarn checkTs //typecheck
yarn test // unit tests
yarn cy:open // opens cypress
yarn cy:test // e2e tests

Important Informations

• For each exposed remote we need to create a new .d.ts file with the given references like following the example:

app1\src\app1.d.ts

• For now, you should avoid use different peer dependencies versions (react, react-dom ...)
• To use Global state management it is recommended to use zustang for ease of communication in the micro frontends framework. You can follow the example in:

app1\src\contexts\demoContext.tsx

MUI Observations

• Global CSS are NOT shared inside the docs for example Roboto font from MUI
• Theme Provider will affect ONLY LOCAL APPLICATION. If you want to use the ThemeProvider to override elements CSS you need to use the HOC inside the component that are being exposed.

Important Files

relative Path	Description
app1\webpack.config.js	All entrypoint settings are within this file see the comments in the file for more information.
app1.cypress	cypress folder where the e2e test and local installation settings are located.
app1.husky	pre commit hooks
app1\src\config\routes.tsx	LOCAL route settings.
app1\src\contexts\demoContext.tsx	Zustang stores for context
app1\src\routes	File where app2's local and remote routes are merged.documentation
app1\src\styles\theme\index.ts	MUI style overwrite file
app1\src\templates\CommonProviders.tsx	If you want to use the MUI style override you must use this context within the exposed component so that the style is applied.

Support material

https://github.com/module-federation/module-federation-examples

Should I worry about exposing stores and traffic contexts between micro frontends?

First, Module Federation shares code, that's all. Not the state of the code, just the code. Think of it like NPM. Importing the mongodb module from NPM doesn't connect you to Mongo, you still have to run it.

There is no magic state sharing in Module Federation, to share state you have to use any of the traditional methods available to you in the web world (REST, Firebase, WebSockets, etc.) And doing that is entirely on you.

Second, Module Federation doesn't know anything about your code or how it's properly used. It shares code, that's it. If you import an Angular component into your React app and try and us it, it will blow up.

So, in the case of the state based security risk, it's not a problem because Module Federation isn't doing any state sharing. And Module Federation presents no more of a security risk than bundle splitting because it is just fancy bundle splitting.

As for the context question, if your React component require context you gotta give them context. Module Federation doesn't know anything about your code and isn't going to magically smooth over these requirements. It just shares code.

As for communication between MFEs, that's more of an architectural question. IMHO, you should share as little as you can between MFEs. Ideally just basic user identity and the JWT.