In recent years the term "microfrontends" entered the tech mainstream. While there are many patterns of actually implementing microfrontends we fee...
For further actions, you may consider blocking this person and/or reporting abuse
Since a premise of microservices is independent deployment, how does Piral enforce independent deployments if it allows the use of shared libraries?
For instance, if Pilet A and Pilet B want to use the same shared library but Pilet A wants a newer version... is Pilet B going to get the version it wants or the version that Pilet A requested?
Thanks for the question - it's a good and reasonable one.
For shared libraries there are two possibilities:
Use the one provided from the application shell. This gives the best performance, is most convenient and is done already with core dependencies such as React. However, this puts the burden of correct dependency management on the app shell. As a consequence updating may be difficult (tooling helps here).
If pilets want more freedom, but still the gain of flexibility the other choice is sharing from the pilets by using a script import and a shared URL. Long story short - if two pilets use a script import from the same URL, the URL will only be used once. So if one pilet goes for a different version we'll have no problem.
If a pilet really wants to be independent dependencies can always be bundled in (shouldn't be done for the already provided core dependencies, but for "new" dependencies it makes sense). Our recommendation is to use this, and once recognized as being used by multiple pilets a central team can always think about aligning such a dependency. "Depends" as usual, e.g., on performance (size) and other (e.g., consistency, coupling, ...) factors.
Hope that helps!
Thanks. Have you or your team looked into the import map spec as a way to make this dependency management easier?
I ask because your competitor (single-spa), has made a lot of advancements with using import maps to enable teams to control their dependencies. It’s fascinating stuff, but I must admit that it’s a bit above my head! Haha.
I think import maps (this one, wicg.github.io/import-maps/, right?) is a promising approach. Right now we rely on
import()(yielding a promise), but maybe we can also support it in the future as an alternative.Thanks for the hint!
Wasn't this exactly what react was meant to be used like?
Excellent read! 🔥
Microfrontends architecture is the stupidest idea nowadays. I think it was invented by API developers who really know nothing about frontend optimizations. In real world most of the modules will be not independent - over the time number of dependencies between modules will increase (with internal deps such as NPM packages). That architecture leads to creating sluggish and huge unmaintable apps. Besides it - what about SSR and page loading time optimization?
Its a valid opinion and the architecture is certainly not for everyone. Besides if you would have read the article (and presumably not stop the the title) you would have seen that we share all the major building blocks (for exactly the reason as you outlined).
For the clients where we rolled out the solution everyone seems to be super happy about it. I've also never seen two modules that collide with each other.
SSR is possible due to React, but page loading time can (as usual) be an issue. Here it really depends what you are after; if you create a tool (this is the target audience) the initial loading time is not as crucial as for creating a fast content page.
It's not all black and white.
Maybe I haven't had a need for this yet, but would you mind explaining the benefit of this approach?
Of what approach? Microfrontends? Or a particular pattern?
dev.to/florianrappl/5-reasons-for-...
Micro-frontends using a React App. I guess I'm just not able to see how it helps individual teams working on different features. I'll give your article a read and see if I'm still confused.
Well, for a single team working on multiple features it does not necessarily help. Why should it (note: this is not a silver bullet)?
It helps, e.g., when
... and many more cases (see the reasons / article I've linked).
Hope that helps!