CODEWITHSUNDEEP
javascriptreactjsmonorepomicro-frontend
rick
rick

Reputation: 751

Modularizing the system independently - Micro Front-End or Monorepo (React)

Problem

Well, start with the problem at hand. Several systems support several functionalities, whether they are applications or pages, and most of them independently.

But for lack of planning, this system becomes a single and complicated project, being difficult to install or update.

The proposal would then be to modulate it, making parallel development, easy, and effective, since a change in an independent module would not impact the update of the entire system.

This concept is already well defined, but I am clearly looking for how far this is possible, and if it's worth it.

enter image description here

enter image description here

structure

enter image description here

The images above describe well what we intend to do in the system.

We intend to divide the system into independent modules, but that can share some things with each other, such as dependencies, interface design and global states.

Possible solutions - Pros and Cons

Here begins my question in question.

At the end of the construction of this project, we should have a system that can be developed separately for each module.

some solutions

Micro Front-End - React

Monorepo - React

Well, we know that there are several ways to configure a react project and launch it, and here begins another challenge.

Another important point is the generated build, it is interesting to keep the react pattern, in which several .js and .css files will be generated in a build folder, making it easy to launch it into production.

All modules would be using the same language (javascript) and the same framework (react).

Well, what would be the best alternative given this project scope? I read several articles demonstrating how to implement monorepo or micro front-end, but most were simple or didn't show the entire process, how to build etc.

A simple demo containing the above idea would also be interesting

Upvotes: 3

Views: 1052

Answers (1)

Saurabh Nemade
Saurabh Nemade

Reputation: 1582

I would go with monorepo approach specifically: https://turbo.build/

With this, I can have multiple packages in same repo as well as web apps at the same place.

I would structure them like this:

apps
 - mainApp - App with module federation
 - module1 - app hosted at /app1
 - module2 - app hosted at /app2
 - module3 - app hosted at /app3
packages
 - app-container
 - app-requests
 - app-translations
 - app-logs
 - app-tracking
 - app-state-management

With this approach, you can add more packages quickly and can have common utilities shared across multiple web apps. You can add multiple packages as your needs grow and quickly use them across the different web apps quickly specifically configuration-related things like sentry/datadog. Later on, you can separate the apps and packages into multiple repositories if they get bigger and publish them as packages separately.

Additionally, you can have one main app that implements module federation and can use other apps independently deployed at their respective URLs. You can read more about module federation here: https://webpack.js.org/concepts/module-federation/

Upvotes: 2

Related Questions