DEV Community

Discussion on: 5 Reasons for Doing Microfrontends

Collapse
dbredvick profile image
drew.tech

I love the idea of micro frontends. The perks you mention are exactly why we were going to break up our FE at my last company.

Where do you decide to breakup monolith frontends though?

Let’s use an e-commerce site for an example, say Amazon.

I would break out:

  • user profile
  • checkout
  • content pages
  • navigation experience (CDP, PDP)
  • home page (maybe)

I have a hard time determining what is “too many” different front ends.

Collapse
florianrappl profile image
Florian Rappl Author

We usually break by feature, so the decomposition you've described seems valid.

Just note:

  • Content pages would potentially be just "content page", where the actual content comes from a headless CMS or other content delivery service
  • The navigation would not be a dedicated microfrontend but rather be distributed among all microfrontends (each one could decide what to deliver to the navigation); the mentioned product detail page would either be part of the "product experience" microfrontend or in its own (depending on the business context and team structure)
  • The home page would potentially be centralized, however, its content distributed like the navigation; e.g., the recommendation microfrontend team could provide a sneak peak of their best recommendations for you on the home page

While some features would certainly be contained in dedicated or even "stand alone" pages, many features would just be scattered and recomposed.

But that's just our take - any decomposition is valid if done with the right reasoning.