Comments (3)
There is no one size fits all solution and assembling all of these parts can happen on a spectrum of choices.
Thats definitely the case. We've used different approaches. My current favourite one is to choose a tech-stack where the vendor library overhead is so small that it becomes a non-issue. Hyperapp, Svelte, Preact or Stencil are good candidates (I've talked about this here).
In this case you don't need any inter-team contracts at all and the frontends can be self-contained.
If you need/want to go with a "heavier" solution you can serve specific vendor assets from a central place. But always implement it in a way that teams can upgrade independently so you aren't forced to to synchronouse deployments as @dennisreimann said earlier. When all teams reference e.g. the latest react the associated vendor bundle is only loaded once. When a new version comes out teams can upgrade on their own speed. For this upgrade period the old and the new bundles are downloaded.
Implementing this requires the vendor bundle to be scoped/namespaced. We've implemented this using Webpacks DDL feature. Publicly served the DLL artefacts and distributed the associated manifest files via an NPM package to the teams. But this requires all teams to use Webpack, which might be an ok compromise.
A nicer and more standards compliant approach is using import-maps
. Currently they are not implemented in all browsers, but they will. @trygve-lie wrote a good summary on how to use them in a micro frontends context. The single-spa FAQ also recommends the import-maps way.
from micro-frontends.
@SassNinja great question! Currently we are also researching "micro frontends" and we've raised similar question internally. One solution what we will try is to mark React as external dependency in Production and require dependency in Development, so the idea is to use React "interfaces" / "contracts".
from micro-frontends.
One solution what we will try is to mark React as external dependency in Production and require dependency in Development, so the idea is to use React "interfaces" / "contracts".
As long as you know what you are doing and are aware of the trade-offs, that is a valid approach to achieve this. Trade-offs here are that teams aren't really independent anymore and loose the ability to upgrade without coordination (i.e. synchronuous deployment).
Citing the website:
Donβt share a runtime, even if all teams use the same framework
This also has it's trade-ofss, as @SassNinja layed out this comes with performance costs, as bundle content will most likely contain duplication. Nevertheless, these trade-offs are considered and weigh less than the benefit of having independent teams that can ship and deploy whatever/whenever they want.
There is no one size fits all solution and assembling all of these parts can happen on a spectrum of choices. That's why it's more important to know the pros and cons of each approach, than to cast in stone the one valid micro-frontends approach.
from micro-frontends.
Related Issues (20)
- Top-level routing HOT 8
- Nodemon HOT 1
- Apply for translation HOT 7
- Server Side Rendering HOT 1
- Can we achieve this with angular elements HOT 1
- Micro-frontends as an advantage to using web components with a headlessCMS
- Team Blue Missing! HOT 1
- Thanks about micro-frontends concept. HOT 1
- Any ETA for navigation reference? HOT 4
- micro frontend
- Added Portuguese Translation HOT 1
- Added Korean Translation HOT 3
- Misleading diagram wrt frameworks HOT 2
- Why did you start to call component architecture as "microfrontends"? HOT 5
- How to have error handling mechanism in microfrontends? HOT 1
- Universal Composition: Render Call Question HOT 2
- Integrate micro frontend from different repo? HOT 1
- Can we create composite app with React and Jinja Template together?
- Added Polish translation HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from micro-frontends.