The micro-frontend chaos (and how to solve it)

[o-b-one]

Discussion for article "The micro-frontend chaos (and how to solve it) "

[ng-babyshark]

Thank you for this insightful article! This approach is great, however it couples the project from deployment perspective. Feed & Navigation apps use User's public API. If I will change the User app, even without touching the Facade, I will need to deploy also Feed & Navigation apps. Do you think is there a way how we can minimise the deploy coupling between apps by using same Anti-Coruptional Layer approach?

[o-b-one]

Thank you @ng-babyshark for your comment!

With regards to your question - As the Facade is only consumed via Module-Federation there is no coupling between the consumers and the application itself,, however in order to enforce the contract, the consumers must import the interface used by the Facade for type-check.
The interface must be considered as 3rd dependency, as if the interface is being changed we will must change (test, build and deploy) both the application implementing it and the applications that consume it.

Examples:

Semi-Anti-Corruption Layer:

1. Feed and Navigation applications using the User Facade via Module-Federation (no type is imported)
2. User Facade changed
3. As no interface is imported, there is no link between the apps, and dynamic or static tests are not running. this can lead to a case where Feed and/or Navigation will be affected without notice

Anti-Corruption Layer - Only User deployed:

1. Feed and Navigation applications using the User Facade via Module-Federation
2. Type of UserFacade interface is imported from "@user/types" library which is used by User, Feed and Navigation
3. User Facade changed with no interface change
4. As the interface remains the same, with no risk for the consumers, tests will be run for the User application only and require the deployment of the User application only.

Anti-Corruption Layer - User + Consumers deployed:

1. Feed and Navigation applications using the User Facade via Module-Federation
2. Type of UserFacade interface is imported from "@user/types" library which is used by User, Feed and Navigation
3. User Facade changed with no interface change
4. As the interface changed, we must verify the consumers are ok with the interface change (usually will hint for breaking change). In that case, we will trigger - build, test and deploy any application that is a consumer of the @user/types - meaning implementing or using the facade interface