클라/서버 각각에서 바라보는 장단점이 있겠지만 합쳐놓고 봤을 때 서버와 클라 사이의 빠져있는 추상화 레이어를 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 도 페북이 해결하려는 문제를 푸는게 아니면 쓰지 말라는 말처럼 들리네요
긱뉴스보다가 회원가입하게 만드는 글은 처음이네요 The bad 파트에 답 달아봤습니다.
클라/서버 각각에서 바라보는 장단점이 있겠지만 합쳐놓고 봤을 때 서버와 클라 사이의 빠져있는 추상화 레이어를 GraphQL 스키마가 채워준다는 제일 큰 value proposition 을 알면서도 일반적인 프로덕트에 REST 를 고려하겠다는 말은 개인적으로 조금 옛날 얘기 처럼들려요
The bad
two or more type systems if there are no code first generates in your language
결국 다른 말로하면 제대로 쓰면 좋다?군요 code generation 뭐 이런거 요즘 문제도 아니죠 툴링이 얼마나 발전했는데
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 이 아니라 정확한 필드를 지정하면 될 일..
원래 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 도 페북이 해결하려는 문제를 푸는게 아니면 쓰지 말라는 말처럼 들리네요