One of the most common questions about micro frontends is how to let them talk to each other. In general, the recommendation is to have them communicate as little as possible, as it often reintroduces the sort of inappropriate coupling that micro frontends were meant to avoid in the first place.
Functional tests should only cover aspects that cannot be tested at a lower level of the test pyramid. By that I mean: use unit tests to cover your low-level business logic and rendering logic, and then use functional tests just to validate that the page is assembled correctly. Cross-application communication should be kept to a minimum.
Lockstep release process
After going through all the trouble of dividing our application into discrete codebases that can be developed and tested independently, let’s not re-introduce all of that coupling at the release stage. We should find a way to integrate our micro frontends at runtime, rather than at build time.
Performance impact
Every application has its own unique performance characteristics. If you want to know for sure what the performance impacts will be of a particular change, there is no substitute for taking real-world measurements, ideally in production. Teams often agonise over a few extra kilobytes of JavaScript, only to download many megabytes of high-resolution images, or run expensive queries against a very slow database. So while it’s important to consider the performance impacts of every architectural decision, be sure that you know where the real bottlenecks are.