GraphQL은 좀 짜증나요
(news.ycombinator.com)- GraphQL은 훌륭하지만, 좀 과장된 것 같음
- 초보~중급 개발자는 유튜브 보고 GraphQL을 사용하게 되는 것 같은데, 이건 잘못된 듯
- 장점
- 원하는 데이터를 쉽게 설명 가능
- 대역폭을 절약. 원하는 만큼 한번에 가져올 수 있음
- 데이터 소비자를 위한 문서 만들기 쉬움
- 구독을 더 쉽게 사용 가능
- API 호출을 묶는게 가능
- 단점
- 실제로 사용하기 고통스러움. 사용하는 백엔드에 따라 당신의 언어로 생성해주지 않으면 2개 또는 그 이상의 타입시스템을 관리해야함
- 맵/테이블/딕셔너리를 지원하지 않음. 이게 정말 큼. 하고 싶지 않지만 어디선가에선 {[key: string] : T} 를 쓰게됨
- API 버전 관리에 대한 명확한 방법이 없음. 끝내는 MyQueryV1.01 MyQueryV1.02 MyQueryV1.03 처럼 하게 될 것
- 페이스북이 GraphQL을 위해 의도한 솔루션/문제 세트를 당신이 처리하는게 아니라면 GraphQL을 사용하지 마세요
- 다른 시니어 개발자들은 어떤 현명한 말들로 신입 개발자들이 이 수렁에 빠지는 걸 구해주실 수 있을까요?
HN의 댓글들
- GraphQL의 가장 큰 문제는 DOS 공격을 방어하거나, 당신의 전체 DB를 다운받으려는 사람들로 부터 막기 위해 일을 해야함.
- 당신의 시스템에 무리한 부하를 주는 쿼리를 만들기가 매우 쉬움.
- 어떤 일들을 해야하는지 보려면 Shopify를 보면 됨. 리턴되는 데이터 양에 대해 레이트 리밋을 걸고, 커서와 페이지네이션도 처리. 인터넷에서 보이는 이쁜 GraphQL의 예와 달리 스키마가 거대하고 못생겼음
- GraphQL은 큰 기술회사들이 가진 조직 문제를 해결하는 훌륭한 방법임
- API를 유지 보수하는 팀과 변경을 요구하는 팀이 다른 경우 같이
- 조직이 커서 이럴 경우 변경을 하세월 기다려야 하니, GraphQL은 그럴 필요를 줄여줌
- 작은 조직이라면 그냥 모자란 부분을 직접 만들어 넣으면 되지 않을까 ?
- 의도된 것이건 아니건 GraphQL은 프론트엔드 개발자들이 백엔드 개발자에 대한 요구로부터 디커플링되어 더 빠르게 움직이게 해줌
- 백엔드 개발자가 데이터 모델을 만들고 GraphQL로 노출하면, 이 백엔드 개발자를 한번도 만나보지 못한 프론트엔드 개발자도 바로 사용이 가능
- 즉석에서 쿼리하는 내용을 변경하고, 원하는 것을 얻어갈 수 있음
- 모두가 빠르게 움직이게 해줌
- 하지만 백엔드 개발자인 나는 GraphQL이 정말 싫음
GraphQL 은 좀 짜증나죠 아주 짜증나는건 아니고요 좀 짜증 나지만 팀원간 커뮤니케이션 비용을 확실하게 줄여주기 때문에 그시간에 짜증 나는 부분을 해결하는게 더 효율적 입니다 그리고 생긴건 진짜 못생겼습니다 하지만 저는 GraphQL 를 쓰는 것을 권장 합니다 아무도 tRPC 쓰자는 것에 동의 안할 꺼니깐요 대부분 사람들은 재대로 써보지도 않고 지레짐작으로 기술 사용을 거부하고 그걸 해결하려면 막강한 권한으로 밀어붙여야 되는데 1~2 개 정도 기술은 그럴 수 있어도 모든걸 밀어 붙이면 잃는게 더 많아서 못하고 ... 그러니 결국 최대한 설득가능 한 수준이 GraphQL ㅠㅠ 똥같은 REST 이게 진짜 커뮤니케이션 비용 엄청 드는 나쁜 구석기 기술 ㅠㅠ
긱뉴스보다가 회원가입하게 만드는 글은 처음이네요 The bad 파트에 답 달아봤습니다.
클라/서버 각각에서 바라보는 장단점이 있겠지만 합쳐놓고 봤을 때 서버와 클라 사이의 빠져있는 추상화 레이어를 GraphQL 스키마가 채워준다는 제일 큰 value proposition 을 알면서도 일반적인 프로덕트에 REST 를 고려하겠다는 말은 개인적으로 조금 옛날 얘기 처럼들려요
The bad
- It is actually a pain to use, depending on the backend you are using you'll have to manage
two or more type systems if there are no code first generates in your language
결국 다른 말로하면 제대로 쓰면 좋다?군요 code generation 뭐 이런거 요즘 문제도 아니죠 툴링이 얼마나 발전했는데 - It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
Production Ready 에도 언급된 내용이지만 Type System 의 장점을 활용하면 딱히 고민할 필요는 없는 부분인 것 같네요 key: string 이 아니라 정확한 필드를 지정하면 될 일.. - No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
원래 GraphQL 은 버전리스입니다....
Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
React 도 페북이 해결하려는 문제를 푸는게 아니면 쓰지 말라는 말처럼 들리네요
GraphQL을 비교적 초기에 도입했었는데, 당시 백엔드 위주로 설명이 많았습니다. 그러다보니 백엔드에서 뭔가 좋을 것 처럼 인식이 있지 않나 싶습니다.
제가 이것저것 삽질해 본 끝에 그 뒤에 회사에 들어오신 분들이나 면접 보시는 분들이 질문하면, 백엔드에게는 힘들지만, 프론트엔드에게는 좋다라고 설명하고 있긴 합니다. :)
의도된 것이건 아니건 GraphQL은 프론트엔드 개발자들이 백엔드 개발자에 대한 요구로부터 디커플링되어 더 빠르게 움직이게 해줌
이게 GraphQL 을 쓰는 이유죠. GraphQL 스펙에도 프론트엔드를 위한거라고 명시되어있습니다 1
저도 새 스타트업에서 GraphQL 를 쓰기 시작했는데, 전 보다 API가지고 프론트엔드 엔지니어와 소통해야하는 횟수가 확실히 줄은거 같아요.
GraphQL 실제로 쓰기 전엔 생각지도 못한 문제들이 백엔드 엔지니어 입장에서 좀 고통스럽게 하긴 하지만 REST API 디자인 잘 하려고 머리싸매는 것 보단 훨씬 나은거 같아요.
어떤 기술도 완벽한 것은 없죠! 저는 단점을 해결하기 위해 드는 비용을 감내할 만큼 해당 기술이 필요하거나 다른 더 큰 문제를 해결한다면 도입해볼만 하다고 생각합니다. 기술/도구의 적합성은 언제나 사용자의 상황에 따라 결정되니까요.
한편으로, GraphQL이 공격받는 이유 중 하나는 '쉽다' 라는 이미지를 어필(?)해서가 아닐까 싶기도 하네요.
초반 Graphql 나와서 POC 프로젝트 진행할때 multipart가 제대로 지원되는 엔진이 없어서, 힘들었던 기억이 나네요..
저도 예전부터 소규모 프로젝트에 graphql 사용했다는거 보면 이건 너무 오버스펙 아닌가.. 하는 생각을 많이 했었는데 생각은 다들 비슷하네요