4 ms·

In theory, yeah, but in practice the problem stems from product initiatives for new features that span those micro-front ends. Each team responsible for a part

In theory, yeah, but in practice the problem stems from product initiatives for new features that span those micro-front ends. Each team responsible for a particular front-end gets a set of stories: 'implement feature x so that the user can blah blah'. This feature requires using a design pattern that is not part of the core set. Each team, because of the silo'd nature of the article's model, must therefore implment it's own version of that pattern, each subtly or grossly different from the other, et voila, you have inconsistency across what to the user is supoosed to be a cohesive app. Sure, there are solutions for this, one of which is common ownership of that design system and having some kind of product coordination that allows for the contribution of new patterns to the design system in advance of the new feature, but that does require a lot of care in planning and coordination that negates a lot of the benefits of the this sort of model, imo.

shados 7y ago
Its not easy by any mean, but few things worth doing are. We have a team of engineers and designers working together to maintain our design system and its implementation, and all teams use it. When a new shared pattern comes up, its implemented in the design system and people use it. Teams are heavily encouraged to not make new patterns on their own from scratch (and its a lot easier to have the design system team handle it anyway). Sometimes folks go rogue, but that would happen within a large monolith too anyway.
- sillyquiet 7y ago
  > Its not easy by any mean, but few things worth doing are. We have a team of engineers and designers working together to maintain our design system and its implementation That would be a horizontal team which this model does not account for.
  - viklove 7y ago
    In fact, it specifically recommends avoiding that, which is why I think this article falls short.
    - shados 7y ago
      I can't read the mind of the article's author, but usually in these types of articles about micro-whatever you want to stress how horizontal teams/libraries/ownership is to be avoided, because people "default" to having them, and you have to fight tooth and nail to make them understand it shouldn't be. But for micro-FEs, there's a few things that, IMO, are unavoidable. A design system implementation (keeping its components as "dumb" as possible, no server api dependencies of any kind, no opinion about frameworks beyond the component technology it uses) is one of them. A few very very core things like authentication is another, as well as how all the routes glue together. There's a few more (nav, service workers, etc). It should still be avoided unless absolutely impossible to avoid or if the benefits are overwhelming.

shados 7y ago

Its not easy by any mean, but few things worth doing are. We have a team of engineers and designers working together to maintain our design system and its implementation, and all teams use it. When a new shared pattern comes up, its implemented in the design system and people use it. Teams are heavily encouraged to not make new patterns on their own from scratch (and its a lot easier to have the design system team handle it anyway). Sometimes folks go rogue, but that would happen within a large monolith too anyway.

sillyquiet 7y ago
> Its not easy by any mean, but few things worth doing are. We have a team of engineers and designers working together to maintain our design system and its implementation That would be a horizontal team which this model does not account for.
- viklove 7y ago
  In fact, it specifically recommends avoiding that, which is why I think this article falls short.
  - shados 7y ago
    I can't read the mind of the article's author, but usually in these types of articles about micro-whatever you want to stress how horizontal teams/libraries/ownership is to be avoided, because people "default" to having them, and you have to fight tooth and nail to make them understand it shouldn't be. But for micro-FEs, there's a few things that, IMO, are unavoidable. A design system implementation (keeping its components as "dumb" as possible, no server api dependencies of any kind, no opinion about frameworks beyond the component technology it uses) is one of them. A few very very core things like authentication is another, as well as how all the routes glue together. There's a few more (nav, service workers, etc). It should still be avoided unless absolutely impossible to avoid or if the benefits are overwhelming.