NestJS는 @nestjs/graphql(Apollo Server 기반)을 통해 일급 GraphQL 지원을 갖추고 있습니다. 코드 우선(code-first) 접근(TypeScript 클래스와 decorator로 스키마를 정의하고, 스키마가 자동 생성됨)을 제공합니다 — 관용적인 NestJS 방식으로, 프레임워크의 decorator/DI 모델에 맞습니다.
({
: [
.<>({
: ,
: ,
: ,
}),
],
})
{}
@ObjectType() // GraphQL 타입
export class User {
@Field(() => ID) id: string;
@Field() name: string;
@Field() email: string;
@Field(() => [Post]) posts: Post[]; // 연관 타입
}
코드 우선에서는 데코레이트된 클래스(@ObjectType, @Field)가 스키마를 정의합니다 — TypeScript 타입이 GraphQL 스키마를 자동으로 생성하여, 둘을 동기화 상태로 유지합니다.
@Resolver(() => User)
export class UsersResolver {
constructor(private usersService: UsersService) {} // DI는 평소처럼 동작
@Query(() => [User]) // query: 사용자 목록 반환
users() {
return this.usersService.findAll();
}
@Query(() => User)
user(@Args("id") id: string) { // 인수를 받는 query
return this.usersService.findOne(id);
}
@Mutation(() => User) // mutation: 사용자 생성
createUser(@Args("input") input: CreateUserInput) {
return this.usersService.create(input);
}
}
Resolver(controller와 비슷하지만 GraphQL용)는 @Query와 @Mutation 핸들러를 정의하고, DI를 통해 service에 위임합니다 — REST controller와 동일한 패턴입니다.
@ResolveField(() => [Post]) // User.posts를 필요할 때 해석
posts(@Parent() user: User) {
return this.postsService.findByUser(user.id);
}
// ⚠️ 목록의 경우 이것이 N+1 쿼리를 유발할 수 있음 → DataLoader로 BATCH 처리
@ResolveField는 연관/중첩 필드를 지연 해석합니다 — 하지만 목록의 경우 N+1 쿼리 문제 위험이 있으며, DataLoader 배치로 해결합니다.
GraphQL: 클라이언트가 필요한 필드만 정확히 요청 (오버/언더페칭 없음),
단일 엔드포인트, 강타입, 복잡한/중첩 데이터 & 다양한 클라이언트에 적합
REST: 더 간단, 더 나은 HTTP 캐싱, 잘 알려짐 — 단순한 API에 적합
→ 유행이 아니라 필요에 따라 선택. NestJS는 둘 다 똑같이 잘 지원.
NestJS의 일급 GraphQL 지원은 가치가 큽니다. GraphQL의 이점 — 클라이언트가 필요한 데이터만 정확히 가져옴(오버페칭과 언더페칭 제거), 단일 강타입 엔드포인트, 복잡한/중첩 데이터의 뛰어난 처리 — 을 NestJS의 친숙하고 구조화된 모델로 가져오기 때문입니다.
현대 API를 구축하는 데 이를 이해하는 것이 중요하며, 특히 관용적인 코드 우선 접근(TypeScript 클래스와 @ObjectType/@Field/@Resolver decorator로 스키마를 정의하고, 스키마가 자동 생성되어 동기화 유지)은 NestJS의 decorator/DI 아키텍처에 자연스럽게 맞습니다 — resolver는 controller처럼 동작하며 주입된 service에 위임합니다.
타입, query, mutation, 해석되는 필드를 정의하는 방법을 알고, 중첩 데이터에 대한 N+1 쿼리 문제(그리고 해결책으로서의 DataLoader)를 인지하는 것은 핵심 시니어 수준 지식입니다.
마찬가지로 중요한 것은 주어진 프로젝트에 올바른 접근을 선택하기 위한 GraphQL 대 REST 트레이드오프를 이해하는 것입니다(유연하고 복잡하며 다중 클라이언트 데이터 요구에는 GraphQL; 강력한 HTTP 캐싱을 가진 더 단순한 API에는 REST).
GraphQL은 주요 API 패러다임이며, NestJS의 깔끔한 통합은 유연하고 효율적인 백엔드를 구축하는 데 의미 있고 자주 관련되는 능력으로 만듭니다.