[FlorianRappl]

Personally, I wouldn't call it a "last resort", but I definitely agree that keeping a functioning monolith is preferred.

Nevertheless, one thing to keep in mind (and I do consulting on MF for the last 5 years) is that most projects / teams are not well prepared and actually not at all suited for MF. MF solutions are usually just done from a technology POV, which is already a problem. Next thing is that the used technologies are often also not well suited. People tend to use strongly coupled things that just create hidden monoliths. In the end projects fail often because either the organization is not ready to have truly independent teams or / and because the software has just become too complex and unmaintainable.

To end with something positive: We also know many success stories in that area where people spent the right amount of research on what technologies to use and where everyone in the organization was prepared to accept the new teams setup.

[gratitoad]

We’re about to embark on the MFE journey and I’m concerned about pulling it off in a way that will have justified the effort. Our motivations are pure, we have many feature teams, we’re driving toward team independence, already breaking up the monolith into Microservices, etc. But on the FE we have the standard requirement to maintain eventual (definition tbd) UI consistency and so intend to continue to maintain a large number of build-time dependencies between MFEs and shared libraries. So I’m not sure exactly how to pull this off.

Are any of these “many success stories” talked about online? Case studies we can get pumped on?

[DanielHB]

This gets you most of the advantages of a microfrontend:

1) Monorepo with multiple workspaces

2) With several separate independently deployed applications, each maintained by a separate team

3) That share a set of common packages for common stuff (auth, etc) with full typescript definitions

4) Add CI to typecheck if any shared package changes types you get errors

5) Preferably with the packages being able to be independently run for development (something like storybook, although I don't recommend it)

6) Preferably with the packages being kept small, lean, with limited number of external dependencies (ie, settle on the cross-team deps to use, so framework, routing, data-fetching, etc)

7) Some kind of pre-commit git hook or CI script to validate a set of core shared dependencies used by packages are kept in sync (ie, everyone is running the EXACT SAME React version). I use this one: https://gist.github.com/DanielHoffmann/a456aadb2f27880d59241...

8) Shared build configuration and tools, all apps are validated, built and bundled by the same code.

9) NO PACKAGE PUBLISHING/VERSIONING, all dependencies are workspace:*

For example:

  folder-structure:
  /apps/{team1-app-name}/
  /apps/{team2-app-name}/
  /packages/auth/
  /packages/some-util-lib/

  /package.json
  "scripts": (test, lint, format, typecheck all done at the top level package.json)
  "workspaces": [
    "apps/*",
    "packages/*",
  ],

  /packages/auth/package.json
  "scripts": (dev to run in development mode)
  "devDependencies": { "some-util-lib": "workspace:*", "react": "^18.0.0" }
  "peerDependencies": { "some-util-lib": "*", "react": "*" }

  /apps/{team1-app-name}/package.json
  "scripts": (dev to run in development mode, build for production builds)
  "dependencies": {
     "auth": "workspace:*"
     "some-util-lib": "workspace:*"
  }

This doesn't give you 100% of the independence of microfrontends, but it does give you quite a lot of bang for your buck. Depending how much independence or reuse you want you might want more or less shared external dependencies (for example your shared packages could be framework agnostic and just use raw JS)

The build/bundling configuration can set up separate chunks for the core set of shared dependencies (react, router, etc) to improve build times, load speeds and caching*

[gratitoad]

First off, I appreciate the thoughtful write-up, under different circumstances this is the direction I’d probably be heading. However our web Frontend code is all currently in a large-ish (500 packages, 100 apps) monorepo and we’re actively pursuing breaking that up into a hybrid repo model, largely in the interest of true team autonomy. We want our code organization to better reflect our Eng org structure and to establish much stronger lines of ownership and responsibility. Obviously we see other compelling reasons to take this big step, but there’s also a lot of risk involved, particularly around dependency management and figuring out how to accomplish eventual UI consistency across our web apps, all of which will use a large number of shared libraries/components that will be broadly organized into a handful of repos (likely monorepos) representing domains and owned by different teams. The intent is for this evolution to culminate in a microfrontends architecture as a way to support collaboration across autonomous teams without the need for built-time coupling.

[DanielHB]

Fair enough, probably far bigger scale than I am used to. But I wonder why move away from a monorepo? Publishing and versioning common packages is a huge pain in the ass, especially for JS projects where you need transpiling, sourcemaps, etc.

Some smart branch management so teams can work independently seems better for me. For example each project gets their own production branch and development branches to trigger deployments and can pull changes from master as they see fit.

If you are planning on these shared components and dependencies be versioned I highly advise against that, the permutation of versions of underlying common libraries (like React) can make an incompatible versioning hell where component X works on React ^16.0.0 but in practice was tested in React ^18.0.0 only. In my own project I explicitly force all shared dependencies (which I try to keep to a minimum) to be on the same version.

> without the need for built-time coupling

There are two ways of having build-time coupling:

1) Shared build/bundling code, configuration and tools

2) Single build/bundling for all the code

You can most definitely have independent projects sharing the same build/bundling code, configuration and tools while every project is built separately and independently. This can make it hard to integrate with solutions that rely on taking over your bundling though.