saljdkl All the front-end modules are currently run either through Employee or Citizen app wrapper.

Hence, it takes a long time to compile the modules and run through the wrapper.

Pros of decoupling :

Separate builds

Decoupling enables every module to build and run separate pipeline. Hence, it can be injected as an independent module in any implementation/state required.

Versioning

Modules can be versioned and can be configured in different versions, meanwhile it can be shared with any partner groups or implementation/state with demanded versions.

Resource Productivity

Currently Employe/Citizen App acts as a wrapper to every module, which requires the transpile of JS6 versioning of code to JS5 . This can be avoided in decoupling, hence reducing the overall frequent transpile after every code change.

Independent Development

Suppose any code change in any module during implementation, consists a bug which effects all other modules, all the dependant resources will be blocked unless the bug is fixed. This can be avoided easily by decoupling as every module will have respective builds.

It can be then used as npm package and can be used by any teams/groups

Reasons to decouple :

1 . Currently, both in QA and DEV env, the Citizen and Employee builds gets overridden frequently as both environment is common across the teams (W&S - Tarrento , BPA -Walking Tree).

For Example:

All the teams use single release branch to deploy in QA and latter env. Now when each teams work on feature branches and deploy them for unit testing in dev environment. Hence overiding all other module changes. Hence the deployment becomes inconsistent in dev environment.

Decoupling will enable every team to build and deploy each module seperately.

Uses/Approach

All app we are making as CRA application.

https://reactjs.org/docs/create-a-new-react-app.html#create-react-app

2. Each will have a separate build pipeline or we will publish it into private npm repo. It will take less time to build.

3. Separate build commands.

"prod:employee-mcs": "yarn run go_employee_mcs && cd dev-packages/egov-uc-dev && yarn build"

4. Sepeate run commands.

"dev:employee-mcs": "cd dev-packages/egov-uc-dev && yarn start"

5. It will increase the developer productivity, currently, all developers are integrating with citizen or employee completing their development, a single line of code they have to run transpile command to convert into ES6/7 to ES5 it will take some time to see their changes.

6. It will reduce the size of the resource into 50% compared to the current application. Below is the example we have done on the MCS application. The 1st load time of the application is very good.

Current : -

Before:-

7. We will able to find out duplicate code, functionality, and packages while running into separately.

8. If the state needs a single application, it can be easily deployed.

9. Feature-wise we could store the images in Docker hub if we need versioning on the individual modules.

FAQ’s on decoupling the Modules

How would the wrapper employee and citizen application work? Left navigation bars and everything?

It depends on the 2 different approaches .

Approach one - Using Employee and Citizen apps as npm packages as its working now.

Approach two - Hosting seperate pipelines of different modules(PT, TL, etc) will render as an iframe inside employee and citizen apps.

The left menu is a seperate Component will be imported either from UI-framework or UI-kit.

What would be the versioning strategy of the npm packages for each of the packages and app we use?

We are planning to publish to our private npm repo. Third-party(react, material-UI) packages versioning yarn/npm will take care of while downloading from npm.

It needs to be defined which package version should a product use and how to determine it?

It can be handled by a branch of the specific state or product.

How the state-specific changes would be followed in the npm packages?

It can be handled by a branch of the specific state or product.

Any state pushing to a package from their pipeline can break the npm package itself

It can be handled by a branch of the specific state or product.

Currently, we repeated the login page in the MCS app when we separated it for Punjab. This cannot scale if each module defines their own page

Its was just workaround for POS release, We have already planned to move the Login page as a component in UI-framework, so all new modules acn just import the component and use the login/registration/forgot password/language-selection/otp pages.

Benefits of upgrading the UI framework

All the components gets updated with latest version of Material UI. The framework becomes more user freindly.
Latest Materail UI versions have newly introduced components , which can be used in our apps to provide user a better User Interface.
New utility functions avialbale in later versions.

Detailed release note of the material UI to upgrade :

https://github.com/mui-org/material-ui/releases/tag/v4.9.6

https://github.com/mui-org/material-ui/releases/tag/v4.8.3

https://github.com/mui-org/material-ui/releases/tag/v4.7.2

https://github.com/mui-org/material-ui/releases/tag/v4.6.1

https://github.com/mui-org/material-ui/releases/tag/v4.5.2

https://github.com/mui-org/material-ui/releases/tag/v4.4.3

https://github.com/mui-org/material-ui/releases/tag/v4.3.3

https://github.com/mui-org/material-ui/releases/tag/v4.2.1

https://github.com/mui-org/material-ui/releases/tag/v4.1.3

https://github.com/mui-org/material-ui/releases/tag/v4.0.2