I am working on architecting a Flutter application using a micro-frontend approach, where the application is divided into independently deployable micro-frontends without relying on other micro-frontends.
Here is the folder structure I am considering:
App
- lib
- containers/
- micro_frontends/
- mf_feature_1/
- mf_feature_2/
- mf_feature_3/
- shared/
- design_system/
- utility/
Each mf_feature_*
will be an independent package created using the Flutter package template.
The containers/
folder will contain pages that combine multiple mf_features
.
The shared/
folder contains reusable components like the design_system
and utility
functions.
The challenge I am facing is implementing navigation/routing in this architecture. Each micro-frontend may have its own internal navigation, but they also need to navigate between other micro-frontends.
Here are the questions I have:
Should I create a common mf_navigation_router
package that all mf_feature_*
and the main app
depend on?
Would using a common router package tightly couple the
mf_feature_*
with the mf_navigation_router
package, and how can I avoid
this?
Is there a better way to handle navigation in a micro-frontend architecture?
Example: You have 3 modules - Main, Auth & Finance.
According to our conversation in the comment section, here is what we have done:
GetMaterialApp(
getPages: MainRoute.pages + AuthRoute.pages + FinanceRoute.pages,
)
class MainRoute { // AuthRoutes, FinanceRoute
static final pages = [
GetPage(
name: ...,
page: ...,
binding: ...,
children: [...],
),
GetPage(
name: ...,
page: ...,
binding: ...,
children: [...],
),
];
}
pubspec.yaml
main/pubspec.yaml:
dependencies:
auth_module:
path: ../../auth_module
finance_module:
git: https:// ...
Your auth_module
& finance_module
now look like other 3rd libraries/dependencies.
My project structure is little different from yours.
Main
- lib/
Shared
- design_system/
- utility/
Auth
- src/
- auth_module.dart // export files in src folder
Finance
- src/
- finance_module.dart // export files in src folder