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.
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!
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.
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!