Node 백엔드를 공부하게되면서 express를 거쳐 nest를 경험하는데 있어 GraphQL도 경험할 수 있고 공부하게 될 수 있는 좋은 기회가 됐다.
graphql은 meta(전 facebook)에서 만든 쿼리언어다.
MySQL, PostgreSQL 등등과 같은 활용할 수 있는 API 쿼리언어인 것이다.
오늘은 graphql의 쿼리언어에 대한 내용과 이해보다는 이후에 사용에 대한 부분을 포인트로 진행하니 graphql에 대한 내용은 참고해서 공부하자! (🔗 graphql 기본이해)
처음의 graphql은 code first로 접했는데 우와! 스키마 구성없이 개발을 할 수 있다니?! 라는 신박함에 놀랬었고
그 이후레 schema first를 접하면서 데이터의 견고함으로 설계가 되다보니 역시 안정감이 폼미쳤다.라고 생각했다. 그럼 code first VS schema first를 알아보자.
(graphql에 대한 정리는 nest.js와 함께 이용했을때의 기준으로 작성했음.)
Code-first
graphql을 사용하는것과 사용하지 않는 경우는 아키텍쳐의 설계 플레이트를 Resolver로 사용하는것이다. (그렇지 않은 경우는 Controller를 사용한다.)
데코레이터(@) resolver를 사용하면서 코드로부터 type을 결정하게되고 그에따라 schema를 구성하고 생성하게 된다. 가장 큰 장점은 schema에 대해서 명확하게 정해지지 않은 상태에서 유연하게 생성하고 수정이 된다는 점이다. 어떻게 작성해야하는지에 대해서는 nestjs를 기준으로 샘플링이 매우 잘 되어있어서 직접 보는것이 눈에 들어온다.
장점은
- schema와 resolver간의 type safety를 보장
- 자신이 편한 언어로 개발 가능(자신이 사용하는 언어의 다양한 기능을 사용 가능)
- 낮은 learning curve
- 코드 중복의 최소화
🔗 code first sample github link
Schema-first
DB에 대한 설계를 진행하고나면 DB에 어떤게 데이터를 활용할 것인지 명확해진다.
그렇게되면 정적(?)으로 DB 설계에 따라 코드가 작성된다.
graphql의 data model을 나타내기 위해 만들어진 SDL(Schema Definition Language)를 사용하며 그렇기 때문에 schema first라고 불린다.
데이터 활용의 명확화로 인해서 모든 정의와 일치하게 코드를 만들어 나가야 한다.
그래서 schema first를 사용하게되면서 nest.js로 코드를 작성해야할때 작성 flow를 간략하게 나열한다면 schema.graphql(===gql) -> (필요하다면 input,interface) -> resolver ->service의 순서정도로 설계해 나가면 개발에 용이하다.
장점
- ASynchronous한 개발 가능
- 확실한 의사소통의 수단
- SDL을 제외한 document가 필요 없음
- 빠른 mocking으로 인해 개발 속도가 빨라짐
단점
- SDL과 Resolver간의 일치성을 보장할 수 없음
- run time에서만 알 수 있는 단점
- schema가 늘어갈 수록 실수의 가능성이 높아짐
- 다양한 도구들로 문제를 해결하려 하지만 근본적인 해결책이 되지 않는다.
🔗 schema first sample github link
그럼 둘 중에 뭘 써야하는건데??
정답은 없다.
두가지의 차이점과 목적은 결국 개발을 할 때에 무엇을 우선적으로 설계할 것인가 이다.
정답은 없다. 개발의 환경, 추구하고자 하는 목표에 따라 다를 수 있다.
아래 내용에 따라 내용에 대해서 알아보고 필요한 관점에 따라서 활용하길 바란다.
사견으로는, code first를 사용하고 그다음 schema first를 사용했을때 schema first의 방식이 매우 어색하고 어렵다고 생각했지만 지금까지 나의 경험으로는 DB를 먼저 설계, 구성하고 개발을 했었기 때문에 DB 구성이 명확한 상태에서 진행하게될때의 확실한 의사소통 수단으로 활용하기에는 schema first가 더욱 잘 맞았던 것 같다.
추가 참고링크
