GN⁺: 6년 만에 GraphQL을 그만둔 이유
(bessey.dev)- 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의 장단점을 비교하여 프로젝트에 맞는 기술을 선택하는 것이 중요함.
Hacker News 의견
- GraphQL 도입 후 많은 문제를 겪었음. 권한 관리와 성능 문제로 인해 더 이상 사용하고 싶지 않음. 프론트엔드에서만 사용하면 좋을 수 있지만, 백엔드와의 통합은 복잡함.
- REST를 먼저 배우고 gRPC를 사용해보니 타입 안전한 API가 매력적이었음. GraphQL은 많은 이점이 없고, 데이터베이스처럼 동작할 때만 유용함.
- 두 개의 GraphQL 프로젝트에서 일했는데, 초기에는 작게 시작했지만 시간이 지나면서 복잡해졌음. 디버깅이 어렵고 성능 문제가 발생함. REST와 RPC가 더 간단하고 관리하기 쉬움.
- Hasura 창립자로서 GraphQL 사용의 진화를 보았음. GraphQL은 데이터 레이어가 없으면 구축하기 매우 어려움. REST 위에 GraphQL을 사용하는 것은 비효율적임. GraphQL의 주요 사용 사례는 여러 데이터 소비자가 있는 경우임.
- 프론트엔드 엔지니어들이 쿼리를 중앙 라이브러리에 저장하고 재사용하는데, 이는 GraphQL을 REST처럼 사용하는 것과 같음.
- OpenAPI, GraphQL, JSON/HTTP, gRPC를 사용해본 경험으로, GraphQL 쿼리를 제한하는 것이 성능과 보안 문제를 완화할 수 있음. Buf Connect가 대부분의 프로젝트에 가장 적합한 타협점임.
- Facebook에서 GraphQL을 사용한 경험으로, 많은 사람들이 GraphQL이 해결하려는 문제를 가지고 있지 않음. Facebook은 버전 관리와 복잡한 객체 모델을 다루기 위해 GraphQL을 사용함.
- Facebook에서 GraphQL이 잘 작동하는 이유는 모든 사용자가 로그인하고, 보안이 모든 필드에 내재되어 있기 때문임. SPA와 로그인 요구 사항이 있는 경우 GraphQL이 유용할 수 있음.
- GraphQL을 사용해보니 처음에는 좋았지만, 결국 많은 추가 작업과 중복이 필요했음. JSON-RPC 타입 엔드포인트로 시작하고 필요한 기능을 추가하는 것이 더 나았음.
- 작은 프로젝트에서 GraphQL을 사용해보니 거의 모든 부분이 좋았음. Apollo Client와 graphql-codegen을 사용해 Vue 3용 타입과 함수를 생성했음. 일부 문제는 있었지만, 타입 수준에서 많은 오류를 잡아줌.
저는 처음 봤을때부터 마음에 안들었어요. 아무래도 RDBMS 위주의 전통적인 개발 방식에 익숙하고 그 시각에서 봐서 그럴 진 모르겠지만, 왜 프론트엔드에 쿼리 방식을 고집해야 하며, 매우 복잡한 커스터마이징 및 타입 보장 등등 여러가지로 일반 REST 에 비해 매력이 없어요. API는 자유도가 너무 넓아도 문제라 봅니다. 실무에서 잠깐 써봤지만 이미 구축해서 망정이지 제가 아키 한다면 당장 쓰지 말라 할 겁니다.