AI Convergence

Micro Service들이 멀티 Database를 사용할 경우 또는 Database Schema에 대한 주도권이 없으며 단지 연결하여 사용하는 입장의 Frontend Stack 개발자일 경우 Prisma보다는 TypeORM을 사용하는 것이 좋아보인다. 

TypeORM 설치 및 환경설정

nestjs 패키지와 typeorm 그리고 postgresql 패키지를 설치한다. 

$> yarn add @nestjs/typeorm typeorm pg

.env를 읽는 방식이 아니라 별도의 configuration json 파일에서 환경설정토록 한다. 

apps/gateway/api/src/environments/ 폴더에 orm-config.json 과 orm-config.prod.json 파일을 생성한다. 

• synchronized는 반드시 개발시에만 true로 사용한다.

// orm-config.json
{
  "HOST": "localhost",
  "PORT": 5432,
  "USER": "iot",
  "PASSWORD": "1",
  "DATABASE": "rnm-stack",
  "ENTITIES": ["libs/domain/src/lib/entities/**/*.entity.ts"],
  "MODE": "dev",
  "SYNC": true
}

// Production 환경에서 사용
// orm-config.prod.json
{
  "HOST": "localhost",
  "PORT": 5432,
  "USER": "iot",
  "PASSWORD": "1",
  "DATABASE": "rnm-stack",
  "ENTITIES": ["libs/domain/src/lib/entities/**/*.entity.ts"],
  "MODE": "production",
  "SYNC": false
}

dev와 prod간의 config 스위칭을 위하여 apps/gateway/api/project.json 안에 replacement  문구를 추가한다. 

// project.json 일부내역
"fileReplacements": [
{
  "replace": "apps/gateway/api/src/environments/environment.ts",
  "with": "apps/gateway/api/src/environments/environment.prod.ts"
},
{
  "replace": "apps/gateway/api/src/environments/config.ts",
  "with": "apps/gateway/api/src/environments/config.prod.ts"
},
{
  "replace": "apps/gateway/api/src/environments/orm-config.ts",
  "with": "apps/gateway/api/src/environments/orm-config.prod.ts"
}
]

libs/shared/src/lib/configuration/ 폴더에 orm-config.service.ts 파일을 생성하고, orm-config.json 파일을 값을 다루도록 한다.

// orm-config.service.ts
import { TypeOrmModuleOptions } from '@nestjs/typeorm';
import { loadOrmConfiguration } from './config.service';

class OrmConfigService {
  constructor(private env: { [k: string]: any }) { }

  ensureValues(keys: string[]) {
    keys.forEach(k => this.getValue(k, true));
    return this;
  }

  getPort() {
    return this.getValue('PORT', true);
  }

  isProduction() {
    const mode = this.getValue('MODE', false);
    return mode !== 'dev';
  }

  getTypeOrmConfig(): TypeOrmModuleOptions {
    const config: TypeOrmModuleOptions = {
      type: 'postgres',
      host: this.getValue('HOST'),
      port: parseInt(this.getValue('PORT')),
      username: this.getValue('USER'),
      password: this.getValue('PASSWORD'),
      database: this.getValue('DATABASE'),
      entities: this.getValue('ENTITIES'),
      synchronize: this.getValue('SYNC'),
    };
    return config;
  }

  private getValue(key: string, throwOnMissing = true): any {
    const value = this.env[key];
    if (!value && throwOnMissing) {
      throw new Error(`config error - missing orm-config.${key}`);
    }
    return value;
  }

}

/**
 * Singleton Config
 */
const ormEnv: any = loadOrmConfiguration();
const ormConfigService = new OrmConfigService(ormEnv)
  .ensureValues([
    'HOST',
    'PORT',
    'USER',
    'PASSWORD',
    'DATABASE'
  ]);

export { ormConfigService };

apps/gateway/api/src/app/app.module.ts 에서 해당 configuration을 설정토록한다. @nestjs/typeorm의 모듈을 사용한다.

// app.module.ts
import { join } from 'path';
import { Module } from '@nestjs/common';
import { ServeStaticModule } from '@nestjs/serve-static';
import { TypeOrmModule } from '@nestjs/typeorm';
import { getMetadataArgsStorage } from 'typeorm';

import { GatewayApiAppService, EntitiesModule } from '@rnm/domain';
import { ormConfigService } from '@rnm/shared';

import { DashboardModule } from './dashboard/microservice/dashboard.module';
import { AppController } from './app.controller';
import { UserController } from './user/user.controller';

@Module({
  imports: [
    ServeStaticModule.forRoot({
      rootPath: join(__dirname, 'public'),
      exclude: [
        '/api/gateway*', '/api/dashboard*', '/api/configuration*', '/api/back-office*',
        '/dashboard*', '/configuration*', '/back-office*'
      ],
    }),
    // ORM 환경을 설정한다. orm-config.json에 설정했던 entities의 내용을 등록한다. 
    TypeOrmModule.forRoot({
      ...ormConfigService.getTypeOrmConfig(),
      entities: getMetadataArgsStorage().tables.map(tbl => tbl.target)
    }),
    EntitiesModule,
    // MicroService
    DashboardModule,
  ],
  controllers: [
    AppController,
    UserController
  ],
  providers: [GatewayApiAppService]
})
export class AppModule { }

TypeORM사용 패턴

typeorm은 두가지 패턴을 선택적으로 사용할 수 있다.

• Active Record: BeanEntity를 상속받아 entity내에서 CRUD 하기. (작은 서비스유리)
• Data Mapper: Model은 별도이고, Respository가 DB와 연결하고, CRUD를 별도 서비스로 만든다. (큰 서비스유리)

Data Mapper 패턴을 사용하기 위해 libs/domain/src/lib/entities/user/ 폴더하위에 user.entity.ts, user.model, user.service.ts 파일을 생성한다. 

• user.entity.ts: table schema
• user.model.ts: interface DTO
• user.service.ts: CRUD 

// user.entity.ts
import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity('user_iot')
export class UserEntity {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  username!: string;

  @Column()
  password!: string;

  @Column()
  email!: string;

  @Column()
  firstName!: string;

  @Column()
  lastName!: string;

  @Column({ default: false })
  isActive!: boolean;

  // USER, ADMIN, SUPER
  @Column({ default: 'USER' })
  role!: string;
}


// user.model.ts
export interface User {
  id: number;
  username: string;
  password: string;
  email?: string;
  firstName: string;
  lastName: string;
  isActive: boolean;
  role: string;
}


// user.service.ts
import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';

import { UserEntity } from './user.entity';
import { User } from './user.model';

@Injectable()
export class UserService {
  constructor(
    @InjectRepository(UserEntity) private repository: Repository<UserEntity>
  ) { }

  create(data: User): Promise<User> {
    return this.repository.save(data);
  }

  updateOne(id: number, data: User): Promise<any> {
    return this.repository.update(id, data);
  }

  findAll(): Promise<User[]> {
    return this.repository.find();
  }

  findOne(username: string): Promise<User | undefined> {
    // findOne이 객체라는 것에 주의
    return this.repository.findOne({ username });
  }

  deleteOne(id: string): Promise<any> {
    return this.repository.delete(id);
  }
}

libs/domain/src/lib/entities/  폴더에 entity.module.ts 생성하고, user.entity.ts를 등록한다.  entity.module.ts에는 user.entity외에 계속 추가되는 entity들을 forFeature로 등록한다. 

// entity.module.ts
import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { UserService } from './user/user.service';
import { UserEntity } from './user/user.entity';

@Module({
  imports: [
    TypeOrmModule.forFeature([UserEntity])
  ],
  providers: [UserService],
  exports: [UserService]
})
export class EntitiesModule { }

entity.module.ts을 사용하기 위해 apps/gateway/api/src/app/app.module.ts 파일에 등록한다. 

//app.module.ts 
import { TypeOrmModule } from '@nestjs/typeorm';
import { EntitiesModule } from '@rnm/domain';
import { ormConfigService } from '@rnm/shared';

@Module({
  imports: [
    ...
    // ORM
    TypeOrmModule.forRoot(ormConfigService.getTypeOrmConfig()),
    EntitiesModule,
    ...
  ],
  ...
})
export class AppModule { }

User CRUD 컨트롤러 작성 및 테스트

사용자 CRUD를 위한 controller를 작성한다. apps/gateway/api/src/app/user/ 폴더를 생성하고, user.controller.ts 파일을 생성한다. 

// user.controller.ts
import { Body, Controller, Delete, Get, Param, Post, Put } from '@nestjs/common';
import { User, UserService } from '@rnm/domain';

@Controller('api/gateway/user')
export class UserController {
  constructor(
    private readonly service: UserService
  ) { }

  @Post()
  create(@Body() data: User): Promise<User> {
    return this.service.create(data);
  }

  @Put(':id')
  updateOne(@Param('id') id: number, @Body() data: User): Promise<any> {
    return this.service.updateOne(id, data);
  }

  @Get()
  findAll(): Promise<User[]> {
    return this.service.findAll();
  }

  @Get(':username')
  findOne(@Param('username') username: string): Promise<User | undefined> {
    return this.service.findOne(username);
  }

  @Delete(':id')
  deleteOne(@Param('id') id: string): Promise<any> {
    return this.service.deleteOne(id);
  }
}

gateway를 start하면 dev모드에서 synchronized: true에서 "user_iot"  테이블이 자동으로 생성한다. 

Postman으로 호출을 해본다. 

• POST method 선택
• Body에 request json 입력
• JSON 형식 선택
• "Send" 클릭

<참조>

- TypeORM 사용형태

https://aonee.tistory.com/77

- TypeORM & Observable 로 변경 사용하는 방법

https://www.youtube.com/watch?v=Z6kw_aJHJLU 

- Nx에서 typeorm 로딩시 에러 이슈

https://github.com/nrwl/nx/issues/1393

MS-4/5/6 글을 통해 Gateway의 공통 기능 구현을 위한 설정을 적용한다.

• Login 할때 사용자 정보는 ORM 기반으로 처리한다.
• 인증을 JWT 기반으로 처리한다.
• Login 화면을 React 기반 구현한다.

NestJS에 Prisma ORM 설정

gateway-api의 공통 기능은 다음과 같고, JWT처리를 위한 사용자 정보 조회를 위해 Prisma ORM을 적용한다. Micro Service도 Prisma를 사용할 것이다.

• api gateway: TCP 통신으로 micro service의 API를 연결한다. 
• http server: gateway의 공통 기능중 Login을 서비스한다.
• reverse proxy: Login이 성공하면 dashboard micro service로 이동한다. (configuration, back-office)
• auth server: JWT 기반으로 token을 발행하고, 요청에 대한 모든 Authorization(인가, 권한)을 체크한다.

Step-1) 설치 및 환경 설정

auth server 기능에서 사용자 정보 데이터처리를 위해 ORM으로 Prisma를 사용을 위해 패키지를 (v3.1.1) 설치한다.

$> yarn add -D prisma
$> yarn add @prisma/client
$> yarn add -D ts-node

전체 애플리케이션을 위한 초기 prisma 환경을 생성한다.

$> npx prisma init

✔ Your Prisma schema was created at prisma/schema.prisma
  You can now open it in your favorite editor.

Next steps:
1. Set the DATABASE_URL in the .env file to point to your existing database. If your database has no tables yet, read https://pris.ly/d/getting-started
2. Set the provider of the datasource block in schema.prisma to match your database: postgresql, mysql, sqlite, sqlserver (Preview) or mongodb (Preview).
3. Run prisma db pull to turn your database schema into a Prisma schema.
4. Run prisma generate to generate the Prisma Client. You can then start querying your database.

More information in our documentation:
https://pris.ly/d/getting-started

자동 생성된 .env 파일에 설정을 추가한다. 

# Environment variables declared in this file are automatically made available to Prisma.
# See the documentation for more detail: https://pris.ly/d/prisma-schema#using-environment-variables
# Prisma supports the native connection string format for PostgreSQL, MySQL, SQLite, SQL Server (Preview) and MongoDB (Preview).
# See the documentation for all the connection string options: https://pris.ly/d/connection-strings
#DATABASE_URL="postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public"

# POSTGRES
POSTGRES_USER=iot
POSTGRES_PASSWORD=1
POSTGRES_DB=rnm-stack

# Nest run locally
DB_HOST=localhost
# Nest run in docker, change host to database container name
# DB_HOST=postgres
DB_PORT=5432
DB_SCHEMA=public

# Prisma database connection
DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${DB_HOST}:${DB_PORT}/${POSTGRES_DB}?schema=${DB_SCHEMA}&sslmode=prefer

VS Code의 extension을 설치한다. 

Step-2) schema.prisma 설정

VSCode extension이 설치되면 schema.prisma의 내용이 다음과 같이 highlighting된다. 

schema.prisma 파일 안에 Prisma 방식의 스키마를 정의한다.

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
  // previewFeatures = []
}

// generator dbml {
//   provider = "prisma-dbml-generator"
// }

model User {
  id        Int   @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  email     String   @unique
  password  String
  firstname String?
  lastname  String?
  posts     Post[]
  role      Role
}

model Post {
  id        Int   @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  published Boolean
  title     String
  content   String?
  author    User?    @relation(fields: [authorId], references: [id])
  authorId  Int?
}

enum Role {
  ADMIN
  MANAGER
  USER
}

schema.prisma를 통해 Migrate SQL과 Prisma Client 파일을 자동 생성한다. Prisma Client 파일은 구현 코드에서 사용된다. (참조)

Step-3) schema 설정을 통해 sql 생성하기 

명령을 수행하면 prisma/migrations sql이 자동 실행된다. 생성된 sql을 통해 table schema를 업데이트한다. 변경점이 있으면 날짜별로 update 할 수 있는 table schema가 자동으로 생성된다. 

$> npx prisma migrate dev --create-only --name=iot

또한 DB Schema에 _prisma_migrations 테이블이 자동생성된다. 

테이블을 자동 생성하고 싶다. prisma db push 명령을 사용한다. (참조)

$> npx prisma db push

Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "rnm-stack", schema "public" at "localhost:5432"
🚀  Your database is now in sync with your schema. Done in 77ms
✔ Generated Prisma Client (3.1.1) to ./node_modules/@prisma/client in 61ms

Step-4) Prisma Studio 사용하기

prisma는 내장 웹기반 studio를 제공한다. 테이블을 선택하여 조작할 수 있다.

$> npx prisma studio

NestJS 에서 PrismaClient  사용하기

Step-1) PrismaClient 생성

schema에 생성되었으면 다음으로 코드에서 Prisma 접근을 위해 PrismaClient를 생성해야 한다. (참조)

• "npx prisma migrate dev" 명령으로 수행할 경우는 "npx prisma generate"이 필요없다. 
• "npx prisma migrate dev --create-only" 일 경우만 수행한다.
• schema.prisma 변경시 마다 다시 실행해 주어야 한다. (참조)

$> npx prisma generate
✔ Generated Prisma Client (3.1.1) to ./node_modules/@prisma/client in 181ms
You can now start using Prisma Client in your code. Reference: https://pris.ly/d/client
```
import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
```

prisma client는 기본적으로 node_modules/.prisma/client 폴더 밑에 생성된다.

Step-2) schema.prisma가 변경이 발생할 경우

이제 "PrismaClient"를 import해서 사용할 수 있는 상태가 되었다. 만일 테이블 변경이 발생한다면 아래와 같이 수행한다. 

• schema.prisma 파일 내역 수정
• "npx prisma migrate" 명령 실행
• migrations 폴더에 있는 migration sql을 database에 적용한다. 

Step-3) NestJS 서비스 생성

사용자 정보는 공통이므로 libs/domain 에 생성한다. (참조)

• libs/shared/src/lib밑으로 prisma 폴더를 생성하고, prisma-client.service.ts파일을 생성한다. 
• index.ts에 export를 추가한다. 

// prisma-client.service.ts 
import { Injectable, OnModuleInit, OnModuleDestroy } from '@nestjs/common'
import { PrismaClient } from '@prisma/client'

@Injectable()
export class PrismaClientService extends PrismaClient implements OnModuleInit, OnModuleDestroy {
  async onModuleInit() {
    await this.$connect()
  }

  async onModuleDestroy() {
    await this.$disconnect()
  }
}

// index.ts
export * from './lib/configuration/config.model';
export * from './lib/configuration/config.service';
export * from './lib/prisma/prisma-client.service';

apps/gateway/api/src/app/app.module.ts에 PrismaClientService를 추가한다.

// /apps/gateway/api/src/app/app.module.ts
import { Module } from '@nestjs/common';
import { ServeStaticModule } from '@nestjs/serve-static';
import { join } from 'path';

import { GatewayApiAppService } from '@rnm/domain';
import { PrismaClientService } from '@rnm/shared'; <== 요기

import { AppController } from './app.controller';
import { DashboardModule } from './dashboard/dashboard.module';

@Module({
  imports: [
    ServeStaticModule.forRoot({
      rootPath: join(__dirname, 'public'),
      exclude: [
        '/api/gateway*', '/api/dashboard*',
        '/dashboard*', '/configuration*', '/back-office*'
      ],
    }),
    DashboardModule
  ],
  controllers: [AppController],
  providers: [GatewayApiAppService, PrismaClientService] <== 요기
})
export class AppModule { }

gateway/api/src/app/app.controller.ts에 테스트 코드로 POST로 user를 생성하는 코드를 작성한다. 

// apps/gateway/api/src/app/app.controller.ts
import { Body, Controller, Get, Post } from '@nestjs/common';

import { GatewayApiAppService } from '@rnm/domain';
import { PrismaClientService } from '@rnm/shared';

import { Role, User as UserModel } from '@prisma/client';

@Controller('api/gateway')
export class AppController {
  constructor(
    private readonly appService: GatewayApiAppService,
    private readonly dbService: PrismaClientService
  ) { }

  @Get()
  getData() {
    return this.appService.getData();
  }

  @Post('user')
  async createUser(@Body() userData: {
    email: string,
    password: string,
    firstname: string,
    lastname; string,
    role: Role
  }): Promise<UserModel> {
    const { email, password, firstname, lastname, role } = userData;
    return this.dbService.user.create({
      data: {
        email,
        password,
        firstname,
        lastname,
        role: !role ? Role.USER : role
      }
    });
  }
}

VSCode에서 Debug창에서 Gateway를 실행하고, 디버깅을 한다.

Postman을 실행하여 User 를 생성해 본다.

• 새로운 Request를 만들고 POST를 선택
• Body에 JSON 타입을 선택
• request 값을 넣고, http://localhost:8000/api/gateway/user 호출

DB툴로 User insert가 되었는지 확인 또는 prisma studio에서 확인

소스: https://github.com/ysyun/rnm-stack/releases/tag/ms-4

<참조>

- Primsa on NestJS 기반 개발

https://www.prisma.io/nestjs

- Prisma Migrate 순서

https://www.prisma.io/blog/prisma-migrate-ga-b5eno5g08d0b

- Primsa, JWT on NestJS StartKit

https://github.com/fivethree-team/nestjs-prisma-starter

- Prisma의 다양한 DB 예제

https://github.com/prisma/prisma-examples

micro service인 dashboard와 gateway간의 테스트 환경을 VS Code에 만들어 본다. 

VS Code 디버깅환경 설정

Step-1) package.json에 script 등록

각 애플리케이션의 build 스크립트를 등록한다. 

// package.json 
  "scripts": {
    "start": "nx serve",
    "build": "nx build",
    "test": "nx test",
    "build:gateway-api": "nx build gateway-api",
    "start:gateway-api": "nx serve gateway-api",
    "build:dashboard-api": "nx build dashboard-api",
    "start:dashboard-api": "nx serve dashboard-api",
    "build:configuration-api": "nx build configuration-api",
    "start:configuration-api": "nx serve configuration-api",
    "build:back-office-api": "nx build back-office-api",
    "start:back-office-api": "nx serve back-office-api"
  },

Step-2) .vscode 폴더안의 tasks.json 추가

tasks.json은 vscode의 디버깅 실행 환경설정파일인 launch.json에서 사용한다. 

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build:dashboard-api",
      "type": "shell",
      "command": "npm run build:dashboard-api"
    },
    {
      "label": "build:configuration-api",
      "type": "shell",
      "command": "npm run build:configuration-api"
    },
    {
      "label": "build:back-office-api",
      "type": "shell",
      "command": "npm run build:back-office-api"
    },
    {
      "label": "build:gateway-api",
      "type": "shell",
      "command": "npm run build:gateway-api"
    }
  ]
}

Step-3) .vscode 폴더안의 launch.json 추가

tasks.json의 설정내용은 "preLaunchTask"에 설정한다.

• task.json의 build 를 먼저 실행한다. 빌드하면 루트폴더의 dist 폴더에 js, map이 생성된다. 
• 이후 main.ts 소스에 breakpoint를 찍으면 디버깅을 할 수 있다. 

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Dashboard API",
      "program": "${workspaceFolder}/apps/dashboard/api/src/main.ts",
      "preLaunchTask": "build:dashboard-api",
      "outFiles": ["${workspaceFolder}/dist/apps/dashboard/api/**/*.js"]
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Gateway API",
      "program": "${workspaceFolder}/apps/gateway/api/src/main.ts",
      "preLaunchTask": "build:gateway-api",
      "outFiles": ["${workspaceFolder}/dist/apps/gateway/api/**/*.js"]
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Configuration API",
      "program": "${workspaceFolder}/apps/configuration/api/src/main.ts",
      "preLaunchTask": "build:configuration-api",
      "outFiles": ["${workspaceFolder}/dist/apps/configuration/api/**/*.js"]
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Back-Office API",
      "program": "${workspaceFolder}/apps/back-office/api/src/main.ts",
      "preLaunchTask": "build:back-office-api",
      "outFiles": ["${workspaceFolder}/dist/apps/back-office/api/**/*.js"]
    }
  ]
}

Gateway와 Micro Service간의 TCP 통신 테스트

Step-1) gateway의 dashboard.controller.ts에서 호출

• dashboard.controller.ts에서 서비스호출
• dashboard.service.ts 에서 breakpoint

// apps/gateway/api/src/app/dashboard/dashboard.controller.ts 
import { Controller, Get } from '@nestjs/common';

import { Observable } from 'rxjs';
import { DashboardService } from './dashboard.service';

@Controller('api/dashboard')
export class DashboardController {
  constructor(
    private readonly dashboardService: DashboardService
  ) { }

  @Get('sum')
  accumulate(): Observable<{ message: number, duration: number }> {
    return this.dashboardService.sum();
  }
}

// apps/gateway/api/src/app/dashboard/dashboard.service.ts 
import { Injectable, Inject } from "@nestjs/common";
import { ClientProxy } from "@nestjs/microservices/client";
import { Observable } from "rxjs";
import { map } from "rxjs/operators";

@Injectable()
export class DashboardService {
  constructor(@Inject("DASHBOARD") private readonly client: ClientProxy) { }

  sum(): Observable<{ message: number, duration: number }> {
    const startTs = Date.now();
    const pattern = { cmd: 'dashboard-sum' };
    const payload = [1, 2, 3];
    return this.client
      .send<number>(pattern, payload)
      .pipe(
        map((message: number) => ({ message, duration: Date.now() - startTs }))
      );
  }
}

Step-2) Micro Service 인 dashboard에서 요청처리

• 요청에 대한 sum 처리후 observable 로 반환
• MessagePattern 데코레이터 적용

import { Controller, Get } from '@nestjs/common';
import { MessagePattern } from '@nestjs/microservices';

import { DashboardApiAppService } from '@rnm/domain';
import { from, Observable } from 'rxjs';

@Controller()
export class AppController {
  constructor(private readonly appService: DashboardApiAppService) { }

  @Get()
  getData() {
    return this.appService.getData();
  }

  @MessagePattern({ cmd: 'dashboard-sum' })
  accumulate(data: number[]): Observable<number> {
    console.log('calling sum from dashboard....');
    const sum = data[0] + data[1] + data[2];
    return from([sum]);
  }
}

Step-3) Dashboard, Gateway 서버 실행

디버깅으로 이동한다.

• Dashboard API 실행
• Gateway API 실행

브라우져에서 호출

• http://localhost:8000/api/dashboard/sum

디버깅 실행 영상

https://www.youtube.com/watch?v=UDWPnJdQUhI 

소스

https://github.com/ysyun/rnm-stack/releases/tag/ms-3

React와 Nest를 기반으로 마이크로 서비스를 구축해 본다. 개발 환경은 Nx를 사용한다. Nx 환경구축은 [React HH-2] 글을 참조한다.

목차

• Gateway, Dashboard등의 Application 생성
• Application에서 사용하는 Library 생성
• Gateway <-> MicroService Application간 통신 설정
  • api 호출: reverse proxy & tcp 설정
  • static assets 호출: static server 설정

Application 생성

4개의 카테고리에 각각 api, web 애플리케이션을 생성한다. 

• gateway, dashboard, configuration, back-office
  • api, web

Step-1) 사전 준비환경 설치

글로벌 환경 설치를 한다. nvm 설치는 [React HH-2] 글을 참조한다.

$> npm i -g @angular/cli@latest 
$> npm i -g @nrwl/cli@latest 
$> npm i -g yarn@latest

node 버전은 nvm을 사용하여 14.18.0 를 사용한다. nvm 버전을 자동으로 설정하고 싶다면 

1) .zshrc파일에 다음 내용을 첨부한다. (Gist 코드 참조)

2) 작업 폴더에 .nvmrc 파일을 만든다.

// 코드: https://gist.github.com/ysyun/845ddd32467bb50af654e1e4605a4b50
// .zshrc
autoload -Uz add-zsh-hook
load-nvmrc() {
    local _CUR_NODE_VER="$(nvm version)"
    local _NVMRC_PATH="$(nvm_find_nvmrc)"

    if [[ -n "${_NVMRC_PATH}" ]]; then
        local _NVMRC_NODE_VER="$(nvm version "$(cat "${_NVMRC_PATH}")")"

        if [[ "${_NVMRC_NODE_VER}" == 'N/A' ]]; then
            local compcontext='yn:yes or no:(y n)'
            vared -cp "Install the unmet version ($(cat "${_NVMRC_PATH}")) in nvm (y/n) ?" _ANSWER
            if [[ "${_ANSWER}" =~ '^y(es)?$' ]] ; then
                nvm install
            fi
        elif [[ "${_NVMRC_NODE_VER}" != "${_CUR_NODE_VER}" ]]; then
            nvm use
        fi
    elif [[ "${_CUR_NODE_VER}" != "$(nvm version default)" ]]; then
        echo -e "Reverting to the default version in nvm"
        nvm use default
    fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

// 작업 폴더에 .nvmrc 파일을 생성하고, 버전을 기입힌다. 아래 내용 참조
// .nvmrc
14.18.0

Step-2) NX 개발환경 생성

create-nx-workspace@latest를 이용하고, .nvmrc 파일을 생성한다. .zshrc가 적용되고, rnm-stack 폴더에 진입하면 자동으로 14.18.0 버전이 적용된다. rnm은 React Nest Micro-service의 약어이다.

$> npx create-nx-workspace@latest
✔ Workspace name (e.g., org name)     · rnm-stack
✔ What to create in the new workspace · react
✔ Application name                    · gateway/web
✔ Default stylesheet format           · scss
✔ Use Nx Cloud? (It's free and doesn't require registration.) · No


$> cd rnm-stack
$> echo "14.18.0" > .nvmrc

다음은 api 애플리케이션을 Nest기반으로 생성한다.

// nest 제너레이터 설치
$> yarn add -D @nrwl/nest@latest

// api 생성
$> nx g @nrwl/nest:app gateway/api

다음으로 루트폴더에 있는 workspace.json 파일을 각 api와 web폴더에 project.json 파일을 생성하여 설정을 옮긴다. 이후 생성되는 애플리케이션들은 자동으로 project.json 파일로 생성된다. 

// workspace.json
{
  "version": 2,
  "projects": {
    "gateway-api": "apps/gateway/api",  <== project.json 파일의 위치 지정
    "gateway-web": "apps/gateway/web",
    "gateway/web-e2e": "apps/gateway/web-e2e"
  },
  ... 생략 ...
  "defaultProject": "gateway-web"
}

테스트 "nx serve gateway-web" 을 수행하면 정상적으로 dev server가 수행된다.

$> nx serve gateway-web

> nx run gateway-web:serve
>  NX  Web Development Server is listening at http://localhost:4200/

나머지 dashboard, configuration, back-office도 생성한다.

// react application
$> nx g @nrwl/react:app dashboard/web
$> nx g @nrwl/react:app configuration/web
$> nx g @nrwl/react:app back-office/web

// nest application
$> nx g @nrwl/nest:app dashboard/api
$> nx g @nrwl/nest:app configuration/api
$> nx g @nrwl/nest:app back-office/api

전체 생성 애플리케이션과 workspace.json 내역

Libraries 생성

다음으로 libs 폴더 하위로 라이브러리들을 생성한다. @rnm/page, @rnm/ui, @rnm/domain, @rnm/shared 로 import하여 사용한다.  

• page
• ui
• domain
• shared

$> nx g @nrwl/react:lib page --importPath=@rnm/page --publishable
$> nx g @nrwl/react:lib ui --importPath=@rnm/ui --publishable
$> nx g @nrwl/nest:lib domain --importPath=@rnm/domain --publishable
$> nx g @nrwl/nest:lib shared --importPath=@rnm/shared --publishable

Micro Service Communication Channel 설정

다음은 애플리케이션간의 연결을 위한 통신부분을 설정한다. NestJS 기반으로 microservice 생성을 위해 패키지를 설치한다. NestJS버전을 7.6.18 버전으로 업데이트 한다. (현재 8.*은 microservice 버그가 있다. 작동불능)

$> yarn add @nestjs/microservices


// package.json 에서 nestjs의 모든 패키지의 버전을 업데이트 한다. 
  "dependencies": {
    "@nestjs/common": "^7.6.18", <== 요기
    "@nestjs/core": "^7.6.18", <== 요기
    "@nestjs/microservices": "^7.6.18", <== 요기
    "@nestjs/platform-express": "^7.6.18", <== 요기
    "@nestjs/serve-static": "^2.2.2",
    "core-js": "^3.6.5",
    "react": "17.0.2",
    "react-dom": "17.0.2",
    "react-router-dom": "5.2.0",
    "reflect-metadata": "^0.1.13",
    "regenerator-runtime": "0.13.7",
    "rxjs": "~6.6.3",
    "tslib": "^2.0.0"
  },
  "devDependencies": {
    "@nestjs/schematics": "^7.3.1", <== 요기, 7최신이 7.3.1
    "@nestjs/testing": "^7.6.18", <== 요기
    ...
  }
  
  
  // nestjs 모든 패키지의 업데이트 버전을 재설치한다.
  $> yarn

Step-1) Micro Service 설정

• dashboard, configuration, back-office 3가지 micro service
  • http server & static server
    • dashboard: 8001, configuration: 8002, back-office: 8002 HTTP port를 사용한다.
  • api server
    • dashboard: 8100, configuration: 8200, back-office: 8300 TCP port를 사용한다.

apps/dashboard/api/src 하위로 public 폴더를 하위로 dashboard 폴더를 추가로 생성한 후 index.html 파일을 생성한다.

• apps/dashboard/api/src/environments폴더에 config.json 파일을 생성한다.
• apps/dashboard/api/project.json 에  "assets" 파트에 설정을 추가한다. 
  "assets": ["apps/dashboard/api/src/environments", "apps/dashboard/api/src/public"]

libs/shared/src/lib 밑에 configuration 폴더를 생성하고, config.service.ts 와 config.model.ts을 생성한다. config.json 파일을 읽기위한 용도이다. index.ts에  export도 설정한다.

// config.service.ts
import * as fs from "fs";
import { join } from 'path';
import { GatewayConfiguration, MicroServiceConfiguration } from "./config.model";

export const loadMicroServiceConfiguration = (message = '[LOAD] config.json file'): MicroServiceConfiguration => {
  console.log(`${message}:`, `${__dirname}/environments/config.json`);
  const jsonFile = fs.readFileSync(join(__dirname, 'environments', 'config.json'), 'utf8');
  return JSON.parse(jsonFile);
}

export const loadGatewayConfiguration = (message = '[LOAD] config.json file'): GatewayConfiguration => {
  console.log(`${message}:`, `${__dirname}/environments/config.json`);
  const jsonFile = fs.readFileSync(join(__dirname, 'environments', 'config.json'), 'utf8');
  return JSON.parse(jsonFile);
}


// config.model.ts 
export interface MicroServiceConfiguration {
  REVERSE_CONTEXT?: string;
  REVERSE_ADDRESS?: string;
  HTTP_PORT?: number,
  TCP_HOST?: string;
  TCP_PORT?: number,
  GLOBAL_API_PREFIX?: string;
}

export interface GatewayConfiguration {
  HTTP_PORT?: number,
  GLOBAL_API_PREFIX?: string;
  DASHBOARD?: MicroServiceConfiguration;
  CONFIGURATION?: MicroServiceConfiguration;
  BACK_OFFICE?: MicroServiceConfiguration;
}


// index.ts
export * from './lib/configuration/config.model';
export * from './lib/configuration/config.service';

apps/dashboard/api/src/main.ts 파일을 수정한다. http server를 위한 listen port를 설정하고, microservice client가 연결토록 TCP로 연결 준비를 한다. loadMicroServiceCofiguration 함수를 "@rnm/shared" 패키지로 부터 위치 투명하게 (마치 node_modules에 설치된 것처럼) import 할 수 있다.

import { Logger } from '@nestjs/common';
import { NestFactory } from '@nestjs/core';
import { Transport, MicroserviceOptions } from '@nestjs/microservices';

import { loadMicroServiceConfiguration } from '@rnm/shared';

import { AppModule } from './app/app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Load config.json file
  const config = loadMicroServiceConfiguration();

  // // Setup tcp server for api
  const options: MicroserviceOptions = {
    transport: Transport.TCP,
    options: { host: config.TCP_HOST, port: config.TCP_PORT || 8100 }
  };
  app.connectMicroservice(options);
  app.startAllMicroservices();

  // // Setup http server for web
  const httpPort = config.HTTP_PORT || process.env.HTTP_PORT || 8001;
  const globalPrefix = config.GLOBAL_API_PREFIX || '/api';
  app.setGlobalPrefix(globalPrefix);
  await app.listen(httpPort, () => {
    Logger.log(`Listening at http://localhost:${httpPort}${globalPrefix}`);
  });
}

bootstrap();

확인 & 테스트 

// LISTEN 포트 확인
$> netstat -an |grep 8100
tcp4       0      0  *.8100                 *.*                    LISTEN
$> netstat -an |grep 8001
tcp46      0      0  *.8001                 *.*                    LISTEN

// gateway 실행
$> nx serve dashboard-api

// other console
$> curl -X GET "http://localhost:8001/api" 
{"message":"Welcome to dashboard/api in libs"}

configuration, back-office도 동일하게 적용한다.

Step-2) Micro Service의 HTTP port가 static file 서비스토록 설정

@nestjs/serve-static (v2.2.2) 패키지를 설치한다. (참조)

$> yarn add @nestjs/serve-static

apps/dashboard/api/src/app/app.module.ts 에 static 환경을 설정한다. rootPath는 public 폴더를 만든다. exclude는 global prefix인 api를 제외한다. public 폴더에 index.html 을 만들어 본다. 향후 react기반 SPA 번들파일을 위치할 것이다. 

import { Module } from '@nestjs/common';
import { ServeStaticModule } from '@nestjs/serve-static';
import { join } from 'path';

import { DashboardApiAppService } from '@rnm/domain';

import { AppController } from './app.controller';

@Module({
  imports: [
    ServeStaticModule.forRoot({
      rootPath: join(__dirname, 'public'),
      exclude: ['/api*', '/dashboard/api*'],
    }),
  ],
  controllers: [AppController],
  providers: [DashboardApiAppService],
})
export class AppModule { }

// index.html
dashboard home

재실행 후, dashboard context path로 브라우져에서 확인한다. public/dashboard/assets/images 밑으로 샘플 이미지 복사

// public/dashboard/index.html 내역

<html>
  <head>
    <base href="dashboard" />
  </head>
  <body>
    welcome to dashboard! <img src="/dashboard/assets/images/dashboard.png" />
  </body>
</html>

Step-3) Micro Service의 응답을 위한 TCP MessagePattern 데코레이터 생성

apps/dashboard/api/src/app/app.controller.ts 에서 TCP 요청에 대한 응답 코드를 작성한다. TCP는 MessagePattern 데코레이터를 통해 응답하고 반환은 Primitive type, Promise, Observable 다 가능하다. 만일 Observable로 하면 gateway 측에서 Observable로 대응할 수 있다. 

• { cmd: 'dashboard-sum' } 은 gateway로부터 오는 Key이다.

import { Controller, Get } from '@nestjs/common';
import { MessagePattern } from '@nestjs/microservices';

import { DashboardApiAppService } from '@rnm/domain';
import { from, Observable } from 'rxjs';

@Controller()
export class AppController {
  constructor(private readonly appService: DashboardApiAppService) { }

  @Get()
  getData() {
    return this.appService.getData();
  }

  @MessagePattern({ cmd: 'dashboard-sum' })
  accumulate(data: number[]): Observable<number> {
    console.log('calling sum from dashboard....');
    const sum = data[0] + data[1] + data[2];
    return from([sum]);
  }
}

테스트는 Gateway까지 설정후 진행한다.

Step-4) Gateway 설정

• gateway
  • http server & static server
  • reverse proxy
  • api client

config.json 파일을 apps/gateway/api/src/environment  폴더밑으로 생성하고 하기와 같이 설정한다.

{
  "HTTP_PORT": 8000,
  "DASHBOARD": {
    "REVERSE_CONTEXT": "dashboard",
    "REVERSE_ADDRESS": "http://127.0.0.1:8001",
    "HTTP_PORT": 8001,
    "TCP_HOST": "0.0.0.0",
    "TCP_PORT": 8100,
    "GLOBAL_API_PREFIX": "/api"
  },
  "CONFIGURATION": {
    "REVERSE_CONTEXT": "configuration",
    "REVERSE_ADDRESS": "http://127.0.0.1:8002",
    "HTTP_PORT": 8002,
    "TCP_HOST": "0.0.0.0",
    "TCP_PORT": 8200,
    "GLOBAL_API_PREFIX": "/api"
  },
  "BACK_OFFICE": {
    "REVERSE_CONTEXT": "back-office",
    "REVERSE_ADDRESS": "http://127.0.0.1:8003",
    "HTTP_PORT": 8003,
    "TCP_HOST": "0.0.0.0",
    "TCP_PORT": 8300,
    "GLOBAL_API_PREFIX": "/api"
  }
}

apps/gateway/api/src/main.ts는 http server를 설정한다.

• global prefix를 설정하지 않고, 각 controller에서 설정한다.
• gateway api 호출은 "api/gateway"
• dashboard api 호출은 "api/dashboard". 다른 microservice도 동일하다.

// gateway의 main.ts
import { Logger } from '@nestjs/common';
import { NestFactory } from '@nestjs/core';

import { loadGatewayConfiguration } from '@rnm/shared';

import { AppModule } from './app/app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Load config.json file
  const config = loadGatewayConfiguration();

  const httpPort = config.HTTP_PORT || process.env.HTTP_PORT || 8000;
  await app.listen(httpPort, () => {
    Logger.log(`Listening at http://localhost:${httpPort}`);
  });
}

bootstrap();


// app.controller.ts
@Controller('api/gateway') <== 요기
export class AppController { ... }


// dashboard.controller.ts
@Controller('api/dashboard') <== 요기
export class DashboardController { ... }

apps/gateway/api/src/app/app.module.ts에서는 static file 서비스 폴더를 지정한다. reverse proxy를 위해 아래 3개의 exclude를 추가한다. web context처럼 사용될 것이다.

• dashboard
• configuration
• back-office

import { Module } from '@nestjs/common';
import { ServeStaticModule } from '@nestjs/serve-static';
import { join } from 'path';

import { GatewayApiAppService } from '@rnm/domain';

import { AppController } from './app.controller';
import { DashboardModule } from './dashboard/dashboard.module';

@Module({
  imports: [
    ServeStaticModule.forRoot({
      rootPath: join(__dirname, 'public'),
      exclude: [
        '/api/gateway*', '/api/dashboard*',
        '/dashboard*', '/configuration*', '/back-office*'
      ],
    }),
    DashboardModule
  ],
  controllers: [AppController],
  providers: [GatewayApiAppService]
})
export class AppModule { }

gateway, back-office, configuration, dashboard등에서 사용하는 api service 를 domain library로 옮기고, 명칭을 수정하여 import해서 사용한다. 예로 GatewayApiAppService, DashboardApiAppService와 같다. api service중에 라이브러리성으로 옮겨도 될 만한 것들을 domain 라이브러리 밑으로 작성한다. 예로 여러 곳에서 호출되는 공통 api의 경우 또는 업무적인 묶음단위로 api를 관리하고 싶을 경우이다. 해당 api를 라이브러리로 빼는 이유는 향후 다른 UI에서 사용하거나 또는 UI가 바뀌어도 업무적인 api에 변경이 없을 경우를 가정한 것이다.

Step-5) Gateway에 Micro Service쪽으로 reverse proxy 설정하기

micro service 인 dashboard, configuration, back-office는 자신의 http web server로써 static file을 서비스하고, tcp를 통해 api를 전송한다. 개발시에는 gateway를 구동하지 않고, micro service만 실행한다면 http를 통해 api 서비스 추가하면 될 것이다.

http-proxy-middleware를 설치한다. 

$>  yarn add http-proxy-middleware

다음으로 apps/gateway/api/src/app 폴더 밑으로 dashboard 폴더를 생성하고,  dashboard용 controller, service, module과 dashboard.proxy.ts 파일들을 생성한다.

• NestMiddleware를 상속받아 use를 구현한다.

// dashboard.proxy.ts ==> dashboard-proxy.middleware.ts 로 추후 명칭 변경됨
/* eslint-disable @typescript-eslint/no-explicit-any */
import { NestMiddleware, Logger } from '@nestjs/common';
import { loadGatewayConfiguration } from '@rnm/shared';
import { createProxyMiddleware } from 'http-proxy-middleware';

export class DashboardReverseProxyMiddleware implements NestMiddleware {
  private config = loadGatewayConfiguration();
  private proxyOptions = {
    target: this.config.DASHBOARD.REVERSE_ADDRESS,
    secure: false,
    onProxyReq: (proxyReq: any, req: any, res: any) => {
      Logger.debug(`[DashboardReverseProxyMiddleware]: Proxying ${req.method} request originally made to '${req.url}'`);
    },
  };
  private proxy: any = createProxyMiddleware(this.proxyOptions);

  use(req: any, res: any, next: () => void) {
    this.proxy(req, res, next);
  }
}

dashboard.module.ts에 다음과 같이 dashboard에 TCP로 접근하는 Client설정을 한다. 그리고 ProxyMiddleware를 설정한다.

import { MiddlewareConsumer, Module, NestModule, RequestMethod } from '@nestjs/common';
import { ClientsModule, Transport } from '@nestjs/microservices';

import { loadGatewayConfiguration } from '@rnm/shared';

import { DashboardController } from './dashboard.controller';
import { DashboardReverseProxyMiddleware } from './dashboard.proxy';
import { DashboardService } from './dashboard.service';

const config = loadGatewayConfiguration();

@Module({
  imports: [
    // dashboard쪽 api 호출을 위한 TCP Client Proxy 등록
    ClientsModule.register([
      {
        name: "DASHBOARD",
        transport: Transport.TCP,
        options: {
          host: config.DASHBOARD.TCP_HOST,
          port: config.DASHBOARD.TCP_PORT
        }
      }
    ])
  ],
  controllers: [DashboardController],
  providers: [DashboardService],
})
export class DashboardModule implements NestModule {
  // middleware 적용
  configure(consumer: MiddlewareConsumer) {
    consumer
      .apply(DashboardReverseProxyMiddleware)
      .forRoutes({ path: config.DASHBOARD.REVERSE_CONTEXT, method: RequestMethod.ALL });
  }
}

전체 코드 준비는 되었고, 다음 글에서는 MS Code에서 Debugging을 통해 위의 코드를 테스트해 본다.

소스: https://github.com/ysyun/rnm-stack/releases/tag/ms-2

<참조>

- 마이크로 서비스 설정 예제
https://github.com/danmt/microservices-basics

- reverse proxy 설정 예제

https://github.com/baumgarb/reverse-proxy-demo

- http-proxy-middleware 패키지

https://github.com/chimurai/http-proxy-middleware

애플리케이션이 계속 증가하고, 작은 변경에 기민하게 대응할 수 있고, 팀별 기술셋의 다양성을 수용하는 환경에서 Micro Service 개발/운영 환경을 구축해 본다. 

Micro Service

모노리틱환경의 단점을 극복한다. (참조)

• 작은 사이즈의 번들링 및 배포
• 지속적인 애플리케이션 추가
• 점점 늘어나는 접속자의 대응

Gateway Pattern 적용

• gateway 역할
  • api gateway: micro service의 api server와 TCP로 연결한다. 또는 중간에 Queue(Redis, RabbitMQ, Kafka)등을 두어서 구성해도 된다.
  • http server: login UI부분을 gateway에서 담당하고 JWT를 사용한다.
  • reverse proxy: micro service에 대한 web bundling file에 대한 reverse proxy 역할을 한다.
  • auth server: login시 auth 역할을 한다. 
• micro service 역할
  • api server: api는 TCP로 응답한다. 
  • http server: reverse proxy의 static 파일 대응을 한다. 

가용성을 위하여 gateway를 두개를 두어 용도별로 운영할 수 있다. 

BFF 패턴

Backend For Frontend 패턴 방식으로 개발한다. 

• Server는 NodeJS 기반으로 구성한다. 
• Client/Server 개발은 TypeScript로 통일한다.
• CSR(Client Side Rendering), SSR(Server Side Rendering)을 사용한다. 

개발 폴더 구성

멀티 애플리케이션을 mono repo에서 개발할 수 있는 폴더 구조를 정의한다. 

• apps 폴더
  • 4개의 애플리케이션이 존재한다.
• libs 폴더
  • page: 애플리케이션에 단위 화면 page를 개발하는 것이 아니라. page단위 별도 구성하고, application에서 조합한다.
  • ui: 모든 애플리케이션에서 사용하는 공통 ui
  • domain: core 업무에 대한 모든 내역들, 변경에 대해 유연하게 대처하기 위해 hexagonal architect방식으로 구성한다.
  • shared: common 라이브러리를 적용한다.

application의 libs 라이브러리 참조 방식

• api: api server역할이므로 주로 none visible한 라이브러리 참조
• web: ui 애플리케이션이므로 page, ui 라이브러도 참조

운영 폴더 구성

gateway와 micro services를 배포하는 폴더 구조를 정의한다. 

• bin: start/stop shell
• config: 환경파일
• lib: server 구동 번들링 파일
• public: static, web 번들링 파일들
• logs: 서버의 로그 파일

<참조>

- 마이크로 서비스 아키텍쳐 패턴 그리고 장/단점 (강추)

https://medium.com/design-microservices-architecture-with-patterns/monolithic-to-microservices-architecture-with-patterns-best-practices-a768272797b2

- 헥사고날 아키텍쳐

https://engineering-skcc.github.io/microservice%20inner%20achitecture/inner-architecture-2/

- BFF 패턴

https://giljae.medium.com/back-end-for-front-end-pattern-bff-4b73f29858d6

서버 사이드 렌더링을 위하여 Next.JS를 적용해 본다. Micro Frontend 전략을 활용하여 구성해 본다. 

• apps 밑에는 multi application이 존재한다.
• libs 밑에는 base 패키지들이 있다. base 패키지는 계속 추가될 수 있다.
• feature는 view와 domain이 존재한다.
  • view: 업무 UI 표현
  • domain: 업무 api 호출(react-query or graphql query) 및 결과 data model, custom Hook 기반
• page에서 view와 domain을 조합한다.
  • SSR에서 Next.JS 기반으로 진행시 feature의 domain을 통해 데이터를 다룬다. 

NextJS 개념

최신것이 항상 좋은 것이 아니다. SPA 프레임워크의 CSR(Client Side Rendering)만으로 개발하다가 예전의 JSP, ASP같은 SSR(Server Side Rendering)의 이점이 있었다. NextJS는 CSR, SSR 뿐만아니라 SSG(Static Site Generation)도 지원을 한다. 

• CSR
• SSR
• SSG

SSG를 위한 getStaticProps, getStaticPaths

• getStaticProps와 getStaticPaths는 async이다.
• getStaticProps, getStaticPaths에서 데이터를 가져오는 domain에 위치한 api를 호출한다. 
• getStaticPaths는 URL path에 따라 데이터가 변경될 때를 대비한다. 

SSR를 위한 getServerSideProps

• 서버에 요청때 마다 데이터를 맵핑하여 응답한다. 

Use Case

• Data가 즉각적으로 변화하는 Dashboard에는 CSR을 적용
• eCommerce 같은 경우 제품의 변경이 수시로 일어나지 않을 때 SSG 적용
• NodeJS위에 Isomorphic Application으로 간다. 

Frontend 개발 영역의 변경

• NodeJS 기반위에 페이지 개발의 주도권을 Frontend에서 갖는다.
• Backend API를 조합하는 역할을 수행한다. 

Rendering on the Web 위치

NextJS기반 애플리케이션은 이전 블로그에서 tube-ssr 애플리케이션을 생성하였다. 이를 기반으로 다음 글에서 로그인 화면을 만들어 보자 

<참조>

> Vercel의 NextJS 소개 영상

https://www.youtube.com/watch?v=eMwTEo6AjDc 

> CSR, SSR, SSG 의 흐름

https://wonit.tistory.com/361

> SPA의 SSR 지원

https://d2.naver.com/helloworld/7804182

> NextJS 기반 실습 시리즈

https://velog.io/@mskwon/next-js-page-static-generation

 props를 통해 하위 컴포넌트에 전파하는 것이 아니라 글로벌하게 접근할 수 있는 상태 저장소 사용을 위해 recoil을 사용한다. recoil 사용이유는 간결하며 Hook스타일 개발에 적합해 보인다.

Concept & API

1) Flexible shared state: 유연하게 상태를 공유해 보자

2) Derived data and queries: 파생으로 데이터를 만들고 조회할 수 있다.

3) App-wide state observation: 애플리케이션 전체에 걸쳐 변경을 관찰할 수 있다.

atom: 상태의 단위이다. 

useRecoilState: useState와 같이 read/write 가능

useSetRecoilState/useResetRecoilState: write-only

useRecoilValue: read-only, useRecoilValue(atom | selector)

selector: 파생상태를 갖거나, Async호출을 하고 싶을 경우

사용예) recoil-paint 소스

설치 및 설정

recoil을 설치한다. 

$> npm install recoil

ESLint에 recoil hook 을 설정한다. 루트의 .eslintrc.json 파일에 useRecoilCallback 을 설정한다. 

{
  "root": true,
  "ignorePatterns": ["**/*"],
  "plugins": ["@nrwl/nx"],
  "overrides": [
    {
      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
      "rules": {
        "@nrwl/nx/enforce-module-boundaries": [
          "error",
          {
            "enforceBuildableLibDependency": true,
            "allow": [],
            "depConstraints": [
              {
                "sourceTag": "*",
                "onlyDependOnLibsWithTags": ["*"]
              }
            ]
          }
        ],
        // 해당 하위 설정
        "react-hooks/exhaustive-deps": [
          "warn",
          {
            "additionalHooks": "useRecoilCallback"
          }
        ]
      }
    },
    {
      "files": ["*.ts", "*.tsx"],
      "extends": ["plugin:@nrwl/nx/typescript"],
      "rules": {}
    },
    {
      "files": ["*.js", "*.jsx"],
      "extends": ["plugin:@nrwl/nx/javascript"],
      "rules": {}
    }
  ]
}

apps/tube-csr/src/main.tsx 에 RecoilRoot를 설정한다. 

import { StrictMode } from 'react';
import * as ReactDOM from 'react-dom';

import { QueryClient, QueryClientProvider } from 'react-query';
import { ReactQueryDevtools } from 'react-query/devtools';
import { RecoilRoot } from 'recoil';

import App from './app/app';

const queryClient = new QueryClient();

ReactDOM.render(
  <StrictMode>
    <QueryClientProvider client={queryClient}>
      <RecoilRoot>
        <App />
      </RecoilRoot>
      <ReactQueryDevtools />
    </QueryClientProvider>
  </StrictMode>,
  document.getElementById('root')
);

state 패키지 구성 및 async 적용하기

libs/state 패키지를 생성한다. 

$> nx g @nrwl/react:lib state

UPDATE workspace.json
CREATE libs/state/project.json
CREATE libs/state/.eslintrc.json
CREATE libs/state/.babelrc
CREATE libs/state/README.md
CREATE libs/state/src/index.ts
CREATE libs/state/tsconfig.json
CREATE libs/state/tsconfig.lib.json
UPDATE tsconfig.base.json
CREATE libs/state/jest.config.js
CREATE libs/state/tsconfig.spec.json
CREATE libs/state/src/lib/state.module.scss
CREATE libs/state/src/lib/state.spec.tsx
CREATE libs/state/src/lib/state.tsx

core, state, api의 사용관계도. 원칙으로 상호 참조는 할 수 없고, 단방향 사용만 가능하다.

core와 api 패키지는 최하단에 위치하고, app(application)은 core,state, api모두를 이용한다. state는 core, api를 이용한다.

조건)

  - state는 selector를 통해 state 변경이 요구될 때만 aync ajax 호출이 있는 경우 api 패키지를 접근한다. 

  - api는 기본적으로 모든 ajax call을 처리한다.

State Custom Hook 을 만들어 기존의 useDogApi (기존 useDogList를 Api postfix로 명칭 변경)를 호출토록 한다. libs/state/src/lib 폴더에 dog.state.tsx를 만들고 다음과 같이 리팩토링한다. 

• api 패키지의 useDogApi()를 호출한다. 
• atom을 생성한다: dog 목록을 저장
• useEffect안에서 render이후 설정한다. useEffect를 사용하지 않으면 에러가 발생한다.

import { useEffect } from 'react';
import { atom, useRecoilState } from 'recoil';

import { useDogApi } from '@rnn-stack/api';

export const dogAtom = atom<string[]>({
  key: 'dogAtom',
  default: [],
});

export function useDogState(): [isLoading: boolean, dog: string[], error: Error | null] {
  const { isLoading, data, error } = useDogApi();
  const [dog, setDog] = useRecoilState(dogAtom);

  useEffect(() => {
    setDog(data?.message || []);
  }, [data?.message, setDog]);

  return [isLoading, dog, error];
}

react-query의 반환값을 같이 넘긴다. useDogState Hook을 apps/tube-csr/src/app/dog.tsx에 적용한다. 즉, 기존 useDogApi 코드를 리팩토링한다. 

import { List } from 'antd';
import { useDogState } from '@rnn-stack/state';

function DogList() {
  // recoil을 사용한 custom hook 적용
  const [isLoading, dog, error] = useDogState();

  if (isLoading || !dog) {
    return <span>loading...</span>;
  }

  if (error) {
    return <span>Error: {error.message}</span>;
  }

  return (
    <List
      header={<div>Header</div>}
      footer={<div>Footer</div>}
      bordered
      dataSource={dog}
      renderItem={(item: string) => <List.Item>{item}</List.Item>}
    />
  );
}

export default DogList;

위의 경우는 api호출후 서버 state에 결과를 저장하는 과정으로 react-query를 사용해도 되지만 예로 작성해 보았다. UI에 대한 state 저장은 소개 영상을 참조한다. 

https://www.youtube.com/watch?v=_ISAA_Jt9kI&t=1s 

소스: https://github.com/ysyun/rnn-stack/releases/tag/hh-5

<참조> 

> 한글: https://recoiljs.org/ko/

> Awesome Recoil: https://github.com/nikhil-malviya/awesome-recoil

> 2021 libraries & React state mangement

https://dev.to/sfeircode/my-go-to-react-libraries-for-2021-4k1

https://dev.to/workshub/state-management-battle-in-react-2021-hooks-redux-and-recoil-2am0

> State Management 분류

   Flux: Redux, zustand

   Atomic: Jotai, recoil

   Proxy: mobx, valtio, overmind

https://velog.io/@gtah2yk/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%83%81%ED%83%9C%EC%97%90-%EA%B4%80%ED%95%9C-%EC%A0%95%EB%A6%AC-%EA%B8%80

> Zustand vs Redux vs Jotai vs Recoil
소스: https://github.com/redhwannacef/youtube-tutorials/blob/main/react-state-management/README.md 

https://www.youtube.com/watch?v=BaEWIbxZKco 

react-query를 사용해 본다. 기능

• 캐싱 기능: fresh, fetching, stale, inactive, delete 상태
  • stale 상태가 받은 데이터를 캐싱한 상태이다
• QueryClientProvider 설정을 통해 useQuery 훅에 QueryClient를 전달한다.
• 조회
  • const { data, isLoading, status, error, isFetching } = useQuery(queryKey, queryFunction, options) 호출
  • queryKey는 문자열, 배열이 가능하고 캐싱하는 키로 사용한다.
  • queryFuction은 promise를 반환한다.
  • isLoading: 캐시데이터 없음. 데이터 요청중 true
  • isFetching: 캐시데이터 유무와 상관 없음. 데이터 요청중 true
• 생성/수정/삭제
  • const { mutate } = useMutation(queryFunction, options);
  • mutate(data, callbacks);
• 캐싱 무효화
  • const queryClient = useQueryClient();
  • queryClient.invalidateQuries(key);

설치 및 설정

react-query를 설치한다. 

$> npm install react-query

apps/tube-csr/src/main.tsx에 react-query의 provider를 설정한다. 그리고 ReactQuery의 DevTool도 설치한다. 

// main.tsx
import { StrictMode } from 'react';
import * as ReactDOM from 'react-dom';

import { QueryClient, QueryClientProvider } from 'react-query';
import { ReactQueryDevtools } from 'react-query/devtools';

import App from './app/app';

const queryClient = new QueryClient();

ReactDOM.render(
  <StrictMode>
    <QueryClientProvider client={queryClient}>
      <App />
      <ReactQueryDevtools />
    </QueryClientProvider>
  </StrictMode>,
  document.getElementById('root')
);

Custom Hook 만들기 및 api 패키지 구성

useQuery를 통해 custom Hook을 만들 수 있다. useQuery 사용시 Typescript에 대한 타입정의를 하자. api 패키지를 별도로 생성하고, dog.api.ts 파일을 생성한다. api custom Hook과 type 파일을 별도로 모아 둔다

$> nx g @nrwl/react:lib api

libs/api/src/lib 폴더 밑에 dog.api.ts 파일을 생성하고, react-query 의 custom Hook을 만든다. 

// dog.api.ts

import { useQuery } from 'react-query';

import { httpService } from '@rnn-stack/core';

export function useDogList() {
  return useQuery<{ message: string[]; status: string }, Error>('dog-list', () =>
    httpService
      .get('https://dog.ceo/api/breeds/list')
      .toPromise()
      .then((response: any) => response)
  );
}

dog.api.ts 파일을 libs/api/src/index.ts 에 export 추가한다. 

export * from './lib/api';

export * from './lib/api/dog.api';

이제 apps/tube-csr/src/app/dog.tsx 에서 사용해 본다. 기존 코드는 주석 처리하고 useDogList 라는 custom Hook을 사용한다. 

useState, useEffect 사용하지 않고 custom Hook을 별도로 작성하였다.

• 코드가 간결해 졌다.
• 역할 분리가 잘 되었다.
• api는 여러곳에서 공통으로 사용하므로 위치투명하게 api 패키지로 이동하였다.
  • import { useDogList } from "@rnn-stack/api";

// dog.tsx
import { List } from 'antd';
import { useDogList } from '@rnn-stack/api';

function DogList() {
  // const [dogList, setDogList] = useState<string[]>([]);
  // useEffect(() => {
    // httpService.get('https://dog.ceo/api/breeds/list').subscribe((response: any) => {
    //   console.log('axios observable response:', response);
    //   setDogList(response.message);
    // });
  // }, []);

  const { isLoading, data, error } = useDogList();

  if (isLoading || !data) {
    return <span>loading...</span>;
  }

  if (error) {
    return <span>Error: {error.message}</span>;
  }

  return (
    <List
      header={<div>Header</div>}
      footer={<div>Footer</div>}
      bordered
      dataSource={data.message}
      renderItem={(item: string) => <List.Item>{item}</List.Item>}
    />
  );
}

export default DogList;

현재는 각 라이브러리의 쓰임세와 구조에 대해서 보고 있다. Production에 사용하려면 좀 더 다음어야 할 것으로 보인다. 다음은 상태관리를 위하여 recoil을 적용해 보자.

소스: https://github.com/ysyun/rnn-stack/releases/tag/hh-4

<참조>

>ReactQuery에 대한 장점을 잘 설명준다. 

https://swoo1226.tistory.com/216

> react-query & typescript: https://tkdodo.eu/blog/react-query-and-type-script

>  react hook & rxjs: https://nils-mehlhorn.de/posts/react-hooks-rxjs

> hooks: https://twitter.com/tylermcginnis/status/1169667360795459584

• useState: Persist value between renders, trigger re-render
• useRef: Persist value between renders, no re-render
• useEffect: Side effects that run after render
• useReducer: useState in reducer pattern
• useMemo: Memoize value between renders
• useCallBack: Persist ref equality between renders

> hook lifecycle: https://medium.com/doctolib/how-to-replace-rxjs-observables-with-react-hooks-436dc1fbd324

React 외에 애플리케이션 개발을 위한 라이브러리를 설치한다.

UI Components

PrimeReact, EUI, MaterialUI, AntD 검토후 소스레벨 최신으로 반영하고 있고, 다양한 비즈니스 UX 대응 가능한 AntD를 선택한다.

// UI Component
$> yarn add antd

// Icon
$> yarn add @ant-design/icons

AntD의 스타일을 apps/tube-csr/src/styles.scss에 import 하고, app.tsx에 AntD의 Button 컴포넌트를 테스트 해본다. styles.scss는 글로벌 스타일로 apps/tube-csr/project.json 환경파일에 설정되어 있다.

// styles.scss
@import 'antd/dist/antd.css';


// app.tsx
import { Button } from 'antd';

import styles from './app.module.scss';

export function App() {
  return (
    <div className={styles.app}>
      <Button type="primary">Primary Button</Button>
      <Button>Default Button</Button>
      <Button type="dashed">Dashed Button</Button>
      <br />
      <Button type="text">Text Button</Button>
      <Button type="link">Link Button</Button>
    </div>
  );
}

export default App;

테스트 서버를 수행하고 확인해 본다. 

$> nx serve tube-csr

라우터 설치

CSR의 Router를 위한 react-router, react-router-dom을 설치한다.

$> yarn add react-router react-router-dom

Ajax를 위한 라이브러리 설치

Client/Server 모두 사용할 수 있는 Axios 를 설치하고 rxjs를 통해 api 를 제어할 것이다. 

$> yarn add axios

테스트 프로그램 작성

// dog.tsx
import { List } from 'antd';
import Axios, { AxiosResponse } from 'axios';
import { useEffect, useState } from 'react';

function DogList() {
  const [dogList, setDogList] = useState<string[]>([]);

  useEffect(() => {
    Axios.get('https://dog.ceo/api/breeds/list').then((result: AxiosResponse) => {
      setDogList(result.data.message);
    });
  }, []);

  return (
    <List
      header={<div>Header</div>}
      footer={<div>Footer</div>}
      bordered
      dataSource={dogList}
      renderItem={(item: string) => <List.Item>{item}</List.Item>}
    />
  );
}

export default DogList;


// app.tsx 에 추가
<DogList />

axios의 처리에 대해 rxjs 라이브러리를 같이 사용해 본다. 

$> yarn add rxjs

axios와 rxjs의 Observable을 사용한 라이브러리를 구현한다. 라이브러리는 NX의 libs 폴더 밑으로 생성한다. 

$> nx g @nrwl/react:lib core

// 실행을 하면 루트의 libs/core 밑으로 package가 생성된다.

libs/core/src밑으로 ajax 폴더를 생성하고 http.service.ts 파일을 생성한다. 

• Axios와 Observable을 조합
• Axios cancel 적용

// libs/core/src/lib/ajax/http.service.ts
/* eslint-disable @typescript-eslint/no-explicit-any */
import axios, {
  AxiosError,
  AxiosInstance,
  AxiosPromise,
  AxiosRequestConfig,
  AxiosResponse,
  CancelTokenSource,
} from 'axios';
import { Observable, Observer } from 'rxjs';

// sample url: https://jsonplaceholder.typicode.com/users
interface RequestArgs {
  method: HttpMethod;
  url: string;
  queryParams?: any;
  payload?: any;
}

enum HttpMethod {
  GET = 'GET',
  POST = 'POST',
  PUT = 'PUT',
  PATCH = 'PATCH',
  DELETE = 'DELETE',
}

export class HttpService {
  private httpClient!: AxiosInstance;
  private cancelTokenSource!: CancelTokenSource;
  private options!: AxiosRequestConfig;
  private completed!: boolean;

  get<T>(url: string, queryParams?: any, options: AxiosRequestConfig = {}): Observable<T> {
    this.setOptions(options);
    return this.executeRequest<T>({ method: HttpMethod.GET, url, queryParams });
  }

  post<T>(url: string, payload: any, options: AxiosRequestConfig = {}): Observable<T> {
    this.setOptions(options);
    return this.executeRequest<T>({
      method: HttpMethod.POST,
      url,
      payload,
    });
  }

  put<T>(url: string, payload: any, options: AxiosRequestConfig = {}): Observable<T> {
    this.setOptions(options);
    return this.executeRequest<T>({
      method: HttpMethod.PUT,
      url,
      payload,
    });
  }

  patch<T>(url: string, payload: any, options: AxiosRequestConfig = {}): Observable<T> {
    this.setOptions(options);
    return this.executeRequest<T>({
      method: HttpMethod.PATCH,
      url,
      payload,
    });
  }

  delete<T>(url: string, options: AxiosRequestConfig = {}): Observable<T> {
    this.setOptions(options);
    return this.executeRequest<T>({
      method: HttpMethod.DELETE,
      url,
    });
  }

  cancel(forcely = false): void {
    if (!this.completed || forcely) {
      this.cancelTokenSource.cancel(`${this.options.url} is aborted`);
    }
  }

  private setOptions(options: AxiosRequestConfig = {}): void {
    if (this.options) {
      this.options = { ...this.options, ...options };
    } else {
      this.options = options;
    }
    this.cancelTokenSource = axios.CancelToken.source();
    this.httpClient = axios.create({ ...options, cancelToken: this.cancelTokenSource.token });
    this.completed = false;
  }

  private executeRequest<T>(args: RequestArgs): Observable<T> {
    const { method, url, queryParams, payload } = args;
    let request: AxiosPromise<T>;
    switch (method) {
      case HttpMethod.GET:
        request = this.httpClient.get<T>(url, { params: queryParams });
        break;
      case HttpMethod.POST:
        request = this.httpClient.post<T>(url, payload);
        break;
      case HttpMethod.PUT:
        request = this.httpClient.put<T>(url, payload);
        break;
      case HttpMethod.PATCH:
        request = this.httpClient.patch<T>(url, payload);
        break;
      case HttpMethod.DELETE:
        request = this.httpClient.delete<T>(url);
        break;
    }

    return new Observable<T>((observer: Observer<T>) => {
      request
        .then((response: AxiosResponse) => {
          observer.next(response.data);
        })
        .catch((error: AxiosError | Error) => {
          this.cancel();
          observer.error(error);
          if (axios.isAxiosError(error)) {
            console.log(error.code);
            if (error.response) {
              console.log(error.response.data);
              console.log(error.response.status);
              console.log(error.response.headers);
            }
          } else {
            console.log(error.message);
          }
        })
        .finally(() => {
          this.completed = true;
          observer.complete();
        });
    });
  }
}

export const httpService = new HttpService();

다음으로 apps/tube-csr/src/app/dog.tsx에 테스트 코드를 입력한다. httpService를 import할 때 from 구문이 Local file system에 있다하더라도 마치 node_modules에서 import하는 것처럼 위치투명성을 보장한다. 이는 루트에 위치한 tsconfig.base.json 파일에 lib 생성할 때 자동 등록된다. 

// dog.tsx

import { useEffect, useState } from 'react';

import { List } from 'antd';
// import Axios, { AxiosResponse } from 'axios';

import { httpService } from '@rnn-stack/core';

function DogList() {
  const [dogList, setDogList] = useState<string[]>([]);

  useEffect(() => {
    httpService.get('https://dog.ceo/api/breeds/list').subscribe((response: any) => {
      console.log('axios observable response:', response);
      setDogList(response.message);
    });
    // Axios.get('https://dog.ceo/api/breeds/list').then((result: AxiosResponse) => {
    //   setDogList(result.data.message);
    // });
  }, []);

  return (
    <List
      header={<div>Header</div>}
      footer={<div>Footer</div>}
      bordered
      dataSource={dogList}
      renderItem={(item: string) => <List.Item>{item}</List.Item>}
    />
  );
}

export default DogList;

tsconfig.base.json

{
  "compileOnSave": false,
  "compilerOptions": {
    "rootDir": ".",
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "importHelpers": true,
    "target": "es2015",
    "module": "esnext",
    "lib": ["es2017", "dom"],
    "skipLibCheck": true,
    "skipDefaultLibCheck": true,
    "baseUrl": ".",
    "paths": {
      "@rnn-stack/core": ["libs/core/src/index.ts"]   <== 요놈
    }
  },
  "exclude": ["node_modules", "tmp"]
}

다음 포스팅에서 계속 진행...

소스: https://github.com/ysyun/rnn-stack/releases/tag/hh-3 

NX는 Angular/CLI를 확장하여 Typescript기반의 멀티 애플리케이션 및 노드 패키지개발을 위한 환경을 제공한다. 또한 Plugin 기반으로 React, NextJS, NestJS와 같은 프레임워크와 노드환경 확장을 통해 FullStack개발을 지원한다. 

목적

• Case1: SPA/CSR의 React 애플리케이션 생성 + NestJS 기반 노드서버 생성
• Case2: SSR을 위한 NextJS기반 애플리케이션 생성
• Case1과 2의 두가지 애플리케이션에 대해 비교 테스트 진행하여 성능 이점과 차이점을 비교한다.

로컬에 새로운 환경 구성하기

NodeJS기반 테스트 환경 구축시 NodeJS버전을 변경하며 사용할 수 있도록 Local PC에 nvm (Node Version Manager)를 설치한다. Windows는 관련 링크를 참조하여 설치한다.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash

NodeJS LTS버전을 nvm을 통해 설치하고 사용 설정한다. 

$> nvm install v14.18.0
$> nvm use 14.18.0

소스 폴더로 이동을 하면 지정한 node version으로 nvm을 통해 switching 하고 싶다면 폴더에 .nvmrc 파일을 생성하고 "14.18.0" 버전을 명시하고, 로그인 사용자 .zshrc 또는 .bashrc 에 하기 사항을 설정한다. Gist 소스 참조

#! /usr/bin/env zsh

# Ref: https://github.com/creationix/nvm#calling-nvm-use-automatically-in-a-directory-with-a-nvmrc-file
# place this after nvm initialization!

autoload -Uz add-zsh-hook

# Function: load-nvmrc
load-nvmrc() {
    local _CUR_NODE_VER="$(nvm version)"
    local _NVMRC_PATH="$(nvm_find_nvmrc)"

    if [[ -n "${_NVMRC_PATH}" ]]; then
        local _NVMRC_NODE_VER="$(nvm version "$(cat "${_NVMRC_PATH}")")"

        if [[ "${_NVMRC_NODE_VER}" == 'N/A' ]]; then
            local compcontext='yn:yes or no:(y n)'
            vared -cp "Install the unmet version ($(cat "${_NVMRC_PATH}")) in nvm (y/n) ?" _ANSWER
            if [[ "${_ANSWER}" =~ '^y(es)?$' ]] ; then
                nvm install
            fi
        elif [[ "${_NVMRC_NODE_VER}" != "${_CUR_NODE_VER}" ]]; then
            nvm use
        fi
    elif [[ "${_CUR_NODE_VER}" != "$(nvm version default)" ]]; then
        echo -e "Reverting to the default version in nvm"
        nvm use default
    fi
}

add-zsh-hook chpwd load-nvmrc
load-nvmrc

NX 개발환경 구성을 위한 글로벌 패키지를 설치한다. Typescript는 v4.3.5 이상을 사용한다.

$> npm i -g @angular/cli@latest
$> npm i -g @nrwl/cli@latest
$> npm i -g yarn@latest

NX 개발환경 생성하기

npx 명령으로 개발환경 생성. RNN Stack에서 RNN은 React NestJS NextJS 을 합친 것이다. React Application의 명칭은 "tube-csr" 이다.

반드시 latest 버전으로 설치한다. 

$> npx create-nx-workspace@latest

선택하기
  ✔ Workspace name (e.g., org name)     · rnn-stack
  ✔ What to create in the new workspace · react
  ✔ Application name                    · tube-csr
  ✔ Default stylesheet format           · scss
  ✔ Use Nx Cloud? (It's free and doesn't require registration.) · No
   
$> cd rnn-stack

"tube-csr" 애플리케이션을 위한 Node서버로 NestJS 플로그인를 설치하고, "tube-api" 이름으로 서버를 생성한다.

Nx의 NestJS 플러그인 설치
$> yarn add -D @nrwl/nest@latest

생성
$> nx generate @nrwl/nest:app tube-api

다음으로 NX의 NextJS 플러그인을 설치한다. NextJS Application은 "tube-ssr" 이다.

설치
$> yarn add -D @nrwl/next@latest

생성
$> nx generate @nrwl/next:app tube-ssr
또는
$> nx g @nrwl/next:app tube-ssr

✔ Which stylesheet format would you like to use? · scss

NextJS 애플리케이션을 설치하면 sass-node버전을 v5.0.0이 설치된다. v4.14.1로 변경 사용한다. 5.0으로 사용시 컴파일 오류 발생하여 향후 패치되면 버전 업그레이드 함.

$> npm uninstall node-sass
$> npm install -D node-sass@4.14.1

tube-ssr 애플리케이션의 개발 서버 포트는 4300 으로 변경한다. workspace.json의 "tube-ssr"의 serve options설정에 포트 정보를 수정한다.

Nx 환경파일 재구성

애플리케이션과 라이브러리를 많이 만들다 보면 rnn-stack/workspace.json 파일안에 설정이 계속 추가된다. 가독성을 위하여 애플리케이션(라이브러리 포함) Nx의 환경설정을 프로젝트별 별도 파일로 분리한다. 분리후에는 애플리케이션이나 라이브러리 생성시 자동으로 "project.json" 파일로 분리가 된다.

각 애플리케이션 root 폴더에 "project.json" 파일을 생성하고 workspace.json의 프로젝트별 설정 정보를 옮긴다. workspace.json에는 애플리케이션의 위치정보로 수정하면 컨벤션에 의해 project.json을 인지한다.

workspace.json은 애플리케이션 위치를 표현한다. 

테스트하기

"tube"라는 React 애플리케이션을 Dev Server기반으로 실행하고, "realtime"이라는 NextJS 프렘워크기반 노드 서버를 실행한다. 

• React Application: http://localhost:4200/ 
• NextJS Application: http://localhost:4300/

React Single Page Application
$> nx serve tube-csr

NextJS Application with Server
$> nx serve tube-ssr

Prettier 코드 포멧터 설정하기

MS Code 편집기를 기준으로 prettier를 설정한다. 

• rnn-stack 루트 폴더에 .prettierrc파일을 생성한다.
• MS Code를 위한 Prettier Plugin을 설치한다. 
• .vscode/settings.json 에 prettier 옵션을 설정한다. settings.json 파일이 존재하지 않다면 생성후 설정한다.
• .vscode/extensions.json의 recommandation으로 prettier를 설정한다.

.prettierrc 내역

{
    "printWidth": 120,
    "singleQuote": true,
    "useTabs": false,
    "tabWidth": 2,
    "semi": true,
    "bracketSpacing": true
}

. vscode/settings.json 내역

{
    "editor.formatOnPaste": true,
    "editor.formatOnType": true,
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "[typescript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[scss]": {
        "editor.suggest.insertMode": "replace",
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[html]": {
        "editor.suggest.insertMode": "replace",
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    }
}

.vscode/extensions.json 내역

{
  "recommendations": [
    "esbenp.prettier-vscode",
    "nrwl.angular-console",
    "firsttris.vscode-jest-runner",
    "dbaeumer.vscode-eslint"
  ]
}

소스

https://github.com/ysyun/rnn-stack/releases/tag/hh-2

참조

• Starting Next with Nx

리액트 프로젝트를 위해 조사해봐야할 항목에 대해서 정리해 본다. 하기 구성에 대해 소스레벨의 준비과정을 작성해 본다.

개발환경

• micro-frontend를 지원하는 환경
• mono-repo기반 multi application을 개발할 수 있는 환경
• Nx.dev for React
  • 멀티 애플리케이션 개발 및 애프리케이션별 번들링
  • 라이브러리의 위치 투명성 보장 및 배포

구조 설계

• 1Layer: 애플리케이션
  • Layout: Feature 를 다루는 영역을 분할
  • Feature: UI + Data-Access 를 조합하여 업무 단위 화면을 구성
• 2Layer: 업무 라이브러리
  • UI: Layout, Feature의 부분을 담당하는 업무 컴포넌트
  • Data-Access: API 호출 및 Data Caching
  • Data-Type: Frontend - Backend간 데이터 타입 및 vadliation
  • State: UI 상태 저장 및 전파
• 3Layer: 공용 라이브러
  • Component: 사용자 정의 요소 컴포넌트 및 랩퍼
  • Chart: 차트 및 랩퍼
  • Utils: 유틸리티들
• 4Layer: package.json 
  • AntD, PrimeReact, MaterialUI, Boostrap와 같은 CSS + Component Framework
  • Redux, Mobx, Recoil 과 같은 state
  • moment, date-fns 같은 date
  • immer 같은 immutable state 
  • react-use 같은 Hooks
  • react-query 같은 data api
  • rxjs 같은 reactiv library

고려 사항

• Elagant Code Base 유지
  • Code Convention
  • TSLint
  • Typescript
• Unit Test Code 
  • commit 전에 Unit Test 수행
• Loose Coupling을 위한 UI Biz Feature, UI Componnet, Library 관계 정립

to be continue...

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

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 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

백앤드 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에서 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

Angular v6부터 Web Components에 대한 지원으로 @angular/elements 기능이 추가되어 Custom HTML Tag을 만들 수 있도록 지원한다. 본 글은 해당 사이트의 글을 Nx.dev 환경과 통합하여 개발하는 과정을 설명한다. Nx 환경은 mono repository 기반으로 multi application을 개발 할 수 있는 환경을 제공한다. Angular/CLI기반이지만 Angular, React, Node.js 개발까지 하나의 Git Repository안에서 개발하고 번들링 할 수 있도록 지원한다. 따라서 micro frontend에서 multi application 개발 잇점을 갖는다. 

블로그 소스 [GitHub]

NX 환경 준비

Angular v9.* 

@angular/cli v9.1.6

RxJS v6.5.*

Typescript v3.8.*

NodeJS v12.16.*

Node Version Manager(nvm)를 통해 로컬환경에 여러 Node버전을 관리하자.

// NodeJS
$ nvm install 12.16.2
$ nvm alias default 12.16.2
$ nvm use 12.16.2

// Angular/CLI 최신버전 사용
$ npm i -g @angular/cli@latest
$ npm i -g @nrwl/cli@latest
$ npm i -g yarn@latest

// local 설치
$ yarn add

NX workspace를 생성한다. 

$ npx create-nx-workspace@latest
// 선택 및 입력
? Workspace name (e.g., org name)     micro-demo
? What to create in the new workspace angular [a workspace with a single Angular application]
? Application name                    app-container
? Default stylesheet format           SASS(.scss)  [ http://sass-lang.com   ]

Web Components 개발 환경 설정

@angular/elements 를 설치한다. 

$ yarn add @angular/elements

UI Component로 ng-antd v9.1.* 를 사용한다. yarn 이 아니라 angular/cli의 'ng' 명령을 사용한다. Yes와 sidemenu 형태 선택한다.

$ ng add ng-zorro-antd

선택하기 
? Enable icon dynamic loading [ Detail: https://ng.ant.design/components/icon/en ] Yes
? Set up custom theme file [ Detail: https://ng.ant.design/docs/customize-theme/en ] Yes
? Choose your locale code: en_US
? Choose template to create project: sidemenu

설치 후에 Nx workspace와 ng-zorro-antd의 불일치를 해결한다.

• apps/app-container/theme.less의 첫줄의 import 문구 수정
  • @import "../../../node_modules/ng-zorro-antd/ng-zorro-antd.less";
• apps/app-container/index.html의 root tag 수정
  • <app-root></app-root>

설정 수정후 실행을 하면 sidemenu가 있는 환경이 자동 셋업되어 아래와 같이 보인다. 자세한 설치방법은 사이트를 참조한다.

$ ng serve --open

Monitor Web Components 개발 및 번들링

monitor 애플리케이션을 신규 생성한다. 모니터 애플리케이션을 Web Components로 만들어 app-container 애플리케이션에서 동적으로 로딩해 본다. 

$ ng g app monitor

선택
? Which stylesheet format would you like to use? SASS(.scss)  [ http://sass-lang.com   ]
? Would you like to configure routing for this application? No

apps/monitor/src/app/app.component.html과 app.component.ts 를 변경한다. 

// app.component.html
{{title}} Application

// app.component.ts
import { Component, Input } from '@angular/core';

@Component({
  selector: 'micro-demo-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss'],
})
export class AppComponent {
  @Input() title = 'monitor';
}

apps/monitor/src/app/app.module.ts에서 Web Comopennts를 등록한다. 

import { BrowserModule } from '@angular/platform-browser';
import { NgModule, Injector } from '@angular/core';
import { createCustomElement } from '@angular/elements';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule],
  providers: [],
  // 동적으로 생성하므로 entryComponents에 등록
  entryComponents: [AppComponent],
  // 정적 bootstrap을 사용하지 않음
  // bootstrap: [AppComponent],
})
export class AppModule {
  constructor(private injector: Injector) {}

  ngDoBootstrap() {
    // createCustomElement를 통해 Web Components 스펙에 맞는 객체로 반환
    const monitorApp = createCustomElement(AppComponent, { injector: this.injector });
    // browser window객체에 잇는 customElements를 통해 Web Components 등록
    customElements.define('monitor-app', monitorApp);
    // 사용방법: @Input() title이 있으므로 attribute 설정가능
    // <monitor-app title="Monitor Application"></monitor-app>
  }
}

monitor 애플리케이션을 번들링하면 여러개의 파일로 나오는데 번들링 파일을 최소화한다. ngDoBootstrap() 은 정적 bootstrap이 아닌 실행타임에 외부 컴포넌트를 동적으로 로딩할 때 애플케이션 root를 결정할 수 있게 한다. ngDoBootstrap에 대한 설명을 참조하자.

$ ng build monitor --prod --output-hashing=none

수행할 경우 main, polyfill, runtime등의 파일이 생성된다. 파일 최소화를 위해 ngx-build-plus 패키지를 이용한다. 

ng add 명령으로 ngx-build-plus를 설치하고 애플리케이션은 monitor를 지정한다. 

$ ng add ngx-build-plus --project=monitor

ng add 로 수행을 하면 angular.json 파일의 설정을 자동으로 적용해 준다. builder의 명령어를 자동 수정함.

    "monitor": {
      "projectType": "application",
      "schematics": {
        "@nrwl/angular:component": {
          "style": "scss"
        }
      },
      "root": "apps/monitor",
      "sourceRoot": "apps/monitor/src",
      "prefix": "micro-demo",
      "architect": {
        "build": {
          "builder": "ngx-build-plus:browser",  <== builder가 자동 변경됨
          "options": {
          ...
          

다시 명령으로 monitor 애플리케이션을 번들링한다. ngx-build-plus로 확장한 옵션인 --single-bundle true를 추가한다.

$ ng build monitor --prod --output-hashing=none --single-bundle true

main과 polyfill을 합쳐주는 스크립트를 등록한다. Mac/Linux기준 명령이다. micro-demo 폴더 밑에 buildSingle.sh 파일을 생성한다. 번들링파일 합치는 명령을 넣는다.  

#!/bin/sh
ng build monitor --prod --output-hashing=none --single-bundle true && cat dist/apps/monitor/main-es5.js dist/apps/monitor/polyfills-es5.js > apps/app-container/src/assets/monitor-es5.js

buildSingle.sh를 수행한 결과 파일은 app-container의 apps/app-container/src/assets/monitor-es5.js 쪽으로 copy된다.

컨테이너 애플리케이션에서 동적로딩

Web Components 스펙을 기준으로 monitor 애플리케이션을 번들링 했기때문에 프레임워크의 종류에 상관없이 <monitor-app> 태그를 사용할 수 있다. 정적으로 사용하는 방법을 살펴보자.

apps/app-container/src/app/pages/welcome/welcome.component.ts에서 monitor-es5.js파일을 import한다. 

import { Component, OnInit } from '@angular/core';
// 소스 import
import '../../../assets/monitor-es5.js';  

@Component({
  selector: 'app-welcome',
  templateUrl: './welcome.component.html',
  styleUrls: ['./welcome.component.scss']
})
export class WelcomeComponent implements OnInit {

  constructor() { }

  ngOnInit() {
  }

}

테스트를 위해 welcome.component.html 에 <monitor-app>태그를 설정해 보자. 

<monitor-app title="Hi Monitor"></monitor-app>

여기까지하고 수행을 하면 <monitor-app> 태그를 해석할 수 없다고 Angular가 에러를 뱃는다. <monitor-app> 은 Angular가 해석하는 것이 아니라 Browser에서 해석되는 Web Components이므로 무시하도록 welcome.module.ts에 CUSTOM_ELEMENTS_SCHEMA를 설정한다. 

import { NgModule, CUSTOM_ELEMENTS_SCHEMA } from '@angular/core';
import { WelcomeRoutingModule } from './welcome-routing.module';
import { WelcomeComponent } from './welcome.component';

@NgModule({
  imports: [WelcomeRoutingModule],
  declarations: [WelcomeComponent],
  schemas: [CUSTOM_ELEMENTS_SCHEMA],
  exports: [WelcomeComponent]
})
export class WelcomeModule { }

<monitor-app>태그를 설정하지 않고 Javascript를 이용하여 로딩해 본다. 

apps/app-container/src/app/monitor.service.ts 파일을 생성한다. 

• monitor-es5.js 파일 동적 로딩
• <monitor-app> DOM 동적 추가

import { Injectable } from '@angular/core';

@Injectable({providedIn: 'root'})
export class MonitorLoaderService {
  loaded = false;

  constructor() { }

  // script 동적 로딩
  loadMonitorScript(): void {
    if (this.loaded) {
      return;
    }

    const script = document.createElement('script');
    script.src = 'assets/monitor-es5.js';
    document.body.appendChild(script);
    this.loaded = true;
  }

  // <monitor-app> 태그 추가
  addMonitorApp(): void {
    const tile = document.createElement('monitor-app');
    // @Input() 내용은 setAttribute로 추가 가능
    tile.setAttribute('title', 'Dynamic Load Monitor');

    const content = document.getElementById('content');
    content.appendChild(tile);
  }
}

 위의 경우 monitor-es5.js 파일을 별도로 다운로드받아 동적 로딩을 수행한다. 

공통 파일 빼고 번들링하기

만일 app-container과 monitor 에서 사용하는 공통 패키지의 버전이 같다면, app-container 애플리케이션과 monitor 애플리케이션이 공통으로 사용하는 파일중, monitor 애플리케이션을 번들링할 때 공통파일을 제거하는 방법에 대해 알아보자. 제거를 통해 monitor 애플리케이션의 번들링 사이즈를 줄일 수 있다. 이는 Network payload time을 줄여주는 결과를 갖는다. 

ngx-build-plus를 이용해서 @angular/cli의 webpack externals 을 자동 생성한다. (참조)

$ ng g ngx-build-plus:externals --project monitor

수행을 하면 angular.json 파일에 별도 환경이 추가되고, apps/monitor/webpack.externals.js 파일이 생성된다. angular.json 내용중

"node_modules/@angular/elements/bundles/elements.umd.js", 내용은 제거한다. elements.umd.js를 공통파일로 빼서 사용하는데 오류가 있다. 

angular.json의 monitor 애플리케이션으 "scripts" 설정 내역 => scripts.js 파일에 설정한 *.umd.js 파일을 합친다.

// angular.json 내의 monitor 애플리케이션 설정
// "scripts"에 externals로 참조하는 파일 설정이 자동으로 입력되어 진다.
    "monitor": {
      "projectType": "application",
      "schematics": {
        "@nrwl/angular:component": {
          "style": "scss"
        }
      },
      "root": "apps/monitor",
      "sourceRoot": "apps/monitor/src",
      "prefix": "micro-demo",
      "architect": {
        "build": {
          "builder": "ngx-build-plus:browser",
          "options": {
            "outputPath": "dist/apps/monitor",
            "index": "apps/monitor/src/index.html",
            "main": "apps/monitor/src/main.ts",
            "polyfills": "apps/monitor/src/polyfills.ts",
            "tsConfig": "apps/monitor/tsconfig.app.json",
            "aot": true,
            "assets": [
              "apps/monitor/src/favicon.ico",
              "apps/monitor/src/assets"
            ],
            "styles": [
              "apps/monitor/src/styles.scss"
            ],
            "scripts": [
              "node_modules/rxjs/bundles/rxjs.umd.js",
              "node_modules/@angular/core/bundles/core.umd.js",
              "node_modules/@angular/common/bundles/common.umd.js",
              "node_modules/@angular/common/bundles/common-http.umd.js",
              "node_modules/@angular/compiler/bundles/compiler.umd.js",
              "node_modules/@angular/elements/bundles/elements.umd.js", // <-- 제거한다
              "node_modules/@angular/platform-browser/bundles/platform-browser.umd.js",
              "node_modules/@angular/platform-browser-dynamic/bundles/platform-browser-dynamic.umd.js"
            ]
          },

apps/monitor/webpack.externals.js  파일내역에서 ng.elements도 주석처리한다.  => monitor-es5.js 파일에서 제거되는 파일목록이다.

const webpack = require('webpack');

module.exports = {
    "externals": {
        "rxjs": "rxjs",
        "@angular/core": "ng.core",
        "@angular/common": "ng.common",
        "@angular/common/http": "ng.common.http",
        "@angular/platform-browser": "ng.platformBrowser",
        "@angular/platform-browser-dynamic": "ng.platformBrowserDynamic",
        "@angular/compiler": "ng.compiler",
        // "@angular/elements": "ng.elements",  <-- 주석처리한다.

        // Uncomment and add to scripts in angular.json if needed
        // "@angular/router": "ng.router",
        // "@angular/forms": "ng.forms"
    }
}

buildSingle.sh 내용을 수정한다. scripts.js 파일은 window.ng.core 또는 window.ng.common과 같은 global 객체가 담겨있는 파일이다. 따라서 scripts.js는 app-container 애플리케이션에서 최초 한번만 로딩하면 되고, 이후 monitor 애플리케이션과 같은 web components는 번들 파일은 자신의 내용만을 포함한다.

monitor app size including common library  - 129KB

monitor app size excluding common library - 19KB

#!/bin/sh
ng build monitor --prod --extra-webpack-config=apps/monitor/webpack.externals.js --output-hashing=none --single-bundle true && cat dist/apps/monitor/main-es5.js dist/apps/monitor/polyfill-es5.js > apps/app-container/src/assets/monitor-es5.js
cat dist/apps/monitor/scripts.js > apps/app-container/src/assets/scripts.js

scripts.js 파일은 angular.json 의 app-container 애플리케이션 "scripts" 옵션에 추가한다. 

    "app-container": {
      "projectType": "application",
      "schematics": {
        "@nrwl/angular:component": {
          "style": "scss"
        }
      },
      "root": "apps/app-container",
      "sourceRoot": "apps/app-container/src",
      "prefix": "micro-demo",
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "outputPath": "dist/apps/app-container",
            "index": "apps/app-container/src/index.html",
            "main": "apps/app-container/src/main.ts",
            "polyfills": "apps/app-container/src/polyfills.ts",
            "tsConfig": "apps/app-container/tsconfig.app.json",
            "aot": true,
            "assets": [
              "apps/app-container/src/favicon.ico",
              "apps/app-container/src/assets",
              {
                "glob": "**/*",
                "input": "./node_modules/@ant-design/icons-angular/src/inline-svg/",
                "output": "/assets/"
              }
            ],
            "styles": [
              "apps/app-container/src/theme.less",
              "apps/app-container/src/styles.scss"
            ],
            "scripts": [
              "apps/app-container/src/assets/scripts.js"  <== 추가
            ]
          },

수행하면 네트워크에서 scripts.js 파일은 한번만 로딩되고, 이후 다양한 Web Components들은 자신의 애플리케이션 내역만 포함한 파일로 번들링하여 파일 사이즈를 줄일 수 있다. (참조)

참조

https://www.angulararchitects.io/aktuelles/angular-elements-part-i/

https://ng.ant.design/docs/getting-started/en

https://medium.com/angular-in-depth/how-to-manually-bootstrap-an-angular-application-9a36ccf86429

https://www.angulararchitects.io/aktuelles/your-options-for-building-angular-elements/

https://indepth.dev/tiny-angular-application-projects-in-nx-workspaces/

https://nstudio.io/blog/custom-web-elements-with-angular-and-react

마이크로 프론트앤드는 마이크로 서비스처럼 전체 화면을 작동할 수 있는 단위로 나누어 개발한 후 서로 조립하는 방식이다. 여기서 작동 단위에 사용된 프론트앤드 프레임워크로 Angular 이든, React 또는 Vue 또는 Vanilla 자바스크립트에 상관하지 않고 조합 가능한 방법을 제공한다. 본글에서는 마이크로 프론트앤드 개발 방법중 Angular 프레임워크를 사용하면서 Web Components를 사용한 통합 방법에 대핸 알아보자.

Micro Frontend 개념

마이크로 프론앤드 개념으로 개발을 하는 잇점은 대규모 엔터프라이즈 애플리케이션을 개발한다고 가정할 때, 각 팀별 또는 업무단위에 대해 Backend + Frontend 개발 후 통합하는 이슈를 줄일 수 있다. 

• 작고, 응집력 있고 유지보수성을 가지는 코드베이스를 가질 수 있다. (Simple, decoupled codebase)
• 분리배포가 용이하고, 자율적인 팀 조직운영이 수월해진다. (Independent deployment, Autonomous teams)
• 프론트앤드 개발을 점진적 업그레이드 또는 재작성이 수월해진다. (Incremental upgrades)

하지만 단점도 존재한다. 

• 배포 번들 사이즈가 커질 수 있다. (Payload size)
• 서로간의 개발 환경의 차이로 복잡도가 올라간다. (Environment differences) 
• 운영 및 거버넌스도 당연히 복잡해진다. (Operational governance complexity)

Thoughtworks의 Technology Radar에 의하면 Micro Frontend가 현재 적용 가능한(Adapt) 상황이다.

마틴 파울러의 글 (또는 번역글) 에서 잘 설명을 하고 있으니 참조하자.

Micro Frontend 통합 방법

마이크로 프론앤드 방식으로 개발 후 각 단위 애플리케이션을 어떻게 통합할지 고려해야 한다. 통합할 때는 각 화면을 조합하는 컨테이너 애플리케이션이 있고, 그 하부에 들어가는 단위 애플리케이션이 존재한다. (참조)

• 서버 템플릿 통합: 각 서버로 html 템플릿을 요청하고, 최종 응답서버에서 각 템플릿을 조합해서 응답을 보냄
  • 서버측에서 최종 화면을 조합한다.
• 빌드타임 통합: 단위 애플리케이션을 패키지로 배포하고, package.json에 명시한 후 컨테이너 애플리케이션에서 import하여 사용하는 방법
  • 각 애플리케이션에 대한 런타임 대응이 안된다. 
  • 애플리케이션을 릴리즈하고 최종 애플리케이션에서 컴파일해야 한다. 
• iframe 통합: 전통적인 방식이면서 가장 쉬운 방식이다.
  • 애플리케이션 통합의 유연성 높다.
  • 애플리케이션의 기술 종속성이 없다. 
  • routing, history, deep-link같은 것이 복잡해질 수 있다. 
  • 컨테이너 애플리케이션과 iframe에 들어가는 단위 애플리케이션간의 통신규약도 필요하다. 
  • UX가 iframe안에 갇히기 때문에 어색한 UI 표현을 가질 수 있다. 
• Javascript를 통한 런타임 통합: iframe과 달리 유연한 통합이 가능하다. 현실적으로 가장 많이 사용하는 방식이다.
  • 컨테이너 애플리케이션을 단위 애플리케이션 번들을 <script> 태그를 통합 다운로드 받고
  • 약속된 초기화 메소드를 호출한다.
  • 클라이언트측에서 (브라우져) 통합한다.
• Web Components를 통한 통합: HTML 커스텀 엘리먼트를 통한 통합방법, static, runtime 통합 둘 다 가능함.
  • Javascript를 통한 런타임 통합과 유사하지만 "The web component way"를 지향한다.
  • 클라이언트측에서 (브라우져) 통합한다.

Mirco Frontend 통합할 때 몇가지 고려사항

• UI 스타일 일관성은 UI Component Library를 만들어 대응한다.
  • 한번에 만들지 말고, 중복코드가 발생하는 지점에서 만들고
  • 코드 일관성을 유지하는 팀이 수행한다. 
• 어플리케이션 통신은 Custom events를 사용한다.
  • 커스텀 이벤트를 위해 PubSubJS를 고려해 보자.
  • 호출시 URL 라우팅에 넘기기
• 백앤드 호출 API 구성
  • BFF(Backend for Frontend Pattern) 패턴으로 프론트앤드 전용 API를 갖는다. 
  • 별도의 데이터베이스를 가질 수도 있다.
  • 로그인은 인증 정보는 통합하는 Container가 소유한다. 

참조

https://micro-frontends.org/

https://martinfowler.com/articles/micro-frontends.html

번역글: https://medium.com/@juyeon.kate/micro-frontends-%EB%B2%88%EC%97%AD%EA%B8%80-1-5-29c80baf5df

https://www.thoughtworks.com/radar/techniques/micro-frontends

https://www.angulararchitects.io/aktuelles/angular-elements-part-i/

React를 해야하지 접근했다 다시 놓고, 접근했다 다시 놓고 여러번의 시도를 하면서 이번에도? 생각할 수 있지만 이제는 정말 필요에 의해서 해야겠다는 생각이 든다. Angular를 할 수록 다른 것을 써봐야겠다는 욕구가 더 강해지고, 앞으로 개발할 소프트웨어에 어느 것이 더 적합할지 판단하기 위해 React를 다시 들여다 보고 있다. 그래서 Rethinkg React이지만 그속의 개념을 암기용으로 간단히 정리해 본다. 

ReactDom 

ReactDom은 Real DOM에 React Element 이 업데이트 하는 것을 관리한다.

SPA 구성할 때 ReactDOM.render(element, selector) 한번만 호출한다.

JSX

JSX는 React Element이다.

JSX를 React,createElement(type, properties, children)으로 쓸 수도 있다.

JSX의 attributes와 children은 "props" 객체를 통해 컴포넌트로 전달된다.

Component & props

컴포넌트는 SPA기반 개발의 경우 UI를 독립적으로 쪼개고, 격리시켜서 개발할 수 있고, 재사용 가능한  단위이다.

컴포넌트는 props를 가진다. props는 read only 이다.

컴포넌트는 순수함수로(Pure Function)로 컴포넌트를 만들 수 있다. 순수함수의 argument로 자동 전달된다.

컴포넌트는 ES6의 class 로 정의할 수 있다. 

컴포넌트는 데이터를 맵핑해서 JSX 조각을 리턴할 뿐이다. (순수함수는 JSX조합 리턴, 클래스 컴포넌트는 render메소드에서 JSX조합 리턴)

props 객체는 컴포넌트를 조합할(Composition) 때 하위 컴포넌트로 값을 내려 보낼수도 있는 객체이다. 

props 객체는 컴포넌트 -> 컴포넌트로의 값 전달 단위이다. Data flow Down => Top-Down unidirection flow

state가 있으면 stateful 컴포넌트, props만 사용하면 stateless 컴포넌트이다.

State & LifeCycle

Local state는 컴포넌트내부에서 DOM과 대화할 수 있는 유일한 수단이다.

Local state에 대해 컴포넌트안에서 값을 변경하고 JSX에서 반영한다. 

Local state는 setState의 Async 호출은 컴포넌트의 render()를 재수행토록 한다.

this.state 객체 값변경은 반드시 setState만을 통해 수행한다. 즉, this.state 값변경의 화면의 업데이트를 위한 것이다.

this.state와 this.props의 값은 Async하게 바뀐다. 

   - setState할 때 this.state값을 개별적으로 업데이트하면 변경된 값만 반영된다. 

   - setState안에서 this.state와 this.props를 사용할 경우 (state, props) => { ... } 함수를 등록하여 사용한다. 이때 첫번째 인자인 state는 이전 state 객체값이다. 

LifeCycle을 통해 업데이트 하는 시점을 잡는다. 컴포넌트 시작 componentDidMount, 종료되기전 componentWillUnmount

class Clock extends React.Component {
  constructor(props) {
    super(props);
    this.state = {date: new Date()};
  }

  componentDidMount() {
    this.timerID = setInterval(
      () => this.tick(),
      1000
    );
  }

  componentWillUnmount() {
    clearInterval(this.timerID);
  }

  tick() {
    this.setState({
      date: new Date()
    });
  }

  render() {
    return (
      <div>
        <h1>Hello, world!</h1>
        <h2>It is {this.state.date.toLocaleTimeString()}.</h2>
      </div>
    );
  }
}

ReactDOM.render(
  <Clock />,
  document.getElementById('root')
);

이벤트 처리

이벤트 핸들러는 JSX안에서 함수 형태로 전달한다. 

함수 호출이 아닌, 함수를 서절하는 것이므로 preventDefault 하기위해 false를 리턴할 수 없는 구조이다. preventDefault()를 명시적으로 호출한다. 

React Element는 HTML의 이벤트가 아닌 SyntheticEvent를 사용해서 cross-browser 호환성을 고민할 필요가 없다.

function ActionLink() {
  function handleClick(e) {
    e.preventDefault();
    console.log('The link was clicked.');
  }

  return (
    <a href="#" onClick={handleClick}>
      Click me
    </a>
  );
}

TypeScript 방식의 경우 

• { (params) => this.method(params) }
• { this.method.bind(this, params) }

import React, { Component } from 'react';

interface State {
    isToggleOn: boolean;
}

export default class App2 extends Component<{}, State> {
    state: State = { isToggleOn: true };
    render() {
        return <button onClick={() => this.handleClick()}>{this.state.isToggleOn ? 'ON' : 'OFF'}</button>;
    }

    private handleClick() {
        this.setState(state => ({
            isToggleOn: !state.isToggleOn
        }));
    }
}

조건이 맞을 때 화면 렌더링 (Conditional Rendering)

{expression} 을 통해 JSX 를 리턴할 수 있다. 이를 위해 Short curcuit, 삼항식, 고차함수 사용가능. expression 이니깐...

expression의 리턴값이 null이면 화면 렌더링을 하지 않는다. 이때는 render가 호출안되고 componentDidUpdate만 호출된다.

Lists 와 Keys

JSX map의 리턴으로 받은 JSX List를 {[JSX, JSX, JSX]}으로도 화면 렌더링을 할 수 있다. 

map list할 때는 특별한 key attribute를 list element에 설정을 해야한다. 그래야 warning 안남, map에서 반드시 key 사용하기

Key는 아이템의 변경을 체크하는데 사용된다. key값은 unique해야 한다. map에서 index를 사용하지 말고 별도의 값을 사용하자

Key는 한번 순수함수 컴포넌트로 맵핑한 해당 컴포넌트에 할당한다. 

Key는 array안에서만 Unique하면 된다.

props.key는 map list에 예약 attribute이니 일반 컴포넌트에서 props로 key를 사용하지 말자

import React, { Component } from 'react';

// key설정하지 않고 반복하는 React Element
const ListItem = ({ value }) => <li>{value}</li>;
const numbers = [1, 2, 3, 4];
const List = ({ isToggleOn }) => {
    return isToggleOn ? (
        <ul>
            // map을 embedding했다. expression이니깐 당연히 가능
            {numbers.map((number, index) => (
                // 반복되는 React Element에 key를 설정한다. 
                <ListItem key={number.toString()} value={number} />
            ))}
        </ul>
    ) : (
        <div>There is no list.</div>
    );
};

interface State {
    isToggleOn: boolean;
}
export default class App2 extends Component<{}, State> {
    state: State = { isToggleOn: false };
    render() {
        return (
            <>
                <button onClick={() => this.handleClick()}>{this.state.isToggleOn ? 'ON' : 'OFF'}</button>
                <List isToggleOn={this.state.isToggleOn} />
            </>
        );
    }

    private handleClick() {
        this.setState(state => ({
            isToggleOn: !state.isToggleOn
        }));
    }
}

Forms 

form elements인 <input>, <textarea>, <select> 같은 것은 자신의 state를 가지고, 사용자 input을 기반으로 state를 업데이트한다.

React에 의해 값이 제어되는 input form element를 controlled component라 한다.

<select value="state value"> <option/> ... </select> 로 root <select>에서 value를 selected attribute로 대치한다. 

import React, { Component } from 'react';

interface State {
    value: string;
}
export default class App2 extends Component {
    state: State = { value: '0' };

    render() {
        return (
            <form onSubmit={this.handleSubmit.bind(this)}>
                <select value={this.state.value} onChange={this.handleChange.bind(this)}>
                    <option value="1">1</option>
                    <option value="2">2</option>
                    <option value="3">3</option>
                </select>
            </form>
        );
    }

    private handleSubmit(event) {
        event.preventDefault();
    }

    private handleChange(event) {
        this.setState({ value: event.target.value });
    }
}

<input type="file"> is uncotrolled component 이다. 

여러개의 input을 다룰때는 input 태그이 name을 통해 setState에 값을 할당한다.

setState는 부분적인 state를 현재 state에 합친다. 

Formik같은 패키지를 써보자.

Composition vs Inheritance

React는 컴폰넌트사용에서 Composition을 추천한다. 

props.children를 사용하거나, props를 통해 함수 컴포넌트를 전달할 수 있다. props통해 함수를 전달할 수 있음. (Lifting state up 참조)

// props.children을 사용하여 composition
function FancyBorder(props) {
  return (
    <div className={'FancyBorder FancyBorder-' + props.color}>
      {props.children}
    </div>
  );
}

function WelcomeDialog() {
  return (
    <FancyBorder color="blue">
      <h1 className="Dialog-title">
        Welcome
      </h1>
      <p className="Dialog-message">
        Thank you for visiting our spacecraft!
      </p>
    </FancyBorder>
  );
}

// props를 통해 컴포넌트를 전달하여 composition
function SplitPane(props) {
  return (
    <div className="SplitPane">
      <div className="SplitPane-left">
        {props.left}
      </div>
      <div className="SplitPane-right">
        {props.right}
      </div>
    </div>
  );
}

function App() {
  return (
    <SplitPane
      left={
        <Contacts />
      }
      right={
        <Chat />
      } />
  );
}

참조

- reactjs.org

두번째 Multi Application에 대한 Plugin 방식을 구성 테스트해 보자.

Library기반 Plugin 파일 만들기

플랫폼에 있는 플러그인이 아니라 플랫폼과 별개의 서비스에서 운영되는 플로그인을 플랫폼상에 렌더링하기 위해서는 UMD(Universal Module Definition) 방식으로 플러그인이 번들링 되어야 한다. UMD에 대해서는 본 블로그의 글을 참조한다.

$ ng g library plugin2 --publishable

plugin2 로 별도 번들링이 가능한 라이브러리 파일을 생성한다. 최종 npm scope를 jm으로 주었기 때문에 npm으로 설치했을 때 node_modules최종 명칭은 @jm/plugin2가 된다. libs/plugins/package.json의 설정 참조. build가 되는지 실행해 본다.

$ ng build plugin2

dist/libs/plugin2에 npm repository로 publish할 수 있는 형태의 다양한 포멧으로 번들링이 되었다. 해당 번들링은 ng-packagr를 기본으로 한 Angular Package Format에 따른다.

plugin2 라이브러리에 plugin2라는 이름의 컴포넌트를 생성하고 여기에 ngx-echart를 사용하는 샘플을 넣어보자.

// 컴포넌트 생성
$ ng g component plugin2 --project=plugin2

// echart 관련 라이브러리 및 echart angular wrapper 설치
$ npm i -S echarts ngx-echarts
$ npm i -D @types/echarts

plugin2/plugin2.component.html과 .ts에 ngx-echart의 예제 내용을 첨부한다. Plugin2Module에 bootstrap에 Plugin2Component를 설정한다.

// plugin2.component.html
<div echarts [options]="options" class="demo-chart"></div>

// plugin2.component.ts 
options 내용 설정: https://xieziyu.github.io/ngx-echarts/#/usage/basic 참조

// plugin2.module.ts
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { NgxEchartsModule } from 'ngx-echarts';

import { Plugin2Component } from './plugin2/plugin2.component';

@NgModule({
  declarations: [Plugin2Component],
  imports: [
    CommonModule,
    NgxEchartsModule
  ],
  exports: [
    Plugin2Component
  ],
  bootstrap: [
    Plugin2Component
  ]
})
export class Plugin2Module {}

plugin2 컴포넌트를 사용하는 별도 애플리케이션을 생성해 보자.

별도 애플리케이션 생성하여 Plugin2 테스트 하기

Multi Application을 가정하여 Plugin2를 사용하는 App2 애플리케이션을 생성하여 Plugin2가 잘 나오는지 테스트 한다.

$ ng g application app2

app2 가 실행할 때 4300 port 를 사용토록 angular.json에 포트설정을 추가한다.

"serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "browserTarget": "app2:build",
            "port": 4300
          },
 ... 중략 ...

 $ ng s app2 

apps/app2/src/app/app.module.ts 와 app.component.html을 수정한다. import 할 때"@jm/plugin2"로 사용함을 주의한다.

// app.component.html
<jm-plugin2></jm-plugin2>

// app.module.ts
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { Plugin2Module } from '@jm/plugin2';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    Plugin2Module
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {}

"ng s app2" 실행하고 http://localhost:4300 으로 호출하면 샘플 echart가 보인다.

Plugin2 번들링 하기

app2 애플케이션에 plugin2 컴포넌트가 잘 나오는 것을 확인 하였다. plugin2 번들링을 위해 한가지 설정 옵션을 변경하여 다시 번들링한다. build시에 에러가 발생하면 ng-packagr v5.0.1 이상을 설치한다.

//libs/plugin2/src/tsconfig.lib.json 에서 skipTemplateCodegen을 false로 변경한다
  "angularCompilerOptions": {
    "annotateForClosureCompiler": true,
    "skipTemplateCodegen": false,

// ng-packagr 관련 업데이트 
$ npm update ng-packagr
$ npm i -D tsickle

//다시 번들링한다. 
$ ng build plugin2
Building Angular Package
Building entry point '@jm/plugin2'
Compiling TypeScript sources through ngc
Bundling to FESM2015
Bundling to FESM5
Bundling to UMD
No name was provided for external module 'ngx-echarts' in output.globals – guessing 'ngxEcharts'
Minifying UMD bundle
Copying declaration files
Writing package metadata
Removing scripts section in package.json as it's considered a potential security vulnerability.
Built @jm/plugin2
Built Angular Package!
 - from: /Users/dowonyun/prototyping/jamong/libs/plugin2

skipTemplateCodegen를 false로 하면 ngfactory파일까지 생성되고 해당 파일은 Angular메타정보를 해석해 놓은 파일로 동적으로 파일을 로딩할 때 사용할 것이다. 다음으로 bundle 된파일을 다시 하나의 파일로 합치기 위해 package.json에 script를 등록한다.

// package.json
"scripts": {
   ... 중략 ...
   "build:plugin2": "rollup dist/libs/plugin2/esm2015/lib/plugin2.module.ngfactory.js --file dist/apps/api/plugin2.js --format umd --name plugin2"
}

// bundling 
$ npm run build:plugin2

dist/apps/api/plugin2.js 파일이 생성된다. 또는 ROOT에 rollup.config.js 파일을 생성하여 관리할 수도 있다.

//rollup.config.js
export default [
  {
    input: 'dist/libs/plugin2/esm2015/lib/plugin2.module.ngfactory.js',
    output: [
      {
        name: 'plugin2',
        file: 'dist/apps/api/plugin2.js',
        format: 'umd'
      }
    ]
  }
];

//build 명령
$ rollup -c

두가지의 명령을 수행한다.

• ng build plugin2
• npm run build:plugin2  또는 rollup.config.js를 설정하였다면 rollup -c

Plugin2 파일 API 서비스 추가

plugin2 파일을 동적으로 로딩하기 위해 다음과 같이 역할을 추가한다.

• Dev Server는 Platform 서버 역할
• API Server는 별개 애플리케이션 서버로 보고 Plugin-2 파일을 서비스하는 역할

이제 API Server에서 plugin2.js 파일을 읽어서 파일 내용을 전달하는 API를 추가한다. NetsJS는 NodeJS위에 구동되는 서버프레임워크로 Angular와 유사한 Syntax를 통해 MVC 패턴으로 개발한다.

• GET으로 plugin2를 호출하면 파일을 읽는다.
• 파일 내용을 return하면 끝!

// apps/api/src/app/app.controller.ts

import { Controller, Get } from "@nestjs/common";

import { Message } from "@jm/api-interface";
import { AppService } from "./app.service";

const path = require('path');
const fs = require('fs-extra');

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get("hello")
  getData(): Message {
    return this.appService.getData();
  }

  @Get("plugin2")
  getPlugin2() {
    const fileName = path.join(process.cwd(), 'dist/apps/api/plugin2.js');
    const plugin2 = fs.readFileSync(fileName, 'utf8');
    return plugin2;
  }
}

테스트를 해보자. API Server기본 context는 api로 http://localhost:3333/api/plugin2 로 호출한다. 번들링 파일 내용이 응답됨을 확인했다.

// API Server 기동
$ ng s api

원격 Plugin2을 Lazy Loading 하기

plugin2.js 파일을 다운로드 받아 로딩하기 위해 apps/jamong/src/app/app.component.html과 .ts에 로딩 구문을 추가한다.

// app.component.html
<button (click)="loadPlugin()">Load plugin</button>
<lazy-af *ngIf="plugin1Path" [moduleName]="plugin1Path"></lazy-af>

<p></p>

<button (click)="loadPlugin2()">Load plugin2</button>
<ng-template #Plugin></ng-template>

app.component.ts

• plugin2.js 파일을 요청하기 위해 HttpClient를 사용
• Plugin2ModuleNgFactory안의 Angular MetaData를 통해 관련 컴포넌트들 JIT 컴파일 수행
• @herodevs/dynamic-af 패키지이 DynamicAFService 서비스를 injector받는다.
• 이때 plugin2.js 소스내의 require하는 모듈을 위해 import * as from ''; 하여 아래 소스처럼 설정한다.

import { Component, ViewChild, ViewContainerRef, NgModuleFactory, Injector } from '@angular/core';
import { HttpClient, HttpErrorResponse } from '@angular/common/http';
import { throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';
import { DynamicAFService } from '@herodevs/dynamic-af';

import * as common from '@angular/common';
import * as commonHttp from '@angular/common/http';
import * as core from '@angular/core';
import * as router from '@angular/router';
import * as rxjs from 'rxjs';
import * as rxjsOperators from 'rxjs/operators';
import * as ngxEcharts from 'ngx-echarts';

@Component({
  selector: 'jm-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {

  @ViewChild('Plugin', {read: ViewContainerRef}) pluginVcr: ViewContainerRef;
  plugin1Path: string;
  loadedPlugins: any = {};

  constructor(
    private http: HttpClient,
    private injector: Injector,
    private lazyService: DynamicAFService
  ) { }

  loadPlugin() {
    this.plugin1Path = 'apps/jamong/src/app/plugin1/plugin1.module#Plugin1Module';
  }

  loadPlugin2() {
    const moduleFactory = this.loadedPlugins['api/plugin2'];
    if (!moduleFactory) {
      this.loadRemoteComponent();
    } else {
      this.lazyService.createAndAttachModuleAsync(moduleFactory, this.injector, { vcr: this.pluginVcr });
    }
  }

  private loadRemoteComponent() {
    let moduleFactory: NgModuleFactory<any>;
    this.http.get('api/plugin2', { responseType: 'text' })
      .pipe(
        catchError(this.handleError)
      ).subscribe((compiledSource: any) => {
        const exports = {};
        const modules = {
          '@angular/core': core,
          '@angular/common': common,
          '@angular/common/http': commonHttp,
          '@angular/router': router,
          'rxjs': rxjs,
          'rxjs/operators': rxjsOperators,
          'ngx-echarts': ngxEcharts
        };
        const require: any = (module) => modules[module];
        // tslint:disable-next-line: no-eval
        eval(compiledSource);
        moduleFactory = exports['Plugin2ModuleNgFactory'];
        this.loadedPlugins['api/plugin2'] = moduleFactory;
        this.lazyService.createAndAttachModuleAsync(moduleFactory, this.injector, { vcr: this.pluginVcr});
      });
  }

  private handleError(error: HttpErrorResponse) {
    if (error.error instanceof ErrorEvent) {
      // A client-side or network error occurred. Handle it accordingly.
      console.error('An error occurred:', error.error.message);
    } else {
      // The backend returned an unsuccessful response code.
      // The response body may contain clues as to what went wrong,
      console.error(`Backend returned code ${error.status}, body was: ${error.error}`);
    }
    return throwError(error);
  }
}

위의 모든 소스는 GitHub에...

<참조>

- ngx-echarts

- Another Angular Plugin Example

- Rollup Configuration