GraphQL Schema

(출처: https://blog.graphqleditor.com/graphql-schemafirst-codefirst)

 

GraphQL의 Schema-first, Code-first에 관련된 단어는 NestJS를 사용하면서 쉽게 접할 수 있다. NestJS에서 generate resource를 사용하면 아래 옵션에 따라서 자동으로 파일들을 생성해주는데 옵션으로 포함돼있기 때문이다.

 

GraphQL에서는 스키마를 생성할 때 두가지 접근 방식이 있다.

 

Schema-first (SDL, Schema Definition Language)

 

Schema-first 방식은 GraphQL 서비스에 대한 스키마를 먼저 정의한 다음 스키마의 정의를 일치시켜 코드를 구현하는 방법을 뜻한다.

 

type ChatRoom {
  id: Int
  title: String!
  admin: Person!
  group(limit: Int = 10): [Person]
}

type Person {
  id: Int
  name: String!
}

 

위와 같이 스키마를 먼저 작성하여 전체 관계를 직관적으로 나타낼 수 있으며, limit의 default value를 통해 group의 반환 값의 개수 또한 제한할 수 있다. 직관적이고 명확하기 때문에 러닝커브가 굉장히 낮으며 팀 커뮤니케이션에도 비교적 장애물이 적다. 하지만, SDL의 단점은 실제 코드 부분인 resolver 부분을 포함하지 않으며, 따로 작성할 때 반드시 SDL로 정의한대로 resolver를 작성해주어야한다.

 

장점

• 커뮤니케이션에서 비교적 적은 장애물 
• SDL을 제외한 document가 필요 없으므로 상대적으로 낮은 러닝커브
• 빠른 mocking으로 인해 개발 속도 증가
• 종속성 반전 원칙(DIP)을 따르면 더 추상적이고 덜 의존적

단점

• 스키마 정의가 Resolver와 계속적으로 동기화되어야 한다.
• lint time에 에러 발견 불가 따라서 코드량이 증가할수록 실수 확률이 증가한다.
• 위 단점을 다양한 라이브러리로 해결하려고 하지만, 근본적인 해결책은 아니다.

Code-first

Code-first 방식은 resolver를 먼저 작성하여 코드로부터 스키마를 생성하는 방법을 뜻한다. 스키마는 우리가 작성한 resolver을 기반으로 자동으로 생성해준다.

 

장점

• schema와 resolver 사이에서 type 안정성이 보장된다.
• 다른 여러 라이브러리를 사용하지 않더라도 Schema-first가 많은 라이브러리로 해결하는 문제들을 쉽게 해결 할 수 있다.
• 코드 중복이 적어진다. (+ NestJS를 사용하기 때문에 boilerplate 조차 작성할 필요가없다.)

단점

• 둘다 처음 접하는 입장에서는 SDL과 비교해서 직관적이지 못해 비교적 러닝 커브가 높다. (하지만, 다른 방면으로 생각해보면 자신이 원하는 언어 내에서 코드를 작성하므로 조금 더 러닝커브가 낮다고 생각할 수 있다.)
• 구현과 스키마가 동시에 포함돼있기 때문에, 가독성이 많이 떨어진다.

 

선택

(출처: https://blog.graphqleditor.com/graphql-schemafirst-codefirst)

두 방법 모두 장단점이있지만, 언제나 그렇듯이 두 방법을 혼용해서는 사용하지말자.

 

Schema-fist를 사용하면 Schema를 기반으로 Client에서 mock data를 만들 수 있으므로 Client와 Server가 모두 동시에 작업을 진행할 수 있어 개발 시간을 단축할 수 있다.

 

우리는 한 사람이 기능 단위로 일을 분배해서 개발하므로 front, back 둘다 개발한다. 따라서 보다 안정적인 Code-first 방식을 선택했다.