3 ms·

The goal of micro-frontends (different teams being able to deploy "their" parts of an application) is nice and all, but I still don't see how this is going to w

by Vinnl 6y ago

The goal of micro-frontends (different teams being able to deploy "their" parts of an application) is nice and all, but I still don't see how this is going to work when the shared modules release breaking changes. So now all those different teams that work on different parts of the same applications will still need to do one massively coordinated release in which they all migrate to the newer version at the same time, and a single team delaying things can put the work of all other teams on hold.

prerok 6y ago
Exactly this. But... from my limited experience: one team will just break things and then everyone just needs to correct their stuff as soon as they can because it's just not working anymore. Coordination takes time but has no place in the world of "move fast and break things". Could be just my limited experience, though.
gdsdfe 6y ago
I think some people are using feature flags for this
lhnz 6y ago
> I still don't see how this is going to work > when the shared modules release breaking changes The team I'm working on is currently working on such an application, and that problem is the one I've been worried about most. What do we do when there is a major version breaking-change upgrade of the shared design system? If you are working within a singular repository (monorepo), you can make a singular commit that fixes all parts of your application at once, and since it is deployed in one go there will be no breakage in production. On the other hand, if you have a shared library that affects multiple repositories, somehow everybody needs to do the PR at the same time, and somehow every deploy needs to be synchronised in order that all micro frontends are updated at the same time. How can that be done in a way which doesn't cause breakages? What if one team is slower to update than every other team? What crazy piece of infrastructure might we require for this kind of gradual distributed upgrade? This almost certainly sounds crazy to most engineers, but at the organisation I work they build quite a lot of App Store style applications which amalgamate 100s of other applications into one gigantic application. Additionally, for some legacy reason, we are tied into using separate repositories for each line-of-business micro frontend.
esperent 6y ago
Couldn't you version shared modules to avoid this?
- Vinnl 6y ago
  What do you mean by "versioning" them? If you mean running two different versions of the same library and putting them in different shared modules, then: maybe, that depends on the library. I'm quite sure that that's not possible with React, though, and I've experienced the same problem at a previous employer that insisted on using Polymer: Web Components have their own tag name (e.g. <google-maps>), and you can't run multiple versions of them at the same time because they'll both want to claim that tag.

by Vinnl 6y ago

prerok 6y ago

Exactly this. But... from my limited experience: one team will just break things and then everyone just needs to correct their stuff as soon as they can because it's just not working anymore. Coordination takes time but has no place in the world of "move fast and break things". Could be just my limited experience, though.

gdsdfe 6y ago

I think some people are using feature flags for this

lhnz 6y ago

> I still don't see how this is going to work > when the shared modules release breaking changes The team I'm working on is currently working on such an application, and that problem is the one I've been worried about most. What do we do when there is a major version breaking-change upgrade of the shared design system? If you are working within a singular repository (monorepo), you can make a singular commit that fixes all parts of your application at once, and since it is deployed in one go there will be no breakage in production. On the other hand, if you have a shared library that affects multiple repositories, somehow everybody needs to do the PR at the same time, and somehow every deploy needs to be synchronised in order that all micro frontends are updated at the same time. How can that be done in a way which doesn't cause breakages? What if one team is slower to update than every other team? What crazy piece of infrastructure might we require for this kind of gradual distributed upgrade? This almost certainly sounds crazy to most engineers, but at the organisation I work they build quite a lot of App Store style applications which amalgamate 100s of other applications into one gigantic application. Additionally, for some legacy reason, we are tied into using separate repositories for each line-of-business micro frontend.

esperent 6y ago

Couldn't you version shared modules to avoid this?

Vinnl 6y ago
What do you mean by "versioning" them? If you mean running two different versions of the same library and putting them in different shared modules, then: maybe, that depends on the library. I'm quite sure that that's not possible with React, though, and I've experienced the same problem at a previous employer that insisted on using Polymer: Web Components have their own tag name (e.g. <google-maps>), and you can't run multiple versions of them at the same time because they'll both want to claim that tag.