# 6년 만에 GraphQL을 그만둔 이유

> Clean Markdown view of GeekNews topic #15097. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=15097](https://news.hada.io/topic?id=15097)
- GeekNews Markdown: [https://news.hada.io/topic/15097.md](https://news.hada.io/topic/15097.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-05-31T09:41:38+09:00
- Updated: 2024-05-31T09:41:38+09:00
- Original source: [bessey.dev](https://bessey.dev/blog/2024/05/24/why-im-over-graphql/)
- Points: 22
- Comments: 8

## Topic Body

- 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의 장단점을 비교하여 프로젝트에 맞는 기술을 선택하는 것이 중요함.

## Comments



### Comment 25983

- Author: savvykang
- Created: 2024-06-06T10:57:57+09:00
- Points: 1

[GraphQL은 좀 짜증나요 (2022)](https://news.hada.io/topic?id=7145)

### Comment 25874

- Author: yangeok
- Created: 2024-06-03T11:11:06+09:00
- Points: 1

rpc 대유행의 시대가 온다

### Comment 25820

- Author: ahwjdekf
- Created: 2024-06-01T21:11:24+09:00
- Points: 1

그럼 그렇지... 뭔가 fancy 한게 나왔다고 덥석 물고 빨아서는 안되는 거지.. 이젠 orm 차례다. 너도 멀지 않았다...

### Comment 25904

- Author: rockmkd
- Created: 2024-06-04T08:40:22+09:00
- Points: 2
- Parent comment: 25820
- Depth: 1

orm은 나온지 20년이 넘었는데요...

### Comment 25778

- Author: [hidden]
- Created: 2024-05-31T13:24:12+09:00
- Points: 2

[숨김 처리된 댓글입니다]

### Comment 25775

- Author: cometkim
- Created: 2024-05-31T12:13:28+09:00
- Points: 1

2018년이면 PQ가 그다지 새롭지도 않았을텐데(사실 GraphQL이 처음 발표 될때부터 권장됨) 6년간 시도를 안했다는게 놀랍네요...

### Comment 25763

- Author: surfindia
- Created: 2024-05-31T10:52:16+09:00
- Points: 1

GraphQL 을 손수 모두 구현하기에는 위에서 말한 모든 이유로 인해 복잡도, 안정성 면에서 어렵습니다. hasura 나 postgraphile 같은 layer 를 DB 위에 두고, 필요에 따라 graphql 이든 rest 든 이 layer 에 추가하는 식으로 개발하는 것이 좋을 것 같아요

### Comment 25751

- Author: neo
- Created: 2024-05-31T09:41:39+09:00
- Points: 3

###### [Hacker News 의견](https://news.ycombinator.com/item?id=40521518) 
- 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용 타입과 함수를 생성했음. 일부 문제는 있었지만, 타입 수준에서 많은 오류를 잡아줌.