일이 더 많아지는 건 사실인데, 이득을 볼 수 있는 환경이 구축된 서비스가 많지 않은 것 ...
# 잡담
h
일이 더 많아지는 건 사실인데, 이득을 볼 수 있는 환경이 구축된 서비스가 많지 않은 것 같아요. 제대로 써먹을려면 클라부터 똑똑해야 되서
h
GraphQL 잘 써먹는 조직은 혼자 그 일을 하지 않죠. 현대적인 기술은 결국 커뮤니티 리소스를 어떻게 활용하느냐에 따라서 할 수 있는 일과 쓸 수 있는 기술이 많이 달라지는데, 그걸 적응한 조직과 적응하지 못한 조직의 온도차가 큰 것 같아요.
제가 보기엔 GraphQL이 다루는 주제를 공유하는 곳은 지금 시장에 굉장히 흔해빠졌어요. 문제가 달라서 적합하지 않거나 도구가 충분히 발전하지 못해서 시기상조인게 아니라 도구가 다루는 “철학적인” 부분이 달라진게 문제같아요.
h
"철학적"인 부분이 뭔가요?
h
RESTful ?
아 사실 GraphQL 이 RESTful 구현의 일종이라고 생각하면 달라진게 없긴한데 (웹 자체에 의존하지 않고 JS에 의존하는 사실 빼고)
h
네 RESTful 측면에서는 오히려 GraphQL이 잘한 부분도 있다고 생각하는데...
어렵네요 잘 떠오르는 부분이 없군요
h
발표들에서 언급했던건 일단
모델을 공유 안하는 문제
ORM이 레이어마다 있음
이게 조직구조가 백엔드-프론트엔드로 나뉘어 초반에야 다루기 훨씬 편한데 장기적으로는 언어를 바꿔버리기 때문에 좋을게 없다고 생각하구요
(제품관점에서)
이건 스케일 상관없이 시간지나면 문제가 생기는 것 같아요
위에 공유해주셨던 ODK 사례에서도 잘 드러나는 부분이지 않나 싶구요 https://graphql-korea.slack.com/archives/CN0G9HJAJ/p1598887393028600
모델이 늘어나면 결국 SDK가 필요하다 -> 언제 다 만드냐 스키마/DSL로 찍자(OpenAPI, Protobuf) -> 동기화 점점 복잡해지는데 어쩌냐/오프라인 지원 한다는데 어쩌냐 (Managed cache layer) 순으로 문제 해결하는건 GraphQL이 아니여도 다 일어나는 수순인 것 같은데, GraphQL은 꽤 빠른 시점에 저런 부분을 고려하게 만드는 것 도 있고