2

Our team is exploring microfrontends as part of the suite of applications we currently offer our clients. A few questions come to mind which I'd appreciate thoughts on:

I understand how a 'shell' or 'container' app can 'host' various 'remotes' which are self standing apps in themselves and, as such, be a 'suite' provider for end users. I see how webpack 5 facilitates module federation and what the value proposition is which is mostly around resource sharing and performance.

Where I do need more clarity on is 'federated' sharing of more granular componentry that do not stand on their own and always live within a larger app. There are at least TWO types of these components:

  1. DOM-bound components eg: dropboxes, panels, or more complex custom components like grids or charts.
  2. non DOM components like services, api packages, algo libraries, etc.

It's not clear to me how enabling federation for the mentioned granular components adds substanial value beyond best practices we have today such as shared libraries, npm packages, etc. The way it seems it's done is that these granular components live within larger dummy apps which in turn 'export' them as 'components' to the wider 'shell/container' thus becoming a 'shared' granular resource to sibling or client apps....

Given these granular components are inherently 'small' (10s or 100s of k) is it worthwhile to federate them (and a minor savings on resources) or just go with the conventional shared library approach and skip the labor required to setup and maintain them as federated artifacts?

Deep thoughts appreciated!

Christophe
  • 74,672
  • 10
  • 115
  • 187
MoMo
  • 121
  • 4

0 Answers0