📒 목차

• 📌 NestJS란?
• 📌 NestJS 설치
• 📌 NestJS 폴더 구조
• 📌 NestJS package.json
• 📌 prettier 저장시 자동포멧팅
• 📌 TypeScript 폴더 구조
• 📌 NestJS started with GraphQL & TypeScript

📌 NestJS란?

NestJS는 TypeScript(타입 스크립트)를 지원하는 효율적이고 확장 가능한 Node.js의 서버 애플리케이션 프레임워크이다.

OOP (Object Oriented Programming), FP (Functional Programming) 및 FRP (Functional Reactive Programming) 요소를 결합하는 특징을 가지고 있다.

Node.js로 Backend를 만드는 것은 마치 레고와 같은데, 레고처럼 조립할 수 있는 부품이 있고, 그 작은 부품들을 차근차근 조립하다 보면 거대한 완성품을 만들 수 있다.

Node.js도 마찬가지로 하나의 파일에서 시작해서 점차 점차 커지게 된다.

규칙도, 제약도 없이 자유롭게 할 수 있고 0에서 거대한 것을 창조하는 과정이기에 매우 훌륭한 경험이 될 수 있다.

하지만, 문제는 너무 제약이 없고, 너무 자유롭다는 것이다.

때로는 규칙이나 제약, 즉 구조와 프레임워크가 필요할 때가 있다.

다른 언어, 예를 들어 파이썬에는 장고라는 프레임워크가 있고 Java는 Spring이 있습니다.

하지만 Node.js에는 규칙이 없고, 어떤 패턴을 따라야 할지도 모르며 사용자가 정의해서 사용해야 한다.

이런 자유로움은 좋은 점도 많지만, 프로젝트로 협업을 진행할 경우 매우 어렵다.

개발자마다 다양한 Architecture 패턴을 가지고 있고, 프로젝트의 규모가 커질수록 개인의 구조와 스타일의 다름으로 인해 협업 과정에 드는 소통 비용이 증가한다.

이는 생산성 저하와 유지 보수의 어려움으로 이어진다.

NestJS는 Architecture 구조를 제공함으로써 Node.js의 주요 문제를 해결해 준다!!!

NestJs는 Node.js를 위한 프레임워크로, 규칙과 구조 없이 자유분방한 node.js를 순식간에 Python+Django, Java+Spring 수준으로 만들어준다.

때문에 각 개발자들이 Architecture를 통일하고 소통 비용을 절감하며, 확장성 있고 효율적인 개발을 할 수 있다.

✅ 효율성

NestJS는 개발자와 팀이 고도로 테스트 가능하고, 확장 가능하며, 느슨하게 결합되고 유지관리가 쉬운 애플리케이션을 만들 수 있는 즉시 사용 가능한 애플리케이션 아키텍처를 제공한다.

그 외에도 TypeScript기반의 Framework이며 Dependency Injection(의존성주입), Inversion of Control(제어의 역전), Module을 통한 구조화 등 생산성에 용이하다.

✅ 안정성

NestJS는 TypeScript를 적극적으로 도입하면서 서버 어플리케이션 개발 시 발생 가능한 오류들을 사전에 방지할 수 있도록 한다.

또한 세부적인 Module로 나누어져 있기 때문에 독립적인 Unit Test를 쉽게 작성 가능하도록 구현되어 있다.

✅ 확장성

NestJS는 Module Class를 지원하며, 각 Module은 비슷한 기능과 개념들을 Class 한 곳에 담아 캡슐화하고 서로 Import가 가능하도록 구현되어 있다.

이러한 Module 구조는 Architecture를 조직적(Organize)으로 가져가게 하고 느슨한 결합(Loose Coupling)을 가능하게 만들어 확장성(Extensible)과 테스트 가능성(Testable)을 높인다.

📌 NestJS 설치

✅ NestJS 설치 명령어

• -g : global의 약자로, 특정 소스코드를 해당 폴더에 설치하는 것이 아니라 컴퓨터에 설치하게 되는 것

• cli : CLI는 Command-line interface로 터미널에서 명령어를 입력해 폴더를 열고, 파일을 실행하는 등의 상호 작용하는 방식을 말합니다.

yarn add -g @nestjs/cli

✅ NestJS 버전 확인하기 (정산적으로 설치 되었는지 확인하기)

nest --version

✅ nest 명령어 통해 새로운 nest 프로젝트 만들기

nest new aaa(폴더명)
// 위의 명령어가 안된다면 아래 명령어로 만들기
npx nest new aaa(폴더명)

✅ git clone으로 Nest 프로젝트 생성하기

git clone https://github.com/nestjs/typescript-starter.git aaa
// aaa 프로젝트 폴더가 생성

yarn install // yarn 명령어를 사용하여 설치

yarn start // 실행 명령어를 입력하여 실행

✅ NestJS .git 파일 관리

NestJs 를 만들게 되면 typescript 파일 등 여러 파일들과 함께 .git 파일도 자동으로 만들어지게 된다.

하지만, 최상단에 .git 파일이 있다면 git 파일이 2개 이상 존재하게 되므로 git add, commit 후 push 할 때 에러가 발생되므로 NestJs 를 만들 때 자동 생성된 git 파일을 삭제해 주어야 한다.

ls -al // 숨겨진 파일까지 모두 조회하기 (.git 파일)

rm -rf .git // 숨겨져있는 .git파일 지우기

📌 NestJS 폴더 구조

✅ 보일러 플레이트 (초기 폴더 구조)

새로운 프로젝트를 실행할때 처음 만들어진 Nest 폴더 구조.

모든 회사가 같은 보일러 플레이트를 가지고 있는 것은 아니다.

회사에 따라 가지고 있는 필요한 기능들이 내장되어 있는 보일러 플레이트가 존재한다.

📌 NestJS package.json

package.json 파일은 프로젝트 전체 설명서라고 할 수 있다.

scripts 는 명령어를 쉽게 실행할 수 있도록 단축 명령어를 만들어 둔 것이다.

// package.json

"scripts": {
    "prebuild": "rimraf dist",
    "build": "nest build",
    "format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"",
    "start": "nest start",
    "start:dev": "nest start --watch",
    "start:debug": "nest start --debug --watch",
    "start:prod": "node dist/main",
    "lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage",
    "test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
    "test:e2e": "jest --config ./test/jest-e2e.json"
  },

• index.js , index.ts 와 같은 파일이 따로 존재하는 것이 아니라, scripts 태그 안의 여러 방법으로 실행할 수 있다.

• 시작하는 부분은 "start": "nest start" 의 start 로 실행해 주시면 된다.
  • 개발할 때 : "start:dev" 사용 (dev 는 development 의 약자)
  • 배포할 때 : "start:prod" 사용 (prod 는 production 의 약자)
    ( "start:dev": "nest start --watch" ⇒ watch : 소스코드가 바뀌면 자동으로 리프레쉬 해주는 것 )

• Nest 자체에서 nodemon 기능을 제공해주고 있기에 nodemond은 필요 없다.

• test : 배포전에 테스트 코드를 작성해서 실행시켜 봄으로 모든 API가 제대로 작동하는지 확인하는 것으로 보다 안전한 개발을 하기 위한 것이다.

// package.json

"dependencies": {
    "@nestjs/common": "^8.0.0",
    "@nestjs/core": "^8.0.0",
    "@nestjs/platform-express": "^8.0.0",
    "reflect-metadata": "^0.1.13",
    "rimraf": "^3.0.2",
    "rxjs": "^7.2.0"
  },
  "devDependencies": {
    "@nestjs/cli": "^8.0.0",
    "@nestjs/schematics": "^8.0.0",
    "@nestjs/testing": "^8.0.0",
    "@types/express": "^4.17.13",
    "@types/jest": "^27.0.1",
    "@types/node": "^16.0.0",
    "@types/supertest": "^2.0.11",
    "@typescript-eslint/eslint-plugin": "^4.28.2",
    "@typescript-eslint/parser": "^4.28.2",
    "eslint": "^7.30.0",
    "eslint-config-prettier": "^8.3.0",
    "eslint-plugin-prettier": "^3.4.0",
    "jest": "^27.0.6",
    "prettier": "^2.3.2",
    "supertest": "^6.1.3",
    "ts-jest": "^27.0.3",
    "ts-loader": "^9.2.3",
    "ts-node": "^10.0.0",
    "tsconfig-paths": "^3.10.1",
    "typescript": "^4.3.5"
  },

dependencies와 devDependencies 는 node 라이브러리들의 설치 목록을 나타낸다.

• dependencies : 백엔드 서버를 실행시킬 때 필요한 모듈들이 위치한다.

• devDependencies : VS code 내에서 개발할 때 필요한 모듈들이 위치한다.

// package.json

"jest": {
    "moduleFileExtensions": [
      "js",
      "json",
      "ts"
    ],
    "rootDir": "src",
    "testRegex": ".*\\.spec\\.ts$",
    "transform": {
      "^.+\\.(t|j)s$": "ts-jest"
    },
    "collectCoverageFrom": [
      "**/*.(t|j)s"
    ],
    "coverageDirectory": "../coverage",
    "testEnvironment": "node"
  }

마지막으로 jest 가 있다.

jest는 테스트 관련된 부분이다. 마우스로 하나하나 클릭해서 테스트해 볼 수 있지만, 백엔드는 보통 보이지 않기 때문에, 명령어를 이용해서 파일을 실행해서 테스트한다.

📌 prettier 저장시 자동포멧팅

파일의 최상단 위치에서 .vscode 폴더를 만들기.

.vscode 폴더 안에 settings.json 파일을 만들기.

settings.json 파일 안에 VS Code settings 을 작성하기.

// settings.json

{
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
}

• "editor.formatOnSave": true : 저장하면 프리티어가 바로 적용될 수 있게 설정

• "editor.defaultFormatter": "esbenp.prettier-vscode” : prettier 포멧 적용 설정

📌 TypeScript 폴더 구조

✅ main.ts

// main.ts

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

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

• 처음에 실행되는 부분이 main.ts 파일이다.

• bootstrap : 함수 이름이기에 bootstrap 외에 원하는 이름으로 작성 가능하다.

• app.listen(3000) : 3000번 포트가 실행되서 24시간 동안 listening 하고 있을것으로 기존에 실행 중이던 3000번 포트가 존재한다면 종료시켜줘야 한다.
  

• .create(AppModule) : AppModule 안에 우리가 앞으로 만들게 되는 모든 내용들(API 등)이 포함되어 있다.

✅ app.controller.spec.ts

test 관련 코드이다.

✅ app.module.ts

// app.module.ts

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';

@Module({
  imports: [],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

app.module.ts 파일에서 app.controller.ts 와 app.service.ts 가 합쳐지게 된다.

app.controller.ts 파일은 controllers 에 해당되며 app.service.ts 파일은 providers 에 해당한다.

따라서 이 module 을 main.ts 파일에 import 해주게 된다.

또한, NestJS에서는 자동으로 의존성주입을 해주게되는데 module 부분이 의존성주입을 해주는 부분이다.

✅ app.controller.ts

// app.controller.ts

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

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

  @Get('/qqq')
  getHello(): string {
    return this.appService.getHello();
  }
}

의존성주입을 사용하여 appService 를 불러오고 있으며, 제어가 역전된것을 확인 할 수 있다.

@Controller() : 데코레이터로 함수의 정의 전에 호출되며 기존 객체에 새로운 기능을 추가할 수 있도록 하는 디자인 패턴이다.

@Get() : Get 요청이 실행되는 부분으로, ( ) 안에 dafault 값은 ‘/’ 이다.

📌 NestJS started with GraphQL & TypeScript

Nest는 GraphQL 애플리케이션을 빌드 하는데  스키마 우선(schema first) 및 코드 우선(code first) 방법을 제공한다.

✅ Schema First(스키마 우선)

Schema first 는 graphql의 schema를 먼저 정의하고, 그 schema 정의에 맞게 코드를 작성하는 방법을 말한다.

schema를 작성하기 위해서는 graphql의 data model을 나타내기 위해 만들어진 SDL(Schema Definition Language) 를 사용한다.

SDL은 모든 프로그래밍 언어와 독립적이며, 통합되는 언어이고, NestJS에서는 GraphQL 스키마를 TypeScript의 클래스 및 인터페이스 형식으로 구현된다.

따라서, GraphQL 스키마를 기반으로 TypeScript 정의 (클래스 또는 인터페이스 사용)를 자동으로 생성하여 중복된 상용구 코드를 작성할 필요성을 줄여주며 ****전체 관계를 직관적으로 나타냄으로 팀 커뮤니케이션 장애가 적은 장점이 있다.

하지만 실제 코드에 해당하는 Resolver는 포함되지 않으므로 스키마 정의와 함께 Resolver가 계속적으로 동기화되어야하며 Resolver 코드와 SDL의 정의가 정확하게 일치해야하는 단점이 존재한다.

GraphQLModule.forRoot({
  typePaths: ['./**/*.graphql'],
}),

스키마 우선 접근 방식을 사용하려면 먼저 옵션 개체에 typePaths 속성을 추가해야 한다. 
typePaths 속성은 GraphQLModule이 작성할 GraphQL SDL 스키마 정의 파일을 찾아야하는 위치를 나타낸다.

// cat.graphql

type Query {
  cats: [Cat]
  cat(id: ID!): Cat
}

type Mutation {
  createCat(createCatInput: CreateCatInput): Cat
}

type Subscription {
  catCreated: Cat
}

type Owner {
  id: Int!
  name: String!
  age: Int
  cats: [Cat!]
}

type Cat {
  id: Int
  name: String
  age: Int
  owner: Owner
}

input CreateCatInput {
  name: String
  age: Int
}

.graphql 로 스키마를 직접 작성해줘야 한다.

✅ Code First(코드 우선)

코드 우선 접근 방식에서는 데코레이터와 TypeScript 클래스를 사용하여 먼저 작성한 Resolver 을 기반으로 해당 GraphQL 스키마를 자동 생성한다.

이 방법은 TypeScript로만 작업하고 언어 구문 간의 컨텍스트 전환을 피하려는 경우 유용하다.

Schema와 Resolver간의 type safety를 보장하며 코드 중복이 최소화되는 장점이 존재다.

하지만, SDL과 비교해서 직관적이지 못한 단점이 존재한다.

GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
			autoSchemaFile: 'src/common/graphql/schema.gql',
})

코드 우선 접근 방식을 사용하려면 먼저 옵션 객체에 autoSchemaFile 속성을 추가해야 한다.

autoSchemaFile 속성 값은 자동으로 생성된 스키마가 생성될 경로이다.

결과적으로 schema first는 graphql schema를 먼저 작성한 후, typescript 클래스나 인터페이스를 생성해 주고 **code first**는 typescript로 클래스를 만들면 해당 클래스에 해당하는 graphql schema를 자동으로 만들어 준다.