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

This topic is pretty old, but still, maybe someone will find it interesting to read the answer later because it's still a very good topic.

This package you've posted in your question - https://github.com/single-spa/single-spa looks very good and we tried to work with it, however, it has too many framework-specific things, that makes onboarding for new engineers super difficult.

I think first you need to choose the approach for the microfrontend composition of your application:

• Build-time composition
• Server-side composition
• Client-side composition
• Route composition

I've tried to describe them with some useful links in the article https://medium.com/@danielostapenko/frontend-architecture-in-scale-for-large-organizations-593930ed10cd

Also, I would really encourage you to look at the Module Federation feature provided by Webpack 5. It looks super promising and comfortable to work within the micro-frontends world.

Answer 2

We have currently worked on exact same thing with single-spa framework. And we have come to same conclusions as you have. One major issue for us was translations for a child app, since at least we could not figure out a way to bundle them to the child app. Other assets like styles are an issue as well.

My suggestion would be to wait for angular elements since the framework is not designed to be used in micro frontend style.

Answer 3

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 4

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.

Answer 5

I believe my answer on this thread would be resourceful. However to clarify further

1. Given that the main application is deployed to www.example.com, each sub-application has to inherit the global styling by forcing an import, i.e

   @import url('https://www.example.com/path/to/global/style.css');
   

2. With web components, styling of individual sub-applications are not transferable. Likewise, inheriting style from the base application has to be forced as demonstrated above.
3. Since each sub-application can be built independently, it makes it language agnostic. One app might choose to use Vue and another uses Polymer.
4. Using web components is similar to using iframes except that it's lighter and is designed to be attached.

Hope it helps

Answer 6

You can expose web components from each of your application and aggregate/use them in your main SPA. Web Components are getting supported by all browsers as well as all leading SAP farmeworks (like angular, ember, react, vue) supports webcomponent. This way you are not bind to any sepcific SPA framework and can resue the components anywhere.

Answer 7

You can look at ShadowDom v1.1 as an alternative to Iframe. I recently work & deploy banking app using this technique to isolate the styling of parent app (which is a stateful application with jsp server-side template) But this only give you styling isolation.

It's better to have different code base for each child application. That way, you can develop them independently, migrate to different Angular version, and deploy seperately. Shared component & proprietary 3rd party library can be published as node_module where you can import it into each child applications. (I imagine that you should have private/internal artifactory respository setup)

Inter communication between child app can be done with localStorate/sessionStorage. You can further wrap them up as a shared service & again publish as node_module dependency.

** Setup

yourcompany.com --> parent app

yourcompany.com/app1.html --> child app 1 - bootstrap application with bundled js files & css yourcompany.com/app2.php --> child app 2 - bootstrap application with bundled js files & css yourcompany.com/app3.jsp --> child app 3 - bootstrap application with bundled js files & css

** or using sub domain

yourcompany.com --> parent app

app.yourcompany.com --> child app 1

blog.yourcompany.com --> child app 2

home.yourcompany.com --> child app 3