GraphQL과 Apollo 열 한번째 이야기 - TypeScript + Nest.js에서 GraphQL 사용해 보기 - 실습 환경 구성

 

 

카카오페이 | 마음 놓고 금융하다

 

 

 

 

NestJS로 배우는 백엔드 프로그래밍:타입스크립트 환경의 차세대 서버 프레임워크를 만나다

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

🗂 목차

✅ GraphQL과 Apollo 첫번째 이야기 - 개념 익히기
✅ GraphQL과 Apollo 두번째 이야기 - REST API란?
✅ GraphQL과 Apollo 세번째 이야기 - GraphQL의 정보 주고 받는 방식
✅ GraphQL과 Apollo 네번째 이야기 - Apollo란?
✅ GraphQL과 Apollo 다섯번째 이야기 - GraphQL을 간단하게 구현해 보아요 😀
✅ GraphQL과 Apollo 여섯번째 이야기 - GraphQL Module화에 대해 알아보아요 😀
✅ GraphQL과 Apollo 일곱번째 이야기 - GraphQL Data Type에 대해 알아보아요 😀
✅ GraphQL과 Apollo 여덟번째 이야기 - GraphQL Union과 Interface 그리고 인자와 인풋 타입에 대해 알아보아요 😀
✅ GraphQL과 Apollo 아홉번째 이야기 - Java + Spring Boot에서 GraphQL 사용해 보기 - 실습 환경 구성
✅ GraphQL과 Apollo 열번째 이야기 - Java + Spring Boot에서 GraphQL 사용해 보기 - 실습 해보기
✅ GraphQL과 Apollo 열 한번째 이야기 - TypeScript + Nest.js에서 GraphQL 사용해 보기 - 실습 환경 구성
✅ GraphQL과 Apollo 열 두번째 이야기 - TypeScript + Nest.js에서 GraphQL 사용해 보기 - 실습 환경 테스트
✅ GraphQL과 Apollo 열 세번째 이야기 - TypeScript + Nest에서 GraphQL 사용해 보기 - 실습 해보기
✅ GraphQL과 Apollo 열 네번째 이야기 - React와 Apollo Client
✅ GraphQL과 Apollo 열다섯번째 이야기 - React와 Apollo Client - Query와 Mutation 사용하여 웹 페이지 만들기
✅ GraphQL과 Apollo 열 여섯번째 이야기 - Kotlin + Spring Boot에서 GraphQL 사용해 보기 - 실습 환경 구성
✅ GraphQL과 Apollo 열 일곱번째 이야기 - Kotlin + Spring Boot에서 GraphQL 사용해 보기 - 실습 해보기

🤔 내가 만난 문제

⚠️ [Nest.js] TypeORM Table 관계가 맺어졌을 때, Seeding (feat. Migration)
⚠️ [Spring Boot 3.0] Could not resolve org.springframework.boot:spring-boot-gradle-plugin
⚠️ [Spring Boot 3] Spring Doc(Swagger) White Label Error

📋 부록

🔍 [Nest.js] 초기 환경 구성 (feat. TypeORM, QueryBuilder, GraphQL, Apollo)
🔍 [SOLID][Nest.js][Java + Spring] Interface를 활용한 결합도 분리 (Interface를 이용한 Dependency Injection - DI)

 

 

GitHub - junyharang-coding-study/GraphQL-Study: GraphQL을 공부하고, 실습한 코드에요 😀

 

 

 

 

🚀 GraphQL과 Apollo 열 한번째 이야기

    🔽 TypeScript + Nest.js에서 GraphQL 사용해 보기 - 실습 환경 구성

        📦 개요

이 전 시간까지 주니는 자프링과 JPA 그리고 QueryDsl ORM을 사용하여 GraphQL에 대해 구성하고,
실습하는 시간을 가져보았어요.

요즘 취업 시간을 둘러보니 많은 기업에서 Nest.js를 사용할 수 있는 사람을 찾는 것을 보았고, 더불어 GraphQL 사용 가능한 사람을 찾는 공고를 많이 보게 되었어요.

기업에서 필요로 하는 기술을 가지고 있다면 좋다고 생각하기 때문에 해당 Computer(컴퓨터) Languge(언어)와 Framwork(프레임워크)를 이용해서 다시 실습해 보려고 합니다.

참고로 열두번째 이야기에서 사용할 ORM은 TypeORM을 사용할 거에요.

또한, GraphQL을 사용하기 위해 강의를 들으며 공부했던 Apollo를 사용할 거에요.

마지막으로 초기 구성 정보는 이 곳에 따로 작성해 두었어요.

 

 

 

 

  

🚀 코드 구현

    🔽 Equipment - Resolver

        📦 초기 구성

nest generate resolver <만들 위치>/<파일명>

Nest.js는 @nestjs/cli 패키지의 nest generate 명령어를 사용하여 필요한 파일들을 만들어 줄 수 있어요.
위와 같이 입력하면 resolver를 원하는 위치에 만들어 줄 수 있어요.

NestCLI 명령어

근데, 주니가 원한 건 src/app/equipment/resolver/Equipment가 만들어지길 바랬지만,
src/app/equipment/resolver/equipment/ 이 곳에 만들어진 걸 알 수 있어요.

src/app/equipment/resolver

그래서 위치를 위와 같이 변경해 주었어요.

src/app/equipment/resolver/equipment.resolver.ts (변경 전)

센스있게 @Resolver()가 딱 붙어있는 걸 볼 수 있어요.

이제 이 코드를 변경해 볼게요.

        📦 Create

src/app/equipment/resolver/equipment.resolver.ts

위 코드에 대해 분석해 볼게요.

코    드	상 세 내 용
@Resolver(...)	해당 Class가 GraphQL Resolver임을 나타내며, EquipmentEntity에 대한 GraphQL Resolver로 사용할 것이라고 정의.
EquipmentResolver Class	EquipmentEntity에 대한 GraphQL Resolver 정의 Class. Resolver는 GraphQL Query, Mutaion에 대한 실제 Logic 담당.
constructor(...)	생성자 부분으로 Class를 이용하여 객체가 생성될 때, 호출되는 Method. 주입된 equipmentService를 해당 객체에서 사용할 수 있도록 초기화
@UsePips(...)	해당 Mutaion의 인자에 대한 입력값을 검증하고, 변환하는 데 사용되는 Pipe 지정. ValidationPipe는 주어진 DTO(Data Transfer Object) Class에 따라 입력값을 검증하고, 필요한 경우 변환 작업 수행(gransfrom: true).
@Mutaion(...)	GraphQL Mutaion 정의. DefaultResponse<string>은 해당 Mutaion의 반환 타입을 표현.
saveForEquipment()	@Mutaion으로 GraphQL Mutaion Method임을 정의. EquipmentRequestDto를 입력 받아 equipmentService의 saveForEquipment() 호출한 뒤 결과 반환.
@Args(...)	GraphQL Mutaion의 인자 정의를 위한 Decorator. "input"은 해당 인자의 이름을 나타내며, { type: () => EquipmentResponseDto }는 이 인자 Type이 EquipmentRequestDto 객체임을 명시.
@Body() ...	Nest.js의 @Body()를 이용하여 HTTP Request Body에서 Data 추출을 명령. 여기서 equipmentRequestDto는 해당 Mutaion의 실제 인자로 사용되는 객체. Mutation 연산 결과로 DefaultResponse<string> 객체 반환.

여기서 Promise에 대해 알아보자면 Promise는 JavaScript에서 비동기 작업을 다룰 때 사용되는 객체에요.
이는 특정 작업의 완료 또는 실패와 같은 결과를 나타내는데 사용하고 있어요.

JavaScript는 비동기 처리를 위해 Call Back(콜백) 함수를 사용하는데, 콜백 함수를 너무 남용하게 된다면
콜백 지옥에 빠질 수 있게 돼요.

이렇게 되면 Error 처리도 힘들고, 여러 개의 비동기 처리를 한번에 하는데 한계가 발생할 거에요.
이런 문제를 보완하며, 비동기 처리에 사용하기 위해 Promise가 탄생하게 되었어요.

Promise를 사용하면 비동기 처리 시점을 명확하게 표현할 수 있고, 연속된 비동기 처리 작업을 수정, 삭제, 추가하기 편하고 유연하게 다룰 수 있어요. 그리고, Code의 유지 보수가 보다 편리할 수 있어요.

Promise는 객체이기 때문에 생성자를 호출하여 인스턴스와 할 수 있어요.
Promise의 생성자는 resolve와 reject 함수를 인자로 전달 받는 콜백함수를 인자로 받고 있어요.
Promise는 인자로 전달 받은 콜백 함수를 내부에서 비동기로 처리 한답니다. 


Promise 객체는 세 가지 상태를 가질 수 있어요.

상    태	상세 내용
Pending(대기 중)	비동기 작업이 아직 완료되지 않은 상태. 즉, 초기 상태.
Fulfilled(이행 됨)	비동기 작업 성공적으로 완료된 상태.
Rejected(거부됨)	비동기 작업 실패 상태.

728x90

 

const myPromise = new Promise((resolve, reject) => {
  // 비동기 작업 수행
  // 작업이 성공하면 resolve() 호출
  // 작업이 실패하면 reject() 호출
});

myPromise.then(
  (result) => {
    // 작업이 성공했을 때 실행되는 부분
  },
  (error) => {
    // 작업이 실패했을 때 실행되는 부분
  }
);

위 Code는 Promise의 구조를 나타낸 Code에요.

resolve와 reject는 Promise 객체의 상태를 변경하는 두 개의 함수에요.
resolve 함수는 작업이 성공되었을 때 호출되고, reject 함수는 작업이 실패했을 때 호출 된답니다.

src/app/equipment/resolver/equipment.resolver.ts

위 Code에서 Promise<DefaultResponse<string>> 이라는 의미는 Promise 객체가 성공적으로 이행 되면 DefaultResponse<string> 형태의 Data를 반환할 것이라는 의미에요.

 

        📦 RequestDto

src/app/equipment/model/dto/request/equipment-request.dto.ts

저장을 위한 RequestDto에요.

@InputType()은 해당 DTO가 GraphQL의 InputyType이라고 명시해 준 부분이에요.
이렇게 해주면 GraphQL Query나, Mutation에 전달되는 입력 데이터 형태를 정의하게 되는 것이랍니다.

@Field(...)와 같은 Decorator는 해당 Field가 GraphQL에서 어떤 자료형 Type을 갖는지 정의해 주는 부분이에요.
그리고, @IsNotEmpty(), @IsInt(), @Min(), @IsString()은 class-validator의 Decorator로 유효성 검사를 위해 명시해 준 Decorator에요.

toEntity()는 해당 DTO 객체의 값을 Entity 객체 값으로 변환하는 역할을 하는 친구에요.

        📦 Read - 목록조회

src/app/equipment/resolver/equipment.resolver.ts

위 코드는 목록조회를 위한 코드에요.
목록조회 메서드는 검색과 페이징 처리가 같이 되도록 처리해 주었어요.

코    드	상 세 내 용
@Query(...)	GqphQL Query를 정의하는 Decorator. DefaultResponse<EquipmentResponseDto[]>는 해당 Query가 반환하는 Data Type 표현. 위 내용은 배열 형태의 EquipmentResponseDto를 깜싼 DefaultResponse 라는 객체 형태로 반환한다는 의미.
@Args(...)	GraphQL Query 인자 정의. "usedBy", { type: () => String, nullable: true }) usedBy: string - usedBy: 인자의 이름 정의. - { type: () => String, nullable: true }: 해당 인자 Type이 문자열이고, nullable: true를 통해 인자가    선택적임을 표현. 즉, 인자를 전달하지 않아도 된다는 의미. - usedBy: string: 해당 인자를 받아들이는 변수의 Type 정의.

조회할 인자는 꼭 필요한 값은 아니에요.
그리고, page와 perPageSize는 페이징 처리를 위한 인자이고,
orderBy는 말 그대로 정렬을 어떻게 할 것인지 선택하라고 받아주는 부분이에요.

 

 

 

        📦 Read - 상세조회

src/app/equipment/resolver/equipment.resolver.ts

이 코드에서 주목해야 할 점은 @Args의 Property이 input이 아닌 equipmentId라는 점이에요.

밑에서 또 자세히 이야기 하겠지만

src/graphql/schema/schema.graphqls

GraphQL type Root Query와 type Root Mutation을 보면
saveForEquipment()는 input으로 객체를 주겠다고 선언하였으나,

getEquipment()는 인자값으로 equipmentId를 줄건데, 그건 문자열이야! 라고 알려준 것이에요.

그렇기 때문에 @Args의 Property가 input이 아닌 equipmentId로 작성해 주어야 해요.

        📦 Update

src/app/equipment/resolver/equipment.resolver.ts

저장을 할 때는 객체에 담아서 값을 받는 것이 아닌 각각의 요소들을 나눠서 받아
Service에서 DTO로 합쳐 작업을 해 보았어요.

Update는 객체로 요청을 받도록 처리해 보았어요.

여기서 RequestDTO가 왜? Update하고, Create에서 각각 만들어서 작업하는지 궁금하신 분들이 계실거에요.
꼭 이렇게 해야 한다는 아니겠지만, 주니가 이렇게 한 이유는

Update의 경우 ID값은 데이터베이스에 있는지 검사를 해야 되서 필수로 받아야 하지만,
나머지 값들은 필수로 받지 않아도 되는데, Create 같은 경우는 이와 달리 안 받아도 되는 내용이 있지 않는 한 모든 내용을 다 받아야 하기 때문이에요.

src/app/equipment/model/dto/request/equipment-update-request.dto.ts

그래서 UpdateRequestDTO 같은 경우 ID를 빼고는 @IsNotEmpty()를 모두 제거해 주었고,
toEntity() 같은 경우도 ID값을 바꾸면 안되기 때문에 ID는 제외하고, Entity 객체로 바뀔 수 있게 만들어 주었어요.

        📦 Delete

src/app/equipment/resolver/equipment.resolver.ts

 

 

    🔽 Equipment - Service

        📦 Create

src/app/equipment/service/equipment.service.ts

@Injectable()은 Nest.js에서 주입 가능한(Dependency-injectable) 서비스임을 나타내 주고 있어요.
주로 Dependency Injection(의존성 주입 - DI)를 사용하여 다른 Class(클래스), Compnent(컴포넌트)에 의존성을 주입하고, Application(애플리케이션) Module(모듈)에서 이 서비스를 Provider(프로바이더)로 설정할 수 있게 해준답니다.

그래서 @Injectable()을 명시하면 해당 클래스는 Nest.js에서 의존성을 주입 받을 수 있는 클래스로 간주됩니다.

예를 들어 주입 가능한 클래스로 선언된 클래스는 다른 Nest.js 구성 요소(Controller 등)에 주입될 수 있어요.
@Injectable()은 주로 비즈니스 로직이나, 데이터 액세스와 같은 계층에 많이 사용돼요.

그리고, 생성자를 통해 EquipmentRepository를 주입 받고 있어요.

15 ~ 16번째 줄은 RequestDTO가 비어있는지 확인해서 비어 있으면 Error Code를 반환하는 부분이에요.

19번째 줄은 RequestDTO의 equipmentId값을 findByEquipmentId()에게 전달해서 데이터베이스에 해당 ID값을 갖은 내용을 갖고오기 위한 부분이고,

이를 통해 21 ~ 23번째 줄에 해당 값이 있다면 이미 해당 ID는 DB에 저장되어 있는 거라 이미 있는 값이라고 알려주는
Error를 반환해 준 부분이에요.

값이 없다면 본격적으로 데이터베이스 저장을 위해 Repository의 saveEquipment()에 RequestDTO를
toEntity()를 이용하여 Equipment Entity로 변환해서 전달해 주는 부분이에요.

Repository 부분에서 보겠지만, 해당 연산이 처리되면 Euipement Entity가 반환이 돼요.
근데 그 값이 Null이라면 저장에 문제가 생긴 것이기 때문에 Error를 반환하게 해줍니다.

Null이 아니라면 정상적으로 처리가 된 것이니 HTTP Status Code 200과
함께 해당 Entity의 ID값만을 추출해서 반환하는 부분이에요.

src/app/equipment/service/equipment.service.ts

위에서 이야기 했던 ID를 먼저 찾는 Method(메서드)는 여러번 사용할 것이기 때문에 따로 빼놨어요.
이렇게 ID값을 받아 Repository의 findByEquipmentId()에게 전달해 주고, 결과값을 반환하는 역할을 해주는데,

이 때도 Entity가 반환되는 걸 알 수 있어요.

 

 

        📦 Read - 목록조회

src/app/equipment/service/equipment.service.ts

조회 및 페이징 처리 그리고, 정렬을 위해 받은 인자값은 EquipmentSearchRequestDTO의 toDto()에 전달되고,
이를 통해 해당 DTO 객체로 변환되게 해주었어요.

그리고 해당 DTO를 Repository 메서드에 전달해서 Query Builder를 이용한 연산을 처리하고,
조회된 결과값을 배열 안에 Entity[]과 number를 받도로 받도록 하였어요.

result 배열 0번째에는 데이터베이스에서 조회된 결과값이 들어있고,
1번째 배열에는 해당 Table에 존재하는 값들의 개수를 담고 있어요.

45 ~ 47번째 줄은 그렇게 조회된 result[0]의 배열 길이가 0이라면 아무것도 조회가 안된 것이니
데이터가 없다는 Error를 반환해 준 부분이에요.

배열의 길이가 0이 아니라면 조회가 된 것이기 때문에 Page 객체의 생성자에 데이터베이스에서 조회된 값들의 개수를 넣어주고, 두번째 매개 변수로 해당 Talble의 총 요소 개수를
그리고, 3번째 매개 변수로 데이터 베이스에서 조회된 값들을 담고 있는 배열을 map()을 통해 Entity를 ResponseDTO로 변환하여 배열로 담기도록 해 주었어요.

 

💡 async와 await

async와 await은 JavaScript 및 TypeScript에서 비동기 코드를 다루는 데 사용되는 키워드.

📝 async: 함수가 항상 Promise를 반환한다는 의미. 이를 통해 함수 내에서 await를 사용하여 비동기 작업 수행.
async 함수 내에서 await를 사용하지 않아도 이 함수는 항상 Promise 반환.

📝 await: async 함수 내에서만 사용할 수 있으며, Promise가 처리(resolve) 될 때까지 대기하고, Promise가 처리되면
결과 값 반환. 이를 통해 비동기 코드를 동기식 코드처럼 사용 가능. 쉽게 말해 작업 넘기지 말고, 끝날 때까지 대기했다가 다음 작업을 하라는 의미.

async와 await을 사용하면 보다 선언적이고, 동기적으로 코드를 작성할 수 있고, 콜백이나, .then()을 사용하는 것보다 가독성을 높일 수 있다.

Node.js 백엔드 개발자 되기 : TypeScript + Node.js + Express + NestJS로 배우는 자바스크립트 백엔드 입문자

 

 

src/app/common/constant/page.ts

Page 객체의 위에 값들이 전달되면 첫번째 인자값과 두번째 인자값은 그대로 각각의 멤버 변수에 입력 되도록 해 주었고,

totalPage는 perPageSize(한 페이지 당 표시할 요소 개수)를 데이터 베이스 Table에 존재하는 모든 요소의 값으로 나누어 나온 수를 Round Up(올림)하여 계산된 값을 tempTotalPage에 담도록 해 주었어요.

만약 totalCount가 10이고, perPageSize가 3이라면 아래와 같이 된답니다.

Math.ceil(10 / 3) = Math.ceil(3.333....) = 4

위 예시로는 4개의 Page가 필요하다는 결과가 나오고, Page 당 3개의 항목이 있는 경우 마지막
Page에는 1개의 항목이 있게 될 것이에요.

그런 뒤 13 ~ 17번째 줄에 해당 값이 1보다 크거나, 같으면 tempTotalPage를 totalPage 멤버 변수에 담아주고,

아니라면 1이 담기도록 해 주었어요.

data라는 멤버 변수에는 어떤 자료형 타입을 갖은 배열도 담길 수 있게 처리해 주었어요.

src/app/equipment/model/dto/request/equipment-search-request.dto.ts

검색을 위한 요청 DTO는 PageRequestDto를 상속 받고 있어요.

멤버 변수인 usedBy와 newOrUsed는 문자열 또는 Null일 수 있다고 정의해 주었어요.

나머지 값들은 부모 클래스 PageRequestDto에서 상속되었거나, 초기화가 되어 있어요.

생성자에서는 비어있는 생성자를 정의해 주었는데,
부모 클래스인 PageRequestDto의 생성자를 호출하는 역할만 하고 있어요.

toDto()는 Client에서 값을 받을 때 DTO 객체에 바로 받는 게 아니라 각각의 요소들을 받고 있고,
이를 DTO로 만들기 위한 역할을 하고 있어요.

src/app/common/constant/page.request.dto.ts

PageRequestDto는 Abstract Class(추상 클래스)로 되어 있어요.
추상 클래스로 되어 있기 때문에 직접 인스턴스와 할 수 없고,
이 클래스를 상속 받는 하위 클래스에서 구현을 완성해 주어야 해요.

여기서 pageNumber (현재 위치한 Page 번호), perPageSize(한 페이지에 출력할 요소 개수),
orderBy(정렬)을 정의해 주었어요. 

 

 

 

 

        📦 Read - 상세조회

src/app/equipment/service/equipment.service.ts

위 코드는 최초 조회할 ID값이 Null인지를 확인하고,
Null이 아니면 데이터베이스에서 해당 ID를 조회한 뒤 Entity를 반환하고 있어요.

그런 뒤 64 ~ 66번째 줄은 조회된 Entity를 다시 Null인지 확인하고, Null이 아니면 정상 조회를 알려준 뒤 Entity를 ResponseDTO로 변환해서 반환해 주고 있어요.
하지만 여기서 Null이라면 데이터 베이스에서 못 찾은 것이기 때문에 해당 내용을 68번째 줄을 이용해서 반환해주고,

71번째 줄은 61번째 줄이 Null이 였다면 ID를 잘 못 전달해 준 것이기 때문에 해당 내용에 대해 반환해 주고 있어요.

62번째 줄에서 호출하는 findByEquipmentId()는 아래 메서드에요.

src/app/equipment/service/equipment.service.ts

위에서 저장 로직을 이야기할 때 공통으로 쓴다는 부분이 이런 부분이라 이렇게 따로 빼논 것이에요.

 

 

        📦 Update

src/app/equipment/service/equipment.service.ts

76 ~ 78번째 줄에서 ID값이 Null이 아닌지 확인하고 있어요.
Null이라면 어떤 데이터를 수정하겠다는건지 알 수 없기 때문에 77번째 줄에 해당 내용에 대해 반환해주고 있어요.

Null이 아니라면 데이터베이스에 해당 ID를 조회한 뒤 반환 받은 Entity를 82번째 줄에서 Null인지 확인하고 있어요.
Null이라면 데이터 베이스에 존재하지 않는 값이기 때문에 마찬가지로 이에 대한 내용을 반환해 준답니다.

Null이 아니였다면 수정 대상을 찾았기 때문에 updateEquipment()라는 메서드에 해당 ID값과 수정할 내용을 담은 RequestDto를 Entity로 변환하여 전달해 주고 있어요.

그렇게 해서 수정이 끝나면 정상 처리 되었다는 내용과 함께 수정 되어 반환된 Entity의 ID값을 전달해 주고 있어요.

        📦 Delete

src/app/equipment/service/equipment.service.ts

95번째 줄에서 ID값이 Null인지 확인하고, Null이 아니라면 삭제 대상 Entity가 존재하는지 검사하기 위해
데이터베이스에 ID값을 조회한 뒤 반환된 Entity 값으로 98번째 줄에서 Null 확인을 다시 해 주었어요.
그래서 Null이라면 삭제 대상 Entity가 없다는 내용을 반환해 줍니다.

Null이 아니면 삭제 대상 개체가 있는 것이기 때문에 데이터베이스에서 Delete Query를 날려 해당 ID값을 가진 개체를 삭제하고, 삭제된 Result값(Entity 반환 아님)을 104번째 줄에서 Null인지 확인하여
Null이면 삭제가 실패한 것으로 간주하고, 해당 내용을 반환해 주었어요.

Null이 아니면 정상 삭제 된 것이기 때문에 해당 내용과 함께 ID값을 반환해 주는데,
이 때는 Client가 전달한 ID값을 그대로 반환하도록 처리해 주었어요.

 

 

 

 

 

    🔽 Equipment - Repository

src/app/equipment/repository/equipment.repository.ts

위에서도 이야기했듯 데이터 액세스 계층인 Repository 역시 @Injectable()을 넣어 DI가 가능하게 해주었어요.

그리고, 생성자를 이용해서 Repository<>를 주입하는 걸 볼 수 있어요.

@InjectRepository()는 TypeORM과 사용되는 Decorator로 Nest.js에서 Repository를 주입받기 위해 사용해요.
Nest.js는 Spring Boot와 비슷하게 의존성 주입을 기반으로 하는 Framework(프레임워크)이며,
@InjectRepository를 사용하여 TypeORM이 관리하는 Entity에 대한 Repository를 주입할 수 있게 도와준답니다.

여기서 @InjectRepository(EquipmentEntity)는 EquipmentEntity라는
TypeORM Entity에 대한 Repository를 주입하겠다고 정의해준 것이에요.

이렇게 하면 해당 클래스에서 TypeORM을 사용하여 데이터베이스에 접근할 수 있어요.

node_modules/typeorm/repository/Repository.d.ts

equipmentRepository 변수는 Repository<Entity> 자료형 Type을 갖고 있는걸 볼 수 있어요.
해당 객체는 TypeORM에서 제공하는 Repository 객체인데,
데이터베이스와 상호 작용하기 위한 다양한 메서드들이 내장되어 있어요. 

해당 코드를 보면 Generiecs(제네릭스) 문법을 활용하여 선언되어 있는데,
TypeScript에서 export Keyword는 해당 클래스가 외부에서 사용될 수 있도록 내보내겠다는 의미에요.
declare는 Compiler에게 해당 Simbol(클래스, 함수, 변수 등)이 이미 어디서 선언되었는지 알려주는 역할이에요.

Eneity extends ObjectLiteral의 Entity는 해당 Repository에서 관리하는 Entity Type을 나타내는 부분이에요.
extends ObjectLiteral은 Entity가 ObjectLiteral이라는 Type을 확장(상속)한다는 의미에요.

ObjectLiteral은 일반적으로 어떤 객체의 구조를 나타내는 데 사용되는 TypeScript의 Type이에요.
이는 Key-Value 쌍의 형태를 가진 객체를 의미해요.

 

 

        📦 Create

src/app/equipment/repository/equipment.repository.ts

 

node_modules/typeorm/repository/Repository.d.ts

저장은 위와 같이 save()를 사용해서 저장을 해주고 있어요.
Entity를 넣어주면 데이터 베이스에 저장 뒤 저장 된 값에 대한 내용을
Promise 객체에 감싸진 Entity 형태로 반환 받을 수 있어요.

 

src/app/equipment/repository/equipment.repository.ts

 

node_modules/typeorm/repository/Repository.d.ts

ID 조회를 위한 Repository 메서드는 위와 같아요.
이렇게 객체를 인자값으로 전달하는 데, 객체의 이름은 where로하고, 값을 조회할 ID로 넣어 객체를 전달하면
데이터베이스에서 해당 ID를 조회하여 조회된 값을 Entity로 반환하는 걸 알 수 있어요.

이 부분은 상세 조회때도 사용되고, Update, Delete 때도 사용됨을 참고해 주세요.

        📦 Read - 목록조회

src/app/equipment/repository/equipment.repository.ts

반응형

위의 코드도 분석해 볼게요.

최초 17번째 줄에 QueryBuilder를 생성하게 됩니다.
createQueryBuilder()를 사용하여 equipment 라는 Alias(별칭)을 가진
EquipmentEntity에 대한 QueryBuilder를 만들었어요.

limit() 과 offset()을 사용하여 Pagination 처리를 해 주었어요.
참고로 Join 등을 이용할 땐, take()와 skip()을 사용해 주어야 해요.

21 ~ 27번째줄 까지는 조건절 즉, 검색 조건에 대한 처리 부분인데, usedBy와 newOrUsed 속성이 존재하는지를 먼저 확인하고, 존재한다면 해당 조건을 andWhere()를 이용해서 검색 조건을 처리할 수 있도록 해 주었어요.

그리고, 29 ~ 30번째 줄은 RequestDTO에 orderBy값이 true이면 내림차순이 될 수 있도록 처리해 주었어요.
기본값은 오름차순이니 true가 아니면 오름차순으로 처리될 거에요.

그런 뒤 33번째 줄에 getManaAndCount()를 호출하여 SQL Query를 실행하고,
결과로 하나의 배열 안의 0번째 배열에는 EquipmentEntity[]
그리고, 1번째 배열에는 Table에 존재하는 모든 요소 개수 값을 담은 number를 반환하도록 해 주었어요.

이렇게 동적 쿼리가 처리될 수 있는 메서드를 만들어 준 것이에요.

        📦 Update

node_modules/typeorm/repository/Repository.d.ts

TypeORM의 update()를 보면 Update할 대상 Entity를 선택하기 위한 기준 값을 전달해 줘야하는 걸 알 수 있어요.
이 때는 string, number, Date, ObjectId 등 여러 형식을 이용해서 기준을 잡을 수 있도록 만들어져 있는 걸 알 수 있어요.
그리고, findOptionsWhere<Entity> 형식으로도 기준을 잡을 수 있고, Update 대상 Entity를 선택할 수 있어요.

partialEntity는 Update할 내용이 담긴 Entity를 인자로 받는 부분이에요.
QueryDeepPartialEntity<Entity> 형식은 Entity의 일부 속성만을 가질 수 있도록 하는 것이에요.

 

 

src/app/equipment/repository/equipment.repository.ts

즉, 위의 메서드는 TypeORM의 update()를 호출하는 메서드이고, ID값을 전달하여 Entity를 선택하는 기준을 제시했고,
수정 값이 담긴 Entity를 전달함으로 해당 데이터베이스에 값이 변경될 값을 전달해 준 부분이에요.

참고로 Update를 할 때, save()를 사용해도 되기는 하는데,
update()를 사용하면 관계 및 기타 작업이 포함된 Cascade가 없는 원시 작업을 실행하게 돼요.

그렇기 때문에 빠르고, 효율적인 Update Query를 실행할 수 있답니다.
단, Entity가 데이터베이스에 존재하는지 확인하지 않기 때문에 이 메서드를 실행하기 전에 확인해 주어야 해요.

        📦 Delete

node_modules/typeorm/repository/Repository.d.ts

TypeORM delete()는 deleteQueryBuilder를 통해 실행되며, 삭제 작업이 성공하면 DeleteResult를 반환하게 돼요.

node_modules/typeorm/query-builder/result/DeleteResult.d.ts

Node. js 교과서

위 내용이 DeleteResult 클래스인데, 10번째 줄은 실행된 SQL Query의 원시 결과를 담는 멤버 변수에요.

15번째 줄은 Query에 의해 영향받은 Row(행) 또는 Document(문서)의 수를 담는 멤버 변수에요.
이 변수는 DELETE Query에 의해 영향을 받은 Entity 개수를 담고 있고,
일부 SQL Driver에서는 지원이 안될 수도 있어요. 그래서 Null 값이 담겨 있을 수도 있어요.

6번째 줄은 Static(정적) 메서드로 QueryResult 객체를 받아 DeleteResult 객체를 생성해요.

src/app/equipment/repository/equipment.repository.ts

결국 Repository에 있는 delete()는 위 메서드를 호출하는 것인데, ID값을 매개 변수로 전달해주게 되면
데이터베이스에 삭제 Query를 날리게 되고, 삭제 작업이 성공하면 DeleteResult 객체가 반환될 것이고,
affected 속성을 통해 영향 받은 행의 수를 확인할 수 있을 거에요.

하지만, 실패하게 되면 예외가 발생하게 될 것이에요.

참고로 반환되는 구체적 예외는 사용중인 ORM Driver에 따라 다를 수 있어요.
대부분 실패한 경우 예외가 발생하고, 예외 객체를 통해 오류에 대한 정보를 얻을 수 있게 처리된답니다.

    🔽 Equipment - Module

Nest.js에서 Module(모듈)은 Application을 구성하는 주요 구성 요소 중 하나에요.
개인적으로 Spring Boot와 비교했을 때, 이런 부분을 명시해줘야 한다는게 불편함으로 다가왔어요.

모듈은 특정 기능이나, 영역에 대한 코드를 구조화하고, Encapsulation(캡슐화)하며, 의존성 주입를 통해 모듈 간 서비스나, 기능을 공유할 수 있게 해 주는 부분이에요.

모듈은 다음과 같은 주요 특징을 가지고 있어요.

주요 특징	상세 내용
@Module	@Module를 사용하여 Module 정의. @Module은 Module의 Metadata를 제공하며, Nest.js에게 해당 Class가 Module임을 알려줌.
imports	Module은 다른 Module을 Import할 수 있으며, imports 속성을 사용하여 현재 Module이 의존하는 다른 Module 선언.
exprots	특정 Module에서 정의한 Service, Component 등을 다른 Module에서 사용할 수 있도록 내보내고자 할 때, exports 속성 사용.
providers	모듈은 Service, Repository, Factory, Provider 등의 제공자를 정의할 수 있으며, 제공자는 주로 의존성 주입을 통해 다른 부분에서 사용.

Nest.js의 모듈 System(시스템)은 Application을 여러 기능 모듈로 나누어 각 모듈이 독립적으로 개발되고, Test 되며,
필요한 경우 다른 모듈에서 재 사용될 수 있도록 해주는 친구에요.
이로써 Application 유지보구성과 확장성을 향상 시킬 수 있다고해요.

src/app/equipment/module/equipment-module.ts

위 모듈은 EquipmentModule이라는 Nest.js 모듈을 정의하는 코드에요.
9번째 줄을 통해 TypeORM을 사용하여 EquipmentEntity를 이 모듈에서 사용할 수 있도록 해 주었어요.

10번째 줄에서는 모듈에서 사용할 Provider(Service, Repository, Resolver) 등을 정의해 주었어요.
즉, EquipmentResolver, EquipmentService, EquipmentRepository를 사용하겠다고 정의한 부분이에요.

src/app.module.ts

위 코드는 모든 모듈을 중앙 집중식으로 관리하는 곳이라고 생각하면 돼요.

13번째 줄을 통해 환경 설정을 Load 하기 위한 ConfigModule을 설정해 주는데, CONFIG_VALIDATOR는 환경 설정의 유효성을 검증하는데 사용되는 것이에요.

src/common/config/config.validator.ts

 

src/app.module.ts

14 ~ 16번째 줄은 TypeORM을 Application에 설정하는 부분인데,
SqliteConfigProvider 클래스를 사용하여 비동기적으로 데이터베이스 설정을 구성해 준 부분이에요.

18 ~ 23번째 줄까지는 GraphQL 설정 부분인데, 여기서 Apollo Server를 사용하기 위해 정의해 주고, ApolloDriverConfig Option을 제공해 주었어요.

24번째 줄은 위에서 정의했던 EquipmentModule을 Import하여
Application에 특정 기능을 사용할 수 있도록 정의한 것이에요.

이렇게 모듈을 계층적으로 구성함으로 각 모듈이 특정 기능이나, 영역을 책임지도록 하고,
Application 전체를 모듈로 구성함으로써 의존성 관리를 하는 것이 Nest.js의 특징 중 하나에요.

 

 

GraphQL과 타입스크립트로 개발하는 웹 서비스:설계부터 개발·배포까지 따라 하며 완성하는 웹 풀

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

 

 

 

🧐 참고 자료

NestJS + typeORM + GraphQL 적용하기

 

 

 

카카오페이 | 마음 놓고 금융하다