Mobile Convergence

백앤드 10년 프론트앤드 10년 이젠 서비스 만들기 10년을 시작해 본다. 첫번째로 도커 개념을 이해하고 나만의 환경을 만들어 본다. 

개념과 기본 명령어

도커는 프로세스를 격리시켜 실행해주는 도구이다. 

도커 = 도커 엔진 + 도커 클라이언트로 클라이언트는 사용자가 명령을 전달하고, 서버는 명령을 수행한다. 서버는 보통 시스템 서비스로 등록된다. 

예) 도커 목록 보기

$ docker ps

exit 명령으로 container가 죽은 목록을 확인 할 때 -a 옵션
$ docker ps -a

도커 이미지 = 실행을 위한 애플리케이션 파일의 집합

IMAGE ID는 고유의 해쉬값이다.  

$ docker images

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
run-java            1.0                 8e445847d25d        16 months ago       643MB
tomcat              8.5.15              b8dfe9ade316        3 years ago         334MB
java                latest              d23bdf5b1b1b        3 years ago         643MB

이미지는 원격의 도커 저장소에서 pull받을 수도 있다. tag를 지정하지 않으면 기본 latest가 적용된다.

$ docker pull <image_name>:<tag>

예)
$ docker pull centos 

도커 실행예 -it 는 쉘을 실행하기 위한 옵션, bash를 실행한다. --name 옵션을 주면 실행 이미지의 별칭을 설정할 수 있다.

$ docker run -it <ImageName:tag> <command>

예)
$ docker run -it centos:latest bash

죽은 컨테이너 다시 시작하기는 container Id를 사용한다.

$ docker restart <container-hash-id>

예)
$ docker ps -a 로 container id 확인
$ docker restart afb7d8bdrexac
$ docker ps

프로세스와 터미널 상의 입출력 연결은 attach
$ docker attach afb7d8bdrexac

도커 컨테이너는 도커 이미지를 기반으로 실행된 격리된 프로세스이다. 따라서 컨테이너는 가상머신이라기 보다는 프로세스이다. 

이미지의 변경사항을 파악하기는 docker diff 명령을 사용한다. A (ADD), C (Change), D (Delete) 이다. 기존 컨테이너에 새로운 기능을 넣고 새로운 이미지를 만들려면 docker commit 명령을 사용한다. rm은 컨테이너 삭제, rmi는 이미지 삭제이다.

$ docker diff <container id>

$ docker commit <container id> <image name>

종료 상태 컨테이이너 ID를 가지고 rm으로 삭제한다.
$ docker ps -a 

$ docker rm <container id>

$ docker rmi <image name> (또는 image id)

Dockerfile로 이미지 만들기

Docker 이미지를 만들수 있는 DSL를 통해 Dockerfile 파일 내용을 구성한다. 

• FROM: 어떤 이미지로부터 새로운 이미지를 생성할지 지정한다.
• RUN: 실행할 컨테이너안에서 실행할 명령을 정의한다. 이미지 빌드시 한번만 수행한다. 다른 명령 이어 수행 && 다음줄 이어서 \ 사용
• COPY: 호스트 머신의 파일이나 폴더를 도커 컨테이너 안으로 복사
• ADD: COPY와 동일, url기반 다운로드, 압축파일은 압축 풀어줌
• CMD: 컨테이너 안에서 실행할 명령어를 지정한다. 컨테이너 실행시 덮어 쓸 수 있다.
• FOREGROUND: 실행 방식
• ENTRYPOINT: 컨테이너 안에서 실행될 프로세스(명령)을 지정한다. CMD의 인자값이 ENTRYPOINT에 전달된다.
• LABEL: key=value 설정
• ENV: 컨테이너 실행 환경 변수값 설정
• ARG: 이미지 빌드시 환경 변수값 설정, "--build-arg  key=value" 로 docker image build 명령 수행시 설정도 가능한다. 
• WORKDIR: 실행하는 디렉토리 위치를 변경한다. cd 명령과 같다.
• EXPOSE: 가상머신에 오픈할 포트를 지정한다.

Dockerfile 명으로 파일을 생성한다. ubuntu에 git 까지 설치하는 하기 내용을 넣는다.

FROM ubuntu:bionic
RUN apt-get update
RUN apt-get install -y git

빌드하고 이미지 확인한다.

$ docker build -t ubuntu:bionic-git .

Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM ubuntu:bionic
bionic: Pulling from library/ubuntu
....
 ---> cdc67675bfc4
Successfully built cdc67675bfc4
Successfully tagged ubuntu:bionic-git

확인 하기
$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              bionic-git          cdc67675bfc4        14 seconds ago      197MB
ubuntu              bionic              56def654ec22        4 weeks ago         63.2MB

도커를 실행하여 컨테이너에서 git 설치 확인한다.  

$ docker run -it ubuntu:bionic-git bash
root@1aef904d7e26:/# git --version
git version 2.17.1

이미지의 빌드과정을 보고 싶을 경우 history 명령을 이용한다. 

$ docker history ubuntu:monawiki
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
425046329513        2 hours ago         /bin/sh -c #(nop)  CMD ["/bin/sh" "-c" "bash…   0B

Dockerfile일 있는 이를 통해 이미지 빌드파일까지 있다면 향후 버전에 따른 영향에 대응할 수 있다. docker pull할 때 기본  레지스트리 정보는 info 명령으로 확인한다. 

$ docker info

Client:
 Debug Mode: false

Server:
 Containers: 0
....
 Registry: https://index.docker.io/v1/

pull 명령시에 Registory를 직접 지정할 수 있다.  레지스트리/네임스페이스/이미지명 => docker.io/library/ubuntu:bionic

$ docker pull docker.io/library/ubuntu:bionic

bionic: Pulling from library/ubuntu
171857c49d0f: Pull complete
419640447d26: Pull complete
61e52f862619: Pull complete
Digest: sha256:646942475da61b4ce9cc5b3fadb42642ea90e5d0de46111458e100ff2c7031e6
Status: Downloaded newer image for ubuntu:bionic
docker.io/library/ubuntu:bionic

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              bionic              56def654ec22        4 weeks ago         63.2MB

콘솔창에서 도커 허브 로그인은 login 명령이다. tag로 명칭을 만들고 push할 수 있다. 

$ docker tag <로컬 이미지명> <docker-hub-id>/<이미지명>
"docker tag" requires exactly 2 arguments.
Usage:  docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

$ docker push <docker-hub-id>/<이미지명>
"docker push" requires exactly 1 argument.
Usage:  docker push [OPTIONS] NAME[:TAG]

Docker Layer 개념

docker container layer의 변경사항을 알고 싶을 경우 

$ docker diff  <container id>

docker container layer의 변경사항을 이미지에 반영하고 싶을 경우

$ docker commit <container id> <new image name>

git을 포함시켜서 새로운 ubuntu:git 이미지 만들기

// 우분투 설치
$ docker pull ubuntu:focal

// git 있는지 확인
$ docker run -it ubuntu:focal /bin/sh -c 'git --version'
/bin/sh: 1: git: not found

// apt-get 업데이트
$ docker run -it ubuntu:focal /bin/sh -c 'apt-get update'

// 업데이트 이미지 커밋
$ docker commit $(docker ps -alq) ubuntu:git-layer-1
sha256:7c65ec0b9441f470a43e28a5c6dfc5a64a120090984e3c7bcd38540cb9ef0b1b

// 업데이트 layer에 git 설치
$ docker run ubuntu:git-layer-1 /bin/sh -c 'apt-get install -y git'

// git 설치 layer 커밋
$ docker commit $(docker ps -alq) ubuntu:git
sha256:e21b7d04736553bb0d995af6f6a751aca2e710f2e2f5874d026a89335a53ade9

// 설치 확인
$ docker run -it ubuntu:git bash -c 'git --version'
git version 2.25.1

// 이미지 확인
$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              git                 e21b7d047365        3 minutes ago       208MB
ubuntu              git-layer-1         7c65ec0b9441        5 minutes ago       98.8MB
ubuntu              focal               d70eaf7277ea        9 days ago          72.9MB

// history 확인
$ docker history ubuntu:git
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
e21b7d047365        15 minutes ago      /bin/sh -c apt-get install -y git               109MB
7c65ec0b9441        17 minutes ago      /bin/sh -c apt-get update                       25.9MB
d70eaf7277ea        9 days ago          /bin/sh -c #(nop)  CMD ["/bin/bash"]

위의 commit으로 이미지를 새롭게 생성한 것과 동일하게 Dockerfile로 빌드하여 이미지 생성하기

FROM ubuntu:focal
RUN apt-get update
RUN apt-get install -y git

빌드하기

$ docker build -t ubuntu:git2 .

Dockerfile로 생성된 이미지와 commit을 이용해 만든 최종 이미지는 같은 형태이다. 

참조

www.44bits.io/ko/post/why-should-i-use-docker-container

• 서버운용기록을 코드화 할 수 있다.
  • 도커 파일 만들기 = 서버 운영 기록 (Dockerfile)
  • 도커 이미지 만들기 = 도커 파일 + 실행 시점
  • 도커 컨테이너 만들기 = 도커 이미지 + 환경 변수

www.44bits.io/ko/post/easy-deploy-with-docker

www.44bits.io/ko/post/how-docker-image-work

joont92.github.io/docker/Dockerfile/

nirsa.tistory.com/63

Angular router의 loadChildren 을 사용하지 않고 Lazy loading하는 방법을 알아본다. 

Angular Module 에 대한 Lazy Loading

Angular의 Lazy Loading 방식

• NgModule 단위로 lazy loading한다.
• Angular v8부터 import(<module path>).then(mod => mod.<moduleName>) 방식으로 로딩한다. import 구문을 사용하면 자동으로 code splitting이 된다.
• Angular v7버전 이하는 ViewEngine 이라는 Template엔진을 사용했고, 8부터 선택적으로 9부터는 디폴트로 Ivy를 Template엔진으로 사용한다.
• Module을 컴파일/로딩하고 Component를 인스턴스화하기위해 ComponentFactoryResolver를 사용하고, ViewContainer에 인스턴스화된 컴포넌트를 렌더링한다.

우선 manual lazy loading을 위한 모듈과 컴포넌트를 생성한다. 

// 라이브러리 생성, nx 또는 ng 둘 다 사용가능하다
$ nx g lib manuallazy

// 컴포넌트 생성
$ nx g c manual --project=manuallazy
CREATE libs/manuallazy/src/lib/manual/manual.component.scss (0 bytes)
CREATE libs/manuallazy/src/lib/manual/manual.component.html (21 bytes)
CREATE libs/manuallazy/src/lib/manual/manual.component.spec.ts (628 bytes)
CREATE libs/manuallazy/src/lib/manual/manual.component.ts (283 bytes)
UPDATE libs/manuallazy/src/lib/manuallazy.module.ts (266 bytes)

lazyload하는 service를 "app-container" 애플리케이션에 생성한다.

$ nx g s lazy-loader --project=app-container
CREATE apps/app-container/src/app/lazy-loader.service.spec.ts (378 bytes)
CREATE apps/app-container/src/app/lazy-loader.service.ts (139 bytes)

서비스에 loadModule 메소드를 추가한다. 8전부터 Ivy 사용만 대응한다. 7버전 이하는 NgModuleFactoryLoader를 사용한다. (참조)

import { Compiler, Injectable, Injector, NgModuleFactory, Type } from '@angular/core';

@Injectable({
    providedIn: 'root',
})
export class LazyLoaderService {
    constructor(private compiler: Compiler, private injector: Injector) {}

    loadModule(path: any) {
        (path() as Promise<Type<any>>)
            .then((elementModule) => {
                    try {
                        return this.compiler.compileModuleAsync(elementModule);
                    } catch (err) {
                        throw err;
                    }
            })
            .then((moduleFactory) => {
                try {
                    const elementModuleRef = moduleFactory.create(this.injector);
                    const moduleInstance = elementModuleRef.instance;

                    // instantiate component dynamically.
                } catch (err) {
                    throw err;
                }
            });
    }
}

컴포넌트 인스턴스화 및 ViewContainer에 렌더링하기

다음 순서로 컴포넌트를 인스턴스화 한다. 

• ManuallazyComponent를 manuallazy 라이브러리에 생성한다.
• MauallazyModule에 초기 인스턴스화할 Component를 리턴한다.
• LazyLoaderService에서 ComponentFactoryResolver를 통해 인스턴스화하고 ViewContainer에 할당한다. 
• "app-container" 애플리케이션의 tsconfig.app.json에 "include"에 MauallazyModule의 index.ts를 추가 설정한다. 
• "app-container" 애플리케이션에서 LazyLoaderService를 loadModule을 호출한다. 

ManulComponent를 생성한다. 

$ ng g c manual --project=manuallazy

// libs/manuallazy/lib/src/manual/manual.component.html
<p>manual lazy component</p>

ManuallazyModule에 ComponentType을 리턴한다.

// libs/manuallazy/src/lib/manuallazy.module.ts

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { ManualComponent } from './manual/manual.component';

@NgModule({
    imports: [CommonModule],
    declarations: [ManualComponent],
})
export class ManuallazyModule {
    bootstrapComponent(): any {
        return ManualComponent;
    }
}

LazyLoaderService에 컴포넌트를 로딩하는 "addComponent" 메소드을 추가한다. 

// apps/app-container/src/app/lazy-loader.service.ts
import {
    Compiler,
    Injectable,
    Injector,
    NgModuleFactory,
    Type,
    ViewContainerRef,
    ComponentRef,
    ComponentFactory,
    ComponentFactoryResolver,
} from '@angular/core';

@Injectable({
    providedIn: 'root',
})
export class LazyLoaderService {
    constructor(private compiler: Compiler, private injector: Injector, private resolver: ComponentFactoryResolver) {}

    loadModule(path: any, viewContainer: ViewContainerRef): void {
        (path() as Promise<Type<any>>)
            .then((elementModule) => {
                try {
                    return this.compiler.compileModuleAsync(elementModule);
                } catch (err) {
                    throw err;
                }
            })
            .then((moduleFactory) => {
                try {
                    const elementModuleRef = moduleFactory.create(this.injector);
                    const moduleInstance = elementModuleRef.instance;

                    // instantiate component dynamically.
                    this.addComponent(moduleInstance.bootstrapComponent(), viewContainer);
                } catch (err) {
                    throw err;
                }
            });
    }

    addComponent(cmpType: any, viewContainer: ViewContainerRef): ComponentRef<any> {
        const factory: ComponentFactory<any> = this.resolver.resolveComponentFactory(cmpType);
        let cmp: ComponentRef<any>;
        if (viewContainer) {
            viewContainer.clear();
            cmp = viewContainer.createComponent(factory);
        }
        return cmp;
    }
}

"app-container" 애플리케이션의 tsconfig.app.json 에 MauallazyModule의 index.ts 를 추가 설정한다.

// apps/app-container/src/tsconfig.app.json 
{
    "extends": "./tsconfig.json",
    "compilerOptions": {
        "outDir": "../../dist/out-tsc",
        "types": []
    },
    "include": ["**/*.ts", "../../libs/lazyview/src/index.ts", "../../libs/manuallazy/src/index.ts"],
    "exclude": ["src/test-setup.ts", "**/*.spec.ts", "src/environments/*.ts"]
}

"app-container" 애플리케이션에서 ManullazyModule을 호출한다. 

// apps/app-container/src/app/app.component.html 일부분
<li nz-menu-item nzMatchRouter>
  <a (click)="manualLazyLoading($event)">Monitor</a>
</li>
... 중략 ...
<div class="inner-content">
   <router-outlet></router-outlet>
   <div style="padding-top: 100px;" #InnerContent></div>
</div>


// apps/app-container/src/app/app.component.ts
import { LazyLoaderService } from './lazy-loader.service';
import { Component, ViewChild, ViewContainerRef } from '@angular/core';

@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.scss'],
})
export class AppComponent {
    isCollapsed = false;
    @ViewChild('InnerContent', { read: ViewContainerRef }) innerContent: ViewContainerRef;

    constructor(private readonly lazyLoaderServie: LazyLoaderService) {}

    manualLazyLoading(event: MouseEvent): void {
        // import 할 때 위치투명하게 nx library를 호출한다.
        const manualLoad = () => import('@micro-demo/manuallazy').then((m) => m.ManuallazyModule);
        this.lazyLoaderServie.loadModule(manualLoad, this.innerContent);
    }
}

구현 소스: https://github.com/ysyun/blog-5730-micro-demo

라우팅으로 통한 Angular 모듈 Lazy loading과 메뉴얼 Lazy loading 방식의 단점

• 둘다 tsconfig.app.json과 같은 사전 설정작업이 필요하다.
• "app-container"라는 Lazy loading된 모듈을 사용하는 애플리케이션과 함께 컴파일이 되어야 한다.

장점은 import구문을 통해 자동 Code Splitting 기능이다. 위이 단점을 해결하기 위해서 Web Components를 지원하는 @angular/elements를 사용한다. 이에 대한 글은 다음을 참조한다. 

https://mobicon.tistory.com/573

참조

https://juristr.com/blog/2019/10/lazyload-module-ivy-viewengine/

https://juristr.com/blog/2017/07/ng2-dynamic-tab-component/

https://juristr.com/blog/2019/04/state-lazy-loading-components-angular/#manual-lazy-loading-of-modules

Nx.dev 기반개발에서 Angular 모듈을 Router기반으로 Lazy Loading하기와 Router를 사용하지 않고 Lazy Loading하는 방법에 대해 알아보자. 알단 Lazy Loading 설정을 하게되면 Angular 컴파일시에 자동으로 모듈단위 Code Splitting하여 번들링한다. 따라서 필요한 시점에 필요한 파일만 다운로드를 받기때문에  TTI(Time ot interactive)시간 즉, 애플리케이션 응답성능을 높일 수 있다. 참고로 Webpack 5 (핸재 beta) 에서 Federation Module 개념을 구현하였는데, Angular에서 이와 비슷한 기능을 Angular Module단위 개발로 제공한다.

NX 환경 설정

• NodeJS v12.* 사용
• @angular/cli와 @nwrl/ci 설치
• create-nx-workspace 이용하여 nx 기반 환경 생성
• yarn통한 node modules 설치

// NVM 설치 (https://github.com/nvm-sh/nvm)
$ nvm install 12.16.2
$ nvm alias default 12.16.2
$ nvm use 12.16.2

// 최신버전들 설치
$ npm i -g @angular/cli@latest
$ npm i -g @nrwl/cli@latest
$ npm i -g yarn@latest
$ npm install typescript@3.8.3 --save-dev --save-exact

// create-nx-workspace
$ npx create-nx-workspace@latest
  ? Worspace name   demo
  ...
$ cd demo
$ yarn install

Router 를 통한 Lazy Loading

• nx 명령을 통해 Lazy loading할 library를 생성한다.
• nx 명령을 통해 Lazy loading되어 보여질 component를 생성한다.
• libs/lazyview/src/lib/lazyview.module.ts 에 RouterModule.forChild 설정
• lazyview모듈을 로딩하는 "app-container" 애플리케이션의 tsconfig.app.json에 "include" path 설정
• apps/app-container/src/app/app-routing.module.ts 안에 loadChildren 을 통해 lazyview 모듈을 import 한다.

// 1) libs/lazyview 라이브러리 생성 - 라이브러리는 모듈단위
$ nx g lib --routing --lazy lazyview


// 2) 컴포넌트 생성
$ nx g c lazypage --project=lazyview


// 3) libs/lazyview/src/lib/lazyview.module.ts에 forChild 설정
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';
import { LazypageComponent } from './lazypage/lazypage.component';
@NgModule({
    imports: [
        CommonModule,

        RouterModule.forChild([
            { path: '', pathMatch: 'full', component: LazypageComponent }
        ]),
    ],
    declarations: [LazypageComponent],
})
export class LazyviewModule {}


// 4) apps/app-container/src/tsconfig.app.json 에 include/exclude 설정
{
    "extends": "./tsconfig.json",
    "compilerOptions": {
        "outDir": "../../dist/out-tsc",
        "types": []
    },
    "include": ["**/*.ts", "../../libs/lazyview/src/index.ts"],
    "exclude": ["src/test-setup.ts", "**/*.spec.ts", "src/environments/*.ts"]
}


// 5) app-routing.module.ts 에 loadChildren으로 '@micro-demo/lazyview' 설정
import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';
const routes: Routes = [
    { path: '', pathMatch: 'full', redirectTo: '/welcome' },
    { path: 'lazyview', loadChildren: () => import('@micro-demo/lazyview').then((m) => m.LazyviewModule) },
    { path: 'welcome', loadChildren: () => import('./pages/welcome/welcome.module').then((m) => m.WelcomeModule) },
];
@NgModule({
    imports: [RouterModule.forRoot(routes)],
    exports: [RouterModule],
})
export class AppRoutingModule {}

"nx serve"  수행한 후 "http://localhost:4200/lazyview" 로 호출한다.

소스: https://github.com/ysyun/blog-5730-micro-demo

참조

https://juristr.com/blog/2019/04/state-lazy-loading-components-angular/#manual-lazy-loading-of-modules

https://juristr.com/blog/2019/10/lazyload-module-ivy-viewengine/

https://juristr.com/blog/2019/08/ngperf-route-level-code-splitting/

https://medium.com/angular-in-depth/lazy-load-components-in-angular-596357ab05d8

https://indepth.dev/webpack-5-module-federation-a-game-changer-in-javascript-architecture/

Angular에서 schematic은 복잡한 로직을 지원하는 템플릿 기반의 코드 생성기이다. @angular/cli에서 코드 생성은 schematics를 사용하는 것이다. 해당 패키지는 @schematics/angular 이다. 본글에서는 나만의 schematic을 만들어 본다. 하기 문서를 참조하여 NX 기반으로 개발한다.

https://medium.com/@tomastrajan/total-guide-to-custom-angular-schematics-5c50cf90cdb4

Schematic 생성

 NX환경이 아니라면 @angular-devkit/schematics-cli 를 글로벌로 설치해서 schematics 명령을 사용해 초기 schematic파일을 자동 생성할 수 있다. 그러나 NX를 사용하면 @angular-devkit/schematics-cli설치 없이 nx명령으로 초기 파일을 생성할 수 있다. NX의 schematics을 사용하겠다는 정의는 루트의 angular.json에 정의되어 있다. 

    ...
    "schematics": {
        "@nrwl/angular:application": {
            "unitTestRunner": "jest",
            "e2eTestRunner": "cypress"
        },
        "@nrwl/angular:library": {
            "unitTestRunner": "jest"
        }
    },
    ...

명령어 예

//schematic-cli 설치
$ npm install -g @angular-devkit/schematics-cli

//schematics 명령 사용 경우
$ schematics blank hello


//NX 환경일 경우
$ nx g workspace-schematic hello
CREATE tools/schematics/hello/index.ts (250 bytes)
CREATE tools/schematics/hello/schema.json (348 bytes)

nx 명령을 생성된 schematic 파일은 tools/hello 폴더 밑에 존재한다. schema.json은 hello schematic의 정의 파일이고, index.ts가 동작하는 시작 파일이다. 

Schematic 키워드

• Tree: virtual file system을 표현한다. base 라는 이미 존재하는 파일 묶음과 staging area 라는 base에서 변경될 것들 목록으로 구성된다. base 는 변경할 수 없고, staging area 만 변경가능 하다.
• Rule: Tree를 받아서 변경점을 적용하고 새로운 Tree를 반환하는 함수이다. 메인 파일인 index.ts에 해당 함수를 정의한다.
• Action: Action을 변환(Transformation)으로 표현되고, action 타입은 Create, Rename, Overwrite, Delete 4가지 유형이 있다.
• 참조 원문

실제 사용자 정의 작업을 해야하는 Rule의 정의이다. 

export declare type Rule = (tree: Tree, context: SchematicContext) => Tree | Observable<Tree> | Rule | Promise<void> | Promise<Rule> | void;

모든 Schematic은 context안에서 구동되어야 하고, SchematicContext 객체로 표현된다. nx가 아닌 schematics 명령으로 생성된 index.ts 의 코드를 보자.

• hello함수는 RuleFactory로써 Rule을 반환하는 고차함수(a higher-order function)를 반환한다.
• hello함수안에서 나의 template이 어떻게 합쳐지고, 변경되어 지는 것인지 정의한다.

//schematic 명령으로 생성된 index.ts 내역

import { Rule, SchematicContext, Tree } from '@angular-devkit/schematics';

// You don't have to export the function as default. You can also have more than one rule factory
// per file.
export function hello(_options: any): Rule {
  return (tree: Tree, _context: SchematicContext) => {
    return tree;
  };
}

nx로 생성된 schematic 의 index.ts는 약간 틀린 구조이다. 

• default함수로 RuleFactory를 정의한다.
• Rule을 반환한다. 

import { chain, externalSchematic, Rule } from '@angular-devkit/schematics';

export default function (schema: any): Rule {
    return chain([
        externalSchematic('@nrwl/workspace', 'lib', {
            name: schema.name,
        }),
    ]);
}

Schematic 옵션 설정

• nx로 생성했을 경우: schema.json 파일에 옵션을 설정한다.
• schema.json의 properties 는 Schematic 수행시 prompt 로 작동하여 사용자 입력값을 처리한다. 
• properties안에 사용자로 부터 입력받고자하는 옵션을 설정한다. 입력받을 수 있는 옵션은 schema.json에 정의되어 있다.
• schema.json 전체 명세서

//nx 명령으로 생성된 schema.json 내역
{
    "$schema": "http://json-schema.org/schema",
    "id": "hello",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Library name",
            "$default": {
                "$source": "argv",
                "index": 0
            }
        }
    },
    "required": ["name"]
}

옵션의 Input "type"  

• confirmation: boolean 옵션
• input: text 또는 number 옵션
• list: 미리 정의한 목록을 선택

"style"을 정의한 예

//schema.json 예
"style": {
  "description": "The file extension or preprocessor to use for style files.",
  "type": "string",
  "default": "css",
  "enum": [
    "css",
    "scss",
    "sass",
    "less",
    "styl"
  ],
  "x-prompt": {
    "message": "Which stylesheet format would you like to use?",
    "type": "list",
    "items": [
      { "value": "css",  "label": "CSS" },
      { "value": "scss", "label": "SCSS   [ https://sass-lang.com/documentation/syntax#scss                ]" },
      { "value": "sass", "label": "Sass   [ https://sass-lang.com/documentation/syntax#the-indented-syntax ]" },
      { "value": "less", "label": "Less   [ http://lesscss.org                                             ]" },
      { "value": "styl", "label": "Stylus [ http://stylus-lang.com                                         ]" }
    ]
  },
},

x-prompt 필드를 통해 긴 입력 문구 조합이 가능하다. 

//x-prompt schema
{
    "oneOf": [
        { "type": "string" },
        {
            "type": "object",
            "properties": {
                "type": { "type": "string" },
                "message": { "type": "string" },
                "items": {
                    "type": "array",
                    "items": {
                        "oneOf": [
                            { "type": "string" },
                            {
                                "type": "object",
                                "properties": {
                                    "label": { "type": "string" },
                                    "value": { }
                                },
                                "required": [ "value" ]
                            }
                        ]
                    }
                }
            },
            "required": [ "message" ]
        }
    ]
}

Schematic 실행

Schematics CLI로 생성했을 경우

• index.ts를 컴파일한다. 
• 명령어: schematics <path-to-schematics-project>:<schematics-name> --<required-option>=<value>

//schematics 으로 생성한 폴더로 이동후 컴파일 수행
$ cd hello
$ npm run build

//schematics 수행
$ schematics .:hello
Nothing to be done.

nx 명령으로 생성했을 경우

• 명령어: npm run workspace-schematic <customized schematic name> <option>

$ npm run workspace-schematic hello hi

> micro-demo@0.0.0 workspace-schematic /Users/dowonyun/mobicon/projects/bistel/src/2019/micro-demo
> nx workspace-schematic "hello" "hi"

>  NX  Executing your local schematic: hello

CREATE libs/hi/tslint.json (91 bytes)
CREATE libs/hi/README.md (158 bytes)
CREATE libs/hi/tsconfig.json (135 bytes)
CREATE libs/hi/tsconfig.lib.json (190 bytes)
CREATE libs/hi/src/index.ts (26 bytes)
CREATE libs/hi/src/lib/hi.ts (0 bytes)
CREATE libs/hi/jest.config.js (246 bytes)
CREATE libs/hi/tsconfig.spec.json (269 bytes)
UPDATE tsconfig.json (731 bytes)
UPDATE angular.json (16683 bytes)

참조

Angular Schematic 개념: https://angular.io/guide/schematics

스키마 명세: https://github.com/angular/angular-cli/blob/7.0.x/packages/schematics/angular/application/schema.json

NX + Angular 기반 개발시 엔터프라이즈 애플리케이션 개발방법에 대한 글을 정리한다. Micro Frontend 개발방법이라기 보다는 애플리케이션을 개발하며 지속적으로 확장할 필요가 있을 때 관심사들을 어떻게 분리하여(Bounded Context) 개발할 수 있을지 보여준다.

https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/

https://connect.nrwl.io/app/books/enterprise-angular-monorepo-patterns

nx.dev를 이용한 라이브러리 관리

Nx는 하나의 레파지토리에서 멀티 애플리케이션과 라이브러리를 개발할 수 있는 환경을 제공한다. @angular/cli를 확장한 형태로 Angular, React, NodeJS를 함께 개발하고 별개로 번들링 배포할 수 있다. Nx 설치는 이전 글을 참조한다.

workspace/libs 하위로 폴더를 구분하여 업무를 개발할 수 있고, workspace/apps 의 애플리케이션에서 libs의 내용을 통합하여 사용하는 방법을 제시한다. 

• application
  • application 안에서 sub-domain을 import하거나, routing 한다.
  • sub-domain을 통합하는 방식이다. 
  • 애플리케이션, web, desktop(using Eletron), mobile(Ionic)을 이용하여 sub-domain을 사용한다.
• sub-domain
  • 업무 도메인이다.
  • sub-domain은 Bounded Context 이다.
  • Bounded Context는 업무 논리적으로 분리될 수 있는 단위이다.
  •  feature-shell
    • 업무 도메인의 페이지를 통합하고 routing을 설정한다. 
    • sub-domain 안에 1개 존재한다. 
    • shell은 sub-domain을 접근토록 하는 entry point 모듈이다.
    • shell orachestrate the routes of "Bounded Context"
  • feature-<bizName>
    • 일반적으로 웹 화면(Page) 하나라고 정의하자.
    • sub-domain 안에는 feature-<bizName>가 여러개 존재할 수 있다.

Nx applications과 libraries 폴더 구조

Feature-shell에서 sub-doamin(Bounded Context) 라우팅하기

애플리케이션에서 Feature-shell 라우팅하기. 애플리케이션에서 feature-shell을 조합하여 사용한다.

NX에서 Library 분류 및 개발 방법

nx workspace의 libs/ 밑으로 라이브러리를 개발할 때 다음과 같이 분류하여 개발한다. 

• Feature-Shell library
  • 업무 sub-domain을 통합하여 애플리케이션에서 사용할 수 있도록 한다.
• UI library
  • presentation component로써 버튼, 모달같은 업무 로직이 없는 컴포넌트들
• Shared library
  • Data Access library
    • REST API 서비스
    • WebSocket 통신
    • Ngrx/Store 기반 State 관리
  • Utils library
    • 유틸리티 서비스

NX에서 tag 구분 keywords

• scope
  • sub-domain 
  • grouping folder 
• type
  • feature-shell
  • ui
  • data-cess
• platform
  • desktop
  • mobile

예) scope:shared, type:feature,platform:desktop

각 라이브러리의 특성에 맞게 libs/ 밑으로 폴더/폴더 형태의 grouping folder 구조로 개발한다. 

feature-shell의 모듈 명칭은 "feature-shell" 으로 한다.

nx를 이용하여 library 생성시 옵션들

• --directory=<grouping folder name>
• --routing: forChild routing 자동 설정
• --lazy: application에 lazy routing 자동 설정, 반드시 parent-module을 지정함.
• --parent-module=<application module path and file name>: lazy 옵션 설정시 lazy routing 설정할 module 위치를 지정함.
• --tags=<tag>,<tag>: nx.json에 포함됨, nx.json에서 직접 수정 및 추가 가능 예) --tags=scope:shared,type:feature
• --publishable: 특별히 npm registry에 publish 할 수 있는 library를 만들고 싶을 때 사용한다. ng-packagr 기반이다.

//Command
nx g lib feature-<sub-domain name> --routing --directory=<grouping folder name> --lazy --parent-module=apps/<application>/src/app/app.module.ts

//Sample
$ nx g lib feature-shell --routing --directory=admin --lazy --parent-module=apps/app-container/src/app/app.module.ts
? Which stylesheet format would you like to use? SASS(.scss)  [ http://sass-lang.com   ]
CREATE libs/admin/feature-shell/README.md (162 bytes)
CREATE libs/admin/feature-shell/tsconfig.lib.json (459 bytes)
CREATE libs/admin/feature-shell/tslint.json (276 bytes)
CREATE libs/admin/feature-shell/src/index.ts (50 bytes)
CREATE libs/admin/feature-shell/src/lib/admin-feature-shell.module.ts (367 bytes)
CREATE libs/admin/feature-shell/src/lib/admin-feature-shell.module.spec.ts (432 bytes)
CREATE libs/admin/feature-shell/tsconfig.json (138 bytes)
CREATE libs/admin/feature-shell/jest.config.js (405 bytes)
CREATE libs/admin/feature-shell/tsconfig.spec.json (258 bytes)
CREATE libs/admin/feature-shell/src/test-setup.ts (30 bytes)
UPDATE angular.json (15807 bytes)
UPDATE nx.json (1098 bytes)
UPDATE tsconfig.json (863 bytes)

품질 및 일관성 유지 방법

• Single Version을 apps와 libs에 적용한다. 
  • package.json에서 관리한다. 
• Code Formatting은 prettier를 사용한다.
  • prettier 설정 관련하여 블로그 글 참조
• Library Dependencies 관리
  • library 순환 참조는 안된다. 
  • library가 application을 import하거나 의존하지 않는다. 
  • npm run dep-graph 또는 npm run affected:dep-graph 수행하면 라이브러리 의존관계도가 자동생성되어 웹브라우져에서 확인할 수 있다.
  • MS Code Editor의 Plugin으로 "Nx Console"을 설치하면 Editor에서 바로 수행해 볼 수도 있다.

Nx Schematics 관리

Nx에 Built-in 된 schematics

• ngrx: Ngrx/store 기반으로 reducer, action, selector, facade를 자동 생성함
• node: Express node application의 경우 
• jest: unit test
• cypress: E2E test
• etc..

Custom schematic 만들기

• 개발자들이 샘플코드를 copy & paste하지 않고 schematic을 통해 업무 개발을 위한 파일을 생성토록할 때 사용한다.
• nx g workspace-schematic <custom-schematic-name> 명령을 수행하면 workspace/tools/ 폴더 밑에 schematic파일이 생성됨.
  • 예제 파일 생성: nx g workspace-schematic data-access-lib 수행
  • 예제 파일 수행: npm run workspace-schematic data-access-lib <name>

//index.ts에 ngrx를 추가로 적용한 예제

import { chain, externalSchematic, Rule } from '@angular-devkit/schematics';
import * as path from 'path';

export default function (schema: any): Rule {
    if (!schema.name.startsWith('data-access-')) {
        throw new Error(`Data-access lib names should start with 'data-access-'`);
    }
    const stateName = schema.name.replace('data-access-', '');
    return chain([
        externalSchematic('@nrwl/workspace', 'lib', {
            name: schema.name,
            tags: 'type:data-access',
        }),
        externalSchematic('@nrwl/schematics', 'ngrx', {
            name: stateName,
            module: path.join('libs', schema.name, 'src', 'lib', `${schema.name}.module.ts`),
        }),
    ]);
}

관련소스: github.com/ysyun/blog-5730-micro-demo.git

참조

https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/

NX에서 Eletron, Ionic, NativeScript 통합 개발하기

https://nstudio.io/xplat/fundamentals/architecture