• Conflicting versions due to transitive dependencies
• Repeatability of builds
  • Usually realized by lock-files

Categories:

• Project based

• Containing all code of a company

• Ups:

  • With individual repositories per package, the publication of a package is required before it can be used. In a monorepo this step can be omitted
  • Ease of using dependent packages within the same repository encourages to improve the reusability of code
  • Simplifies large refactorings

• Downs:

  • Requires specialized tools and workflows, for example:
    • Lerna
    • Yarn
  • Higher risk of violating the separation of concerns in a reasonable large code-base due to missing isolation
  • Size, Scalability

Resources:

• Building large scale react applications in a monorepo
• Monorepos in the Wild
• Monorepos: Please don’t!
• Sharing UI Components with Lerna and Yarn Workspaces

• Ups

  • Less excess of code for unsused functionality per package

• Downs

  • Requires tools to remain maintainable
  • License Management becomes harder
  • Reduces performance

• The Era Of Micro Packages

• NPM & left-pad: Have We Forgotten How To Program?

• NPM
• NuGet
• Yarn

Resources:

• Yarn vs npm - which Node package manager to use in 2018?

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Recommended:

• Elastic Load Balance (ELB)

  • Automated operations
  • On demand provisioning

• Microservices - a definition of this new architectural term

• Mastering Chaos - A Netflix Guide to Microservices