서론
얼마 전 Apollo GraphQL 기반 express.js 서버와 Nest.js 서버의 통합 작업을 진행했다.
이 과정에서 타입스크립트로 실행했을 때에는 성공하였으나 컴파일 후 자바스크립트 파일을 실행하였더니 GraphQL 스키마 병합 오류가 발생하여 디버깅하는데 며칠 동안 고생하여, 관련 내용을 기록 차 간단히 정리해보았다.
본론
GraphQL 서버의 스키마 관리 방식에는 schema first 와 code first 가 있다. schema first의 경우 graphql 스키마 정의 언어를 사용하여 스키마를 명시하고, code first의 경우 코드에 데코레이터를 사용하여 스키마를 생성한다.
express 서버는 schema first 방식이었기에 엔티티 별로 정의된 스키마 정의 파일들을 불러와 통합해야 했다. 이 때 __dirname 을 사용하였는데, 컴파일 후 이 코드를 포함한 파일의 위치가 변경되며 스키마 정의 파일들을 불러올 수 없어 빈 데이터가 생성되었다.
아쉬운 점은 빈 값으로 subgraph 스키마를 생성(=통합)하는 경우 바로 오류를 발생시키지 않고 우선 기본 값인 1버전 디렉티브 정의를 생성하고 이를 nestjs 가 생성한 2버전 디렉티브 정의와 병합하는 시점에 충돌오류를 일으켜서 원인을 찾는 데 어려움을 겪었다. 그래서 경고 로깅을 추가하는 것이 어떨지 이슈를 올려보았다.
외부 파일을 사용할 때에는 절대경로를 활용하거나 컴파일 시에 해당 파일도 함께 dist에 복사하는 과정이 필요한 것 같다.
회고
가장 큰 힌트는 타입스크립트와 자바스크립트 간 오류 유무의 차이였는데, 이를 간과하고 오류 메시지에 매몰되어 apollo와 graphql 라이브러리 버전을 바꿔가며 시간을 썼다. 검색을 여러 번 해보아도 문제가 풀리지 않을 때에는 표면이 아닌 기본적인 사항부터 체크해보는 것의 중요성을 알게 되었다.
'배운 것들 > 그 외' 카테고리의 다른 글
| Nest.js의 인터셉터를 이용하여 인풋 필드에 권한 체크를 추가하기 (2) | 2025.12.24 |
|---|---|
| Elasticsearch 로 기업 검색 구현하기 (2) | 2025.11.06 |
| 스탬피드 캐싱 방지하기 (6) | 2025.07.24 |
| GraphQL 요청당 필드 캐싱으로 인한 이슈 해결 (1) | 2025.06.27 |
| Elasticsearch 를 활용한 프로젝트를 경험하면서 느낀 점 (2) | 2025.06.26 |