Hacker News Reader

Comment by sillyquiet | Hacker News Reader

This really only works if you have at least one team dedicated to maintaining cohesiveness in design patterns across all the 'micro frontends'(i.e., one of those verboten 'horizontals').

Otherwise you are going to end up with a ux experience or even a UI experience that diverges from app to app as each team designs and implements its own solution to common problems

View on HN

The rise of design systems, and how its pretty much a must these days regardless of your architecture, kinds of takes care of that. It does mean one of the "micro services challenges", code sharing, hits you from day 1. If one app wants to use Angular and another wants to use React, you now need two implementations of your design system from the get go, and that's likely to be your biggest, most complicated and most expensive to maintain library.

So you usually want to make a tradeoff right out of the gate and standardize the core stack around a specific core set of UI libraries/frameworks. It takes away from the benefits a little, but its worth it. If you grow to ultra large scale you can have multiple implementations (which I think many of the big techs do), but for most its a bad idea.

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.

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.

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

In fact, it specifically recommends avoiding that, which is why I think this article falls short.

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.

Design systems alone don't really solve for this. Design would need to look at the experience across the entire app.

A simplified example of how the UX can break down if frontend teams are too isolated is notifications. If every team triggers a bunch of their own notifications the user might be getting slammed with notifications.

Sure the pieces might look cohesive, but it might suck for the user if the teams aren't thinking about it from the perspective of a user.

There's always going to be shared services in any split system. Notifications is going to be one of these (kind of by necessity, especially if you plan on leveraging things like service workers which don't have a good "stacking" story to have multiple ones for the same path, so you want a shared one if you don't want every have to have one).

Reply on news.ycombinator.com