Micro frontend architecture advice

Question

We have several web applications that we wish to present under one single page application. We are looking for a micro-frontend architecture/framework to use. As we see it, these are our options for implementation:

1. Using the single-spa open source framework: https://github.com/CanopyTax/single-spa
2. Using Iframes (friendly Iframes) the hosting application (the shell) and loading each application according to the current url.
3. Writing our own Javascript framework
4. Other?

The current state is a monolith FE application that consumes the other child-application as internal 3rd party packages. This approach is not scalable for us, because the hosting application is building all the products together, and nothing is really separated.

Our requirements are the usual requirements for micro-frontend:

1. Independent development - Each team can choose their own frameworks and build their products regardless the other products.

2. Independent deployment - Each application can be upgraded in production without downtime and without interfering the other applications.

3. Shared components - We're using Angular4 in our applications, and we have a proprietary 3rd party library (shared components and logic) that we've already wrote that should be shared among all of the products for similar look and feel.

4. We would like to have the ability to upgrade each application's framework (Angular, RXjs, Typescript etc and also for our proprietary component library) without caring about the other applications.

We tried to use the single-spa framework but we have some issues and we are currently found our-self thinking if this is the right approach for us, or should we try a different approach.

The issues we have using the single-spa are:

1. Assets loading is problematic. (We must have the assets files on the root folder of the hosting application, and we suffer from assets conflicts when switching to another application).
2. We still don't know how to handle global styling for all applications (We use sass for styling and it must be complied together with the local styles for each application)
3. Upgrade angular framework (or all other frameworks) is not possible for one application, it's all or nothing (since we have one instance of angular).
4. We have to implement a different bundling for development other side the hosting application (the shell).

When we think about the Iframe (using friendly Iframe) solution, we visualize a full separation between all child-application, and tend to believe this is a more suitable approach for us.

Are there any pitfalls for using Iframes?

Answer 1

I would like to add my 2¢ to the topic of possible architectural solutions for frontend's microservices:

1. OpenComponents used by OpenTable – https://github.com/opentable/oc
2. Mosaic by Zalando – https://www.mosaic9.org/

Hope you find them useful.

Answer 2

Since your question is somewhat broad, I will only address your inquiries about the usage of Iframes, since advising you on architecture is pointless, without knowing the circumstances (target group?, mobile?, what are the KPIs? (performance, initial load, development costs, re-usability, ...)

Iframes are good for "total" isolation (code + style), no other approach will give you this, however because of this, they have a lot of drawbacks:

• sharing data between iframes needs orchestration in the outer AND the inner SPAs, that involves setting up additional security measures (because each SPAs is exposed)
• styling your inner SPAs by the outer one, will only work, when they are on the same domain and needs additional JS code
• sharing cookies only works, if the inner SPAs are on the same domain as the outer SPAs
• performance-wise each Iframe needs to load everything by itself; re-using assets, libraries etc. is very difficult and involves meddling with the tooling of each SPA.

Usually, if you have everything under your control going with a real micro frontend approach is the better solution than Iframes.

Answer 3

You might try PuzzleJs. It is designed to be framework solution to micro frontends architecture for both gateway and storefront. It is being used on production of our high traffic e-commerce website. You should really check it out.

It actually covers almost all of your requirements.

• Independent Deployments
• Independent Source Code
• Independent Technologies

---

And about the iframe solution, it might get hard to manage things like CORS and communication with other iframes.

---

But micro frontends solution is not still perfect. There are lots of complexities when you really dive deep into it.

Some assets will try to declare same variable in global scope and sometimes they will have different versions that will cause error. So teams won't be fully independent from each other.

Logging and monitoring gets extreme hard. Tools like New Relic will help you but it won't be enough. You should implement custom monitoring and error reporting tools.

Keeping applications dockerized and auto-scale friendly is really important. With this architecture if you have 4 gateways and a storefront it can be tricky.

Initial cost of implementing micro-frontends architecture is quite high. You should consider your time and developer resource carefully

Performance is the most important thing. You don't want to download react or other libraries for more than one time because multiple teams are using them. You should implement DllPluginn to remove duplicated codes. And it will make everything harder.

And there are lots of other problems that I couldn't remember. If you don't have more than 50 developers working on same storefront project, micro front-ends is an overkill decision.