- 2018년부터 6년간 사용 후, 진정한 GraphQL 열혈 팬이었지만 이제 회의가 듦
- 이제 GraphQL을 추천하지 않는 이유와 더 나은 대안이 무엇이라고 생각하는지에 대해 설명하고자 함
공격 표면
- GraphQL은 쿼리 언어를 노출하여 공격 표면을 넓히는 위험이 있음.
- 권한 부여와 관련된 문제는 특히 중요함.
- 모든 필드에 대해 적절한 권한 검사가 필요함.
- REST API에서는 엔드포인트마다 권한을 검사하는 것이 더 간단함.
권한 부여
- 모든 필드에 대해 사용자 권한을 확인해야 함.
- REST API에서는 엔드포인트마다 권한을 검사하는 것이 더 간단함.
속도 제한
- GraphQL 쿼리는 크기 제한이 없어서 서버에 큰 부담을 줄 수 있음.
- 쿼리 복잡성을 추정하고, 일정 복잡성을 초과하는 쿼리를 제한하는 방법이 있음.
- REST API에서는 요청 수를 제한하는 것이 더 간단함.
쿼리 파싱
- 잘못된 쿼리 문자열이 서버의 메모리를 과도하게 사용할 수 있음.
- 최대 오류 수를 설정하여 파싱을 중단하는 방법이 있음.
성능
데이터 페칭과 N+1 문제
- 필드 리졸버가 외부 데이터 소스를 여러 번 호출할 수 있음.
- Dataloader 패턴을 사용하여 문제를 해결할 수 있음.
- REST에서는 컨트롤러에서 N+1 문제를 해결하는 것이 더 간단함.
권한 부여와 N+1 문제
- 권한 부여 코드가 N+1 문제를 일으킬 수 있음.
- REST에서는 이 문제가 발생하지 않음.
결합
- GraphQL 코드베이스는 비즈니스 로직이 전송 계층에 강하게 결합됨.
- 통합 테스트가 필요하고, 디버깅이 어려움.
복잡성
- GraphQL의 보안 및 성능 문제를 해결하기 위한 다양한 방법들이 코드베이스의 복잡성을 증가시킴.
- REST 솔루션은 일반적으로 더 간단함.
대안
- OpenAPI 3.0+를 사용하는 JSON REST API를 추천함.
- 정적 타입 언어로 작성된 클라이언트가 있는 경우, OpenAPI가 더 나은 선택일 수 있음.
- OpenAPI는 자동으로 타입 안전한 클라이언트 코드를 생성할 수 있음.
GN⁺의 의견
- GraphQL은 강력하지만, 보안과 성능 문제를 해결하는 데 많은 노력이 필요함.
- REST API는 상대적으로 간단하고, 많은 경우에 더 적합할 수 있음.
- OpenAPI는 타입 안전성과 자동화된 도구를 제공하여 개발 생산성을 높일 수 있음.
- GraphQL을 도입할 때는 보안 및 성능 문제를 충분히 고려해야 함.
- REST와 GraphQL의 장단점을 비교하여 프로젝트에 맞는 기술을 선택하는 것이 중요함.