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용 타입과 함수를 생성했음. 일부 문제는 있었지만, 타입 수준에서 많은 오류를 잡아줌.