2

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

rick
  • 554
  • 6
  • 18

1 Answers1

1

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/

Saurabh Nemade
  • 1,522
  • 2
  • 11
  • 20
  • In my research I came across "turbo.build", I had difficulties in relation to its production version. It uses Next, so my backend which is on nginx should be adapted? I couldn't find a version that uses webpack for example. The Module Federation is certainly something I should study well. – rick Nov 14 '22 at 21:53
  • You can certainly use it without NextJS. The normal create-react-app build will also work. Simply treat each web app as a separate project and have a CICD pipeline for each project separately to build & upload it to the server path that is behind Nginx. You can find many possible examples of module federation at: https://github.com/module-federation/module-federation-examples – Saurabh Nemade Nov 14 '22 at 22:34