SPAs enable teams to use components deliver engaging UX, business features, and associated business logic as a self-contained solution for modern web apps. Even with client-side view routing and on-demand loading these SPAs are build-time solutions. These solutions often are deployed as full-page immersive experiences.
1) MFEs
Within the last couple of years ideas have emerged to deploy these SPAs as widgets or micro-experiences. The approach is to then allow a host page to compose multiple SPAs within custom layouts on a full-page.
I think using micro-experiences published as independent SPAs is a flawed solution. Yes the Single-SPA is rather creative for providing client-side routing AND even limited container layout.
That solution does not address however the issues of
how do we handle version-incompatibility issues
For example, what if two different SPAs are loaded using the same framework; but each requires DIFFERENT versions of the framework or libraries?
how do we constrain 1 MFE from routing the entire full-page experience
how do we choreograph animations and transitions across MFEs
how do we ensure consistent theme?
how do we prevent CSS bleeds or overrides across MFEs within the same browser window layout?
how do the SPAs communicate easily with each other? Shared data or global services?
how is authentication supported?
These are hard questions that must be addressed when thinking that MFEs solve the problems with multiple teams working in parallel or with different technologies.
2) Component-based SPA Development
Another approach is something that @bitdev_ (bit.dev) is working on: allowing MFEs to be published as components. And then allowing those MFE components to be composed and development time and build/deployed as a single SPA.
This is another interesting approach that has IMO many of the challenges enumerated above.
3) Component development
If developers use an Nx workspace, then React, Vue, Angular, and NextJS solutions can be created using shared business logic and services (implemented in TypeScript). While the views are not shareable, the business and data services are shared. Architected properly this is actually 70%-80% of an apps core code IMO.
Thanks for the detailed explanation! I agree, I faced the problems you listed and as you said Single-SPA does not provide a set of solutions for them. So I had to find and gather solutions.
I used shared modules for authentication, communication between apps and business logic, same as you proposed, sharing data services. Having shared modules is the best whether you use components or even MFEs.
As the website was developed by one team, it was easy to have no style overrides and styles were encapsulated by Angular's shadow DOM and React's CSS modules. Also for each app, Webpack can be configured to use the externally available SystemJS (or ES) module or bundle the module. So if two apps are dependent on two different versions of a module, there is no issue apart from the bundle being fat. They each bundle their own version. If they use the same version, they can both use the externally shared module. Anyway it is recommended to use the same version.
I do agree that agreeing on the above solutions and communicating the decisions and conventions may be hard for larger teams, but it was not a problem for us.
About the third solution, component development, yes I think I could go that way and it may be cleaner in many ways, especially using nice tools like Nx. Things could be designed cleaner if we were doing it from scratch. But I am not sure how the development setup would be like using component development (3rd). We were able to only run a single app locally, and override the import-maps using the Single-SPA extension to make the live website to connect to the local app using all the React dev features like hot reloads, which our original AngularJS app did not have. New developers did not need to even build or run the whole website or know how it works. Using components I cannot imagine how to do that, I need to dig deeper in Nx and monorepos. to find out. Also using shared logic and data services (70%-80% of the code) can be achieved using MFEs too, by sharing modules.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
SPAs enable teams to use components deliver engaging UX, business features, and associated business logic as a self-contained solution for modern web apps. Even with client-side view routing and on-demand loading these SPAs are build-time solutions. These solutions often are deployed as full-page immersive experiences.
1) MFEs
Within the last couple of years ideas have emerged to deploy these SPAs as widgets or micro-experiences. The approach is to then allow a host page to compose multiple SPAs within custom layouts on a full-page.
I think using micro-experiences published as independent SPAs is a flawed solution. Yes the Single-SPA is rather creative for providing client-side routing AND even limited container layout.
That solution does not address however the issues of
These are hard questions that must be addressed when thinking that MFEs solve the problems with multiple teams working in parallel or with different technologies.
2) Component-based SPA Development
Another approach is something that @bitdev_ (bit.dev) is working on: allowing MFEs to be published as components. And then allowing those MFE components to be composed and development time and build/deployed as a single SPA.
This is another interesting approach that has IMO many of the challenges enumerated above.
3) Component development
If developers use an Nx workspace, then React, Vue, Angular, and NextJS solutions can be created using shared business logic and services (implemented in TypeScript). While the views are not shareable, the business and data services are shared. Architected properly this is actually 70%-80% of an apps core code IMO.
Thanks for the detailed explanation! I agree, I faced the problems you listed and as you said Single-SPA does not provide a set of solutions for them. So I had to find and gather solutions.
I used shared modules for authentication, communication between apps and business logic, same as you proposed, sharing data services. Having shared modules is the best whether you use components or even MFEs.
As the website was developed by one team, it was easy to have no style overrides and styles were encapsulated by Angular's shadow DOM and React's CSS modules. Also for each app, Webpack can be configured to use the externally available SystemJS (or ES) module or bundle the module. So if two apps are dependent on two different versions of a module, there is no issue apart from the bundle being fat. They each bundle their own version. If they use the same version, they can both use the externally shared module. Anyway it is recommended to use the same version.
I do agree that agreeing on the above solutions and communicating the decisions and conventions may be hard for larger teams, but it was not a problem for us.
About the third solution, component development, yes I think I could go that way and it may be cleaner in many ways, especially using nice tools like Nx. Things could be designed cleaner if we were doing it from scratch. But I am not sure how the development setup would be like using component development (3rd). We were able to only run a single app locally, and override the import-maps using the Single-SPA extension to make the live website to connect to the local app using all the React dev features like hot reloads, which our original AngularJS app did not have. New developers did not need to even build or run the whole website or know how it works. Using components I cannot imagine how to do that, I need to dig deeper in Nx and monorepos. to find out. Also using shared logic and data services (70%-80% of the code) can be achieved using MFEs too, by sharing modules.