There is no strict rule about Architecture

The architecture for each project is determined by its requirements.

We must think about the requirements to pick the architecture will work for us.

With the project I currently working on, there are some unflexible requirements.

1) ZERO Coupling between Child Projects

👉 NO import of functions/objects / classes / etc

👉 NO Shared State

👉 Shared libraries through MF is OK

2) NEAR ZERO coupling between CONTAINER and CHILD APPS

👉 CONTAINER shouldn't assume that a CHILD is Using a PARTICULAR framework. Try to be genetic as much as possible.

👉 Any necessary Communication is done with callbacks or Simple Events.

3) CSS from one project shouldn't affect another.

4) VERSION CONTROL (monorepo vs Separate REPOS) shoudn't have any impact on the overall project

5) Container should be ABLE to decide to ALWAYS use the LATEST version of a micro Frontend or specify a Specific version

👉 Container will ALWAYS use the LATEST version of a CHILD app (does not require a Re-deploy of Container)

👉 Container can SPECIFY EXACTLY WHAT VERSION of a child it wants to use (requires a re-deploy to change)

---

Things to keep in mind

When we try to link multiple micro Frontend apps together (integration).

Specifically, during the integration process of child apps (REMOTE) into the Container (HOST).

We shouldn't assume that the child apps are using a particular framework.

Instead, we want to make the "coupling" between the HOST and the REMOTES as GENETIC and as SIMPLE as possible.

As much as you can, try to avoid Coupling Software together.

The more you can isolate your different applications, the better off you're gonna be in some number of years.

It might sound cliché when we just need to work with small pieces of software.

However, this architecture choice can have a massive impact on large-scale software.