Basic Basic Basic Introduction

Monorepo

Multiple Repositories

Props

Clean ownership

A small team can own and independently develop and deploy the full stack(like tools, workflow, ...etc.) of a service.

Props

Better scale and coordination

The purpose of the organization as a whole gets diluted, each teams don't need to know the main objective of the company.

Teams do not need to coordinate with other teams, only need to know what will be provided by other teams and what should be provided by them.

Thus leading to faster execution.

Props

Narrow clones

Only needs to clone their own repository files

Props

Easily for DevOps

Easily setting CI/CD, ...etc.

Cons

The purpose of the organization as a whole gets diluted, each teams don't need to know the main objective of the company.

Sometimes too idealistic

Assume we have a package called "foo" and there are some related plugins or middlewares

One day, plugin "bar" has some bugs caused by its core package "foo"

Fix foo

Publish foo to npm

Install foo on repository of foo-plugin-bar

Test foo-plugin-bar

foo-plugin-bar still broken

Done

x N

Monorepo

Google
Facebook
Twitter

Props

Simplified organization

With a mono repo, projects can be organized and grouped together in whatever way you find to be most logically consistent, and not just because your version control system forces you to organize things in a particular way.

Using a single repository also reduces overhead from managing dependencies and versions.

Props

Easily refactor

Developers can easily run the entire system on their machine and this helps them understand all services and how they work together. This has led our developers to easily refactor a core feature or find more bugs locally before even sending a pull request.

Props

Single lint, build, test and release process

Since everything is located inside one repo, you can configure your CI/CD and bundler once and then just reuse configs to build all packages before publishing them to remote.

Same goes for unit, e2e, and integration tests—your CI will be able to launch all tests without having to deal with additional configuration.

So does releasing and publishing.

Props

Coding style

Some companies find it useful to have a consistent coding format enforced across their code.

This is certainly more difficult to achieve when you have separated repositories.

Props

Atomic commit

The feature across modules can be rollbacked just like database transaction.

Props

Specific section improvement

With the adoption of mono repo, every individual in the organization is aware of business objectives and this makes it a unified team and hence can contribute more specifically towards the goals and objective of the organization.

Props

Centralized report issues.

People may not clearly know the certainly place where issues belong.

Can use label to distinguish where the issue belongs to.

Cons

Massive repository size

As title

Cons

No way to restrict access authority

Unfortunately, you can’t share only the part of your monorepo.

You will have to give access to the whole codebase, which might lead to some security issues.

Cons

Heavily refactoring

Although easily refactoring as above discussion, but heavily.

Cons

CI CD

Difficultly without tools.

Git Submodules

Git submodules is, for most developers, a painful topic.

Bazel (Google)

https://bazel.build/

Bazel (Google)

Bazel is a build tool for large-scale applications, which can handle multi-language dependencies and support a lot of modern languages (Java, JS, Go, C++, etc.).

In most cases, using Bazel for small-to-medium JS applications is overkill, but on a large scale, it may provide a lot of benefit because of its performance.

Who is using Bazel ?

It's just suitable for really large applications. Thus powerful but hard to learn.
And I haven't use it.

Lerna

https://lerna.js.org/

Lerna

Splitting up large codebases into separate independently versioned packages is extremely useful for code sharing. However, making changes across many repositories is messy and difficult to track the versions of dependencies.

Problem

Lerna

Commands

Lerna

Centralized version

Who is using Lerna ?

Yarn Workspace

https://classic.yarnpkg.com/en/docs/workspaces/

Yarn Workspace

Yarn initially is a dependency manager for NPM packages, which was not initially built to support monorepos.

But in version 1.0, Yarn developers released a feature called Workspaces.

At release time, it wasn’t that stable, but after a while, it became usable for production projects.

Yarn Workspace

Centralized node_modules

Single node_modules folder in the root for all packages.
For example, if you have `packages/package-a` and `packages/package-b`—with their own package.json.

All dependencies will be installed only in the root.

That is one of the differences between how Yarn and Lerna work.

Who is using yarn workspace ?

For packages

Structure, Lerna config, Tools

example package: artibox

Structure

package.json
for yarn

lerna

Symlink(Alias)

webpack alias

tsconfig

Clear dependencies

root

packages

Single lint

eslint

prettier

Single build

run topologically via dependencies of packages

bold, highlight, italic, underline, strikethrough
depends on toggle-mark

Single release & publish

add version tag and changelog

publish to npm

For application

Isomorphic & Shared

example system: cms(content management system)

Isomorphic vs Universal

The backend and frontend share the same code.

Run everywhere

same logic

same logic

Server
Php
Java
.Net Core

Client
JavaScript

Server
JavaScript

Client
JavaScript

Isomorphic

The goal of isomorphic is the same as monorepo

To share

Share anything if possible

DBA
orm
repository

DBA
orm
repository

console client

console client

website server

website
client

Shared in whole app

Isomorphic / common / shared

error codes

utils / helpers (lodash-like)

...etc

Shared in servers

common / shared

dao / entities / models (from orm)

utils / helpers related to business logics for server

middlewares

services, like queue, task schedule, ...etc.

...etc

Shared in clients

common / shared

ui (such as a library)

hooks

utils / helpers related to business logics for client

...etc

Share

Don't repeat your self if possible.

DBA
orm
repository

DBA
orm
repository

console client

console client

website server

website
client

File Structure

For me, it would look like

/isomorphic
  /article
    /errors
      article-not-found.error.ts
    /utils
      ...
  ...
/db
  /article
    article.entity.ts
    article.repository.ts
  ...
/server-shared
  ...
/console-server
  /article
    article.service.ts
    article.resolver.ts
  ...
/website-server
  /article
    article.service.ts
    article.resolver.ts
  ...
/client-shared
  ...
/console-platform
  /core
    /article
      /hooks
        useCreateArticle.ts
        useUpdateArticle.ts
        ...
      /components
         CreateArticleForm
         CreateArticleModal
         ...
  /pages
    /article
      /create
        index.tsx
      /update
        index.tsx
      index.tsx
/website
  /core
    /article
      /hooks
        useArticleQuery.ts
      /components
        Article
  /pages
    /article
      index.tsx

Q & A

Made with Slides.com