graphql을 사용하면서 schema를 바탕으로 code가 매치되게 할 수 있고, 코드를 바탕으로 schema가 생성되게 할 수 있다.
두 케이스 모두 graphql 서비스의 작동을 하게 되지면 어떤 접근법을 사용하느냐에 따라 더 많은 기능을 사용할수도 사용하지 못하게 될수도 있고, 더 쉽거나 어렵게 작업하게 될 수도 있다.
schema first는 graphql의 schema를 먼저 정의하고 그 schema 정의에 맞게 코드를 작성하는 방법을 말한다. schema를 작성하기 위해서는 그래프큐엘의 data model을 나타내기 위해 만들어진 SDL(Schema Definition Language)를 사용하며 그렇기 때문에 schema first라고 불린다.
#title은 string으로 된 value를 갖게 되며, !로 항상 반드시 가져야하는 value라는 의미를 나타낼 수 있다.
type Film {
id: Int
title: String!
}
graphql이 그래프 형태의 관계들을 쿼리하여 사용할 수 있는 만큼 다음과 같이 타입으로 관계를 지정할 수 있다.
type Film {
id: Int
title: String!
director: Person!
actors(limit: Int = 10): [Person]
}
type Person {
id: Int
name: String!
}
film이 많은 actor들을 가직 수 있는 만큼 리스트의 형태로 표현되며 limit의 default value를 통해 몇개의 요소들을 return 할 것인지 제한할 수 있다.
위의 예제를 통해 알 수 있듯 SDL의 가장 큰 장점은 간단하고 명확하며, 익숙하거나 익숙하지 않는 사람 모두에게 이해하기 쉬우며 data model을 생성하는데 있어서 팀 가운데 커뮤니케이션 툴처럼 사용될 수 있다.
하지만 위에서 보여주는 SDL의 단점은 필드의 값들을 계산할 실제 코드를 나타내는 resolver를 포함하지 않는다는 것이다. SDL은 그 자체만으로 전부가 될 수 없으며 스키마 정의와 resolution을 나누어 사용하게 된다.
두번째 단점으로는 resolver 코드가 SDL의 정의와 정확하게 일치해야한다는 점이다.(String!으로 정의했다면 String이나 Int!가 아닌 정확히 String!이여야한다.)
code first 접근 방식에서는 resolver를 먼저 작업함으로서 시작하게 된다. 그 후 그 코드로 부터 schema를 generate하게 된다. 그렇기 때문에 schema를 여전히 갖게 되지만 수동적으로 생성하지 않고 script를 통해 생성하게 되지만 코드만으로 schema를 이해하기란 SDL의 정의를 보는것 만큼 이해하기 쉽지 않다.
TDD(test-driven-development)와 비슷하다. 개발자는 처음 작업을 시작할 때 반드시 여러 use case와 사용자 편의성을 고려해야하며 마지막 결과는 더 모듈화되고 유지보수 가능한 디자인을 갖을 수 있다.
DIP(Dependency Inversion Principle), 의존성 역전 원칙을 따른다.
👉🏻 DIP란?
상위 모듈은 하위 모듈의 구현에 의존해서는 안되며 하위 모듈이 상위 모듈이 정의한 추상에 의존해야 한다.
DIP에서 역전이란 실제 호출 및 사용관계의 역전이 아닌 절차적 흐름의 구조적 디자인에서 발생하던 하위 레벨의 변경이 상위 레벨에 미치는 변경을 끊자는 의미이다. 상위 모듈에서 하위 모듈의 구현을 직접 의존하는 것이 아닌 하위 모듈이 상위 모듈이 정의한 추상을 구현하게 되므로 역전이라고 한다.
schema는 api의 mock data를 사용할수 있게 하므로 백엔드의 api를 기다리지 않고 동시에 client가 작업에 들어갈 수 있다.