Why does front-end engineering prefer to use Monorepo architecture more and more?

Author: HannahLin
Source: medium

There are dreams, dry goods, WeChat search [Da Qian World] Pay attention to this Shuawanzhi who is still doing dishes in the early morning.
This article GitHub https://github.com/qq449245884/xiaozhi has been included, the first-line interview complete test site, information and my series of articles.

Monorepository (Monorepo for short) has a history, this term has only become so popular in recent years. My company has only introduced this architecture in the past six months. After I have tasted a lot of benefits, I want to write an article to introduce it. I hope that more people will know this architecture. This article will not be source code, but start from the pain points of the existing architecture ( Single Repo Monolith , Multi-repo ), why use Monorepo and so on.

What are the problems with the existing architecture?

20 years ago, the front-end was quite simple, but in the past 6 to 7 years, it has html/css/js tremendous changes. Nowadays, few people only use pure 061bfc78ddbe41 to make websites. Most of them are based on the front-end framework with a lot of dependencies (SCSS). preprocessors, task managers, npm, typescript...) . When the team develops to a certain size, several different products will be separated. The dependencies used by each product is different, making maintenance difficult. How can we avoid duplication of source code and assign responsibility? Let me introduce it through practical examples.

If shop.com has several projects today, each project has a different team responsible.

购物网站 shop.com (React)
结帐 shop.com/cart

购物网站手机版 m.shop.com (不是 RWD，是独立网站)
后台 admin.shop.com (Vue)
分析使用者网站 analytics.shop.com (Angular)

Note. Although you can choose to use different front-end frameworks for different projects, you will see the greater benefits of monorepo if you use the same one.

shop.com shop.ocm/cart are under the same domain, they are in charge of completely different teams

Under this complex structure, the methods we are more familiar with are Monolith and Multi repo [Extended reading: Probe into the Micro Frontends program structure]

Single-repo Monolith 😰

Initially we are using this architecture development, but with the increasingly complex front-end engineering, front-end needs to do more and more, more the Dependencies was introduced in Single-repo Monolith under the framework of the whole package It will become super fat, and the entire package must be deployed during deployment. Of course, delopy will explode for a long time. This architecture has obvious shortcomings, and it cannot achieve high scalability and efficient organizational development.

Single-repo Monolith 
apps
  ├ node_modules
  ├ libs // 放 share 的東西
  ├ design-systems 
  | ├ node_modules
  | ├ xx...
  ├ shop 
  | ├ node_modules
  | ├ cart
  | | ├ xx...
  | ├ xx...
  ├ shop-mobile
  | ├ node_modules
  | ├ xx...
  ├ admin
  | ├ node_modules
  | ├ xx...
  ├ analytics
  | ├ node_modules
  | ├ xx...
  ├ e2e
  | ├ xx...

Multi repo 😢

Now most of the front-end will use Multi repo , and each independent case will have a corresponding repo . The team maintains their own product , and it is easy to clarify responsibilities.

Design-systems Repository
design-systems
  ├ node_modules  
  ├ e2e
  ├ xxxx
Shop Repository
shop 
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Shop Cart Repository: Cart Cart 因为隶属另一个团队所以会拆分成两个 Repository
shop-cart
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Mobile Version Repository
shop-mobile
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Admin Repository
admin
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Analytics Repository
analytics
  | ├ node_modules
  | ├ e2e
  | ├ xx...

Seems good, but here comes the problem

Repeat configuration

Multi repo Because each repo is independent, so you must build your own webpack , development environment, how to deploy etc., if ten repo must maintain these 10 configurations inconsistent, if management is very different between repo trouble

Common code maintenance costs become high

projects of the logic between 061bfc78ddc16a is duplicated, but because of the difference from repo , it debug , and maintenance is time-consuming, labor-intensive and costly. You might want to pull out the things that will be used repeatedly and create a separate libs Repository , and just change the libs , then the process will be changed.

• libs Repository, version from 1.0 to 1.1 2.
• shop, shop-mobile, admin, analytic install the latest libs 1.1
• Commit changes, then push to update a self-repo, waiting for deploy

This is also the most common complaint about Multi repo, because the repo is cut too finely, resulting in only a share code process is also super complicated, and the time taken is relatively high.

Version management of dependencies becomes extremely complicated

react 17.0.2 and shop is still 15.6 . If the new version discards some support, a bug will occur. Or because the latest libs Repo is not pulled in time, the update is not timely and a bug occurs.

Mono repo 😊

Mono repo can solve the pain points of the above Multi repo. Since there is only one Repo, it is very convenient to manage. test suite runner , and a shared dependency if there is any change, then the project useful to this dependency will be known, and because there is only one repo, everyone is. The latest code will not be updated in a timely manner.

apps
  ├ design-systems
  ├ design-systems-e2e
  ├ shop
  | | ├ cart
  ├ shop-e2e
  ├ shop-mobile
  ├ shop-mobile-e2e
  ├ admin
  ├ admin-e2e
  ├ analytics
  ├ analytics-e2e
node_modules
libs
  ├ utils

libs can put anything that will be shared, such as design systems , TS Interfaces , JS Utilities etc. In this way, the respective teams of the architecture only focus on their own projects. For example, the shop-mobile team will only change the things in this folder, and you can also run shop-mobile only separately when building.

Although monorepo is the main repo, a package.json , but my company will still put some team specific packages in its own folder, for example, I am sure that only design-system is useful for gatsby. So the settings here can still be adjusted for your own company, but if this package is likely to be used by other teams in the future, it is best to put it on the outermost layer.

apps
  ├ design-systems
  | ├ node_modules
  ├ design-systems-e2e

advantage

• unified management of configs and tests : Because there is only one repo there is no need to repeat the configuration environment, including CI/CD , unit , e2e , webpack only need to maintain one copy
• deployment time of is very fast. 161bfc78ddc41c: Although it is the same repo, CI/CD can be individually deployed for different cases. If the share code changes, you don't need to pull request multi-repo for every project, but only need to update the cases that use this share code.

• management dependency becomes easy : one repo , one package.json
• Can oysters use share code (libs)
• Compile time: Compile time using monorepo will not slow down, because the good monorepo tools (such as nx) will help you optimize the cache and performance

Of course, monorepo still has some disadvantages

• huge codebase
• everyone can change the code of other teams. : because there is only one repo , but this is not a big problem, because the code push needs to be reviewed by a pull request. If it is approved, it is not managed.

❌
// shop.js
import 'adminTools' from 'admin'

If you want to import monorepo, I recommend Nx . The official documents are clearly written and some video tutorials are included.

Summarize

Of course, not every project is suitable for monorepo . It is still necessary to choose a suitable structure for the content of the project, but in general, if the project is large enough and different teams deal with different projects, monorepo is quite suitable.

code is deployed, the possible bugs cannot be known in real time. In order to solve these bugs afterwards, a lot of time was spent on log debugging. By the way, I would like to recommend a useful BUG monitoring tool Fundebug .

Original: https://medium.com/hannah-lin/%E7%82%BA%E4%BB0%E9%BA%BC%E5%89%8D%E7%AB%AF%E5%B7%A5% E7%A8%8B%E8%B6%8A%E4%BE%86%E8%B6%8A%E6%84%9B%E4%BD%BF%E7%94%A8-monorepo-%E6%9E%B6 %E6%A7%8B-661afa90910a

comminicate

If you have dreams and dry goods, search for [Moving to the World] pay attention to the brushing wisdom who is still doing dishes in the early morning.

This article GitHub https://github.com/qq449245884/xiaozhi has been included, the first-line interview complete test site, information and my series of articles.