Life can be a series of copy-paste days
One day, you are assigned by your boss to a new project that needs a back-end, front-end for both administrators and end-users. Due to being familiar with the coding of React and NodeJS experienced billions of projects before. So it doesn’t take long, you dig into the company’s previous projects, or have a built-in “boilerplate” that you can create or view on github. You quickly “copy-paste” the lines of code that you are proud of to a new project. For example middlewares, utils functions, helper functions, functions …. that you are busy building. Then until Redux-shared, shared users such as login, register, login, logout … Soon, you have a complete framework to be able to embark on a new project code with your team very quickly. .
Suddenly one beautiful day, the beautiful tester beamed at you and said: “Brother, I see that is wrong …”. With all your dignity, you immediately check for and find out that one of your utils functions is incorrectly coded. Fire up and start debugging and fixing it. Then you have to think through your mind, which projects of the company use this function and repair one by one, then build and deploy each project again. At that time you wonder: “What did I do wrong that this number of suffering” =))). You realize you’ve tormented yourself, the source code in the company 20-30% of the same, and can continue to increase. At this point, the problem of covering errors is possible on all projects.
As a leader, you immediately summon martial to find a solution. A young developer gives you the solution. That is to create separate libraries for each of the above functions, publish them to npm. Projects that need to be used can be installed and used as another 3rd-library available on npm. At this point you and everyone feel reasonable, because those lines of code only need to be written once and then pushed to npm and no longer copy-paste. You think you have found the light of your life, you and your partner scooped up the code and pushed it to npm. The problem is solved.
Wait….
Then one day, a friend who has 2 years of experience fixing library A and then publishing the new version on npm, he told you to update the version of the library on the project. But people don’t know, the other fresher corrects the output of a function from string => number. So all the remaining projects after the update fail clean unit-test (it’s your company that still has unit test =))). Blacker CI / CD runs, and your project runs the risk of collapsing in an instant … Then everyone punches that fresher in a big game.
Begin
I think the above problem, we must have been, are and will be able to have in our careers. Dragging a number of lines of code from one project to another is not very strange, right? Then we think to ourselves, do not know how leading technology companies such as facebook, google, microsoft will solve with such huge amount of code, but sometimes we have lost our career and have not read all. OK. Through wandering the internet, I have read a number of articles about how to organize code in the world’s leading companies. That is the monorepos term.
You can search on google for this term easily, I would like to briefly summarize Monorepo: Monorepos is a way of developing software, in which we will save all the codes of many projects in common. 1 repository on revision control systems. . Currently, many leading technology companies in the world are using Monorepos to develop their applications, such as Google, Facebook, Microsoft, Uber, Airbnb, Twitter …
Benefits of monorepos:
There are many advantages of monorepos compared to traditional development, they are:
- “Ease of code reuse”: We can use shared libraries that we develop ourselves directly, by abstracting them and using them directly instead of depending on a package manager like NPM.
- “Simplified dependency management”: When we use multiple repositories to store source code, these repositories will use the 3rd libraries, and these libraries have to be downloaded and built in all repositories. When we use monorepos, these 3rd party libraries will only be downloaded at the original codebase. Furthermore, 3rd versions may be consistent across projects. For example, I use Angular, if we split into repositories, there will be cases where Angular versions will be different between projects: 2,4,9,11 … If we use monorepos and manage Well, we will identify the Angular versions to the latest one, so the code is always upgraded to the latest version on all other projects.
- “Large-scale code refactoring”: Every time we refactor code in codebase lines, we make sure that we won’t affect other projects without having to update library version like the script we mentioned at the beginning of this article.
- “Atomic commits”: Normally, we have to make sure that when the project is active we have to synchronize the versions between projects. For example library 2.0 updates to 3.0. Those applications must also update the library to 3.0. When there are so many projects, unified and synchronized management becomes a big concern for the leaders and team leads. For monorepos, we can change the code in different libraries and applications, and commit the same time and have a specific hash commit, so the following people can capture the changes to the projects.
- “Collaboration across teams”: We can work between teams more easily. For example, a team specializes in developing library utils, a team specializes in developing applications that use other libraries. Communication between the two teams is continuous and essential.
Beneficial, must be harmful:
- “Collaboration across teams”: Each build code has only one version for all projects
- “Lack of per-project access control”: Must grant access to all source code for team members. In some cases, this is not allowed because each member can only access certain repositories (in case of using multi repo).
- “More storage needed by default”: We only need code on one project and still have to clone the whole repository
The above disadvantages must also be faced by big technology corporations, but according to our research, Google or big companies have their revision control systems and solve the above problem.
Epilogue
Whether or not to use Monorepo depends on your team. For me, there will be 1 of the following cases.
Candlestick:
- When project is internal, do not worry about managing code among members, should use monorepo
- When there is a large amount of codebase shared
- The team obeys the rule, writes unit test and check affect fully
Should not:
- When making projects for many customers, monorepo can be used with the condition of handing over the final source code. At this point, all other project source code must be deleted before handing over. In the case of customers accessing the source during development, it is absolutely not possible.
There are also a number of tools available for monorepos generation like Lerna, Yarn, and NxWorkspace.
However, I personally think that, NxWorkspace currently has many advantages over other tools.
Next article I will write articles about NxWorkspace. Good bye!.