This message was deleted.
# 잡담s
Slackbot
05/07/2021, 4:01 PMThis message was deleted.
👀 1
h
Hyeseong Kim
05/07/2021, 5:00 PM음... 이해도 되고 굉장히 유용하겠네요. 다만 스키마 nullability 디자인의 중요성을 떨어트릴까봐 다소 걱정되긴 합니다
Hyeseong Kim
05/07/2021, 5:02 PMMarking Schema fields as non-null can introduce particular problems in a distributed environment where there is a possibility of partial failure regardless of whether the field is intended to have null as a valid state.이걸 인정하면 외부 시스템에 의존하는 모든 필드는 nullable 하게 표현되고 모든 nullability 는 클라이언트에서 결정해야 한다고 비약할 수 있는게 아닌가 싶기도 하고요
Hyeseong Kim
05/07/2021, 5:04 PM그리고 재귀 적용 항목은 없었으면 좋겠군요
Hyeseong Kim
05/07/2021, 5:05 PM저도 이거 되면 당장 필요한 곳이 있긴해요. 원래 정적분석 짜서 해결해야 하는걸 그냥 클라이언트에 선택권을 쥐어줄 수 있으니...
Hyeseong Kim
05/07/2021, 5:06 PM허?
Hyeseong Kim
05/07/2021, 5:09 PM페이스북 엔지니어가 언급한대로 프래그먼트 사용하면 복잡성이 좀 높아보이네요 (그리고 당연히 프래그먼트를 써야함)
Relay는 자체적으로 컴파일러가 있고 런타임통합이 있으니까 sensible default 를 제어할 수 있는데 보편적으로는 어렵지 않나...
Hyeseong Kim
05/07/2021, 5:44 PM그리고 스키마 안정성을 떨어뜨리겠다는 생각도 들어요. 사실상 모든 필드에 대해서 nullability 의미론을 무효화 할 수 있게 된다는 소리니까 Breaking change 범위도 훨씬 넓어지겠네요
u
김영민
05/07/2021, 7:07 PM회사 내부에선 언제 새로운 microservice가 생겨서 federate할 지 모르는 상황이라 이미 모든 필드는 nullable해야한다는 쪽으로 가고 있어요 그러다보니 이런 syntax/directive가 더 필요해지긴 했네요 ㅎㅎ https://graphql-korea.slack.com/archives/CN0G9HJAJ/p1620406976092600?thread_ts=1620403285.091600&cid=CN0G9HJAJ
김영민
05/07/2021, 7:08 PMfragment 끼리 겹치는 건 어떻게 할지 좋은 생각이 안나고 있어요 ㅜㅜ
김영민
05/07/2021, 7:08 PMRelay 아닌 client들은 미리 compile 하는 스텝이 필수도 아니라서 linting이나 compile check을 할 수도 없고
김영민
05/07/2021, 7:09 PM어떤 새로운 breaking change가 생기는 건가요?
https://graphql-korea.slack.com/archives/CN0G9HJAJ/p1620409460093600?thread_ts=1620403285.091600&cid=CN0G9HJAJ
h
Han BaHwan
05/08/2021, 12:29 AM위 스펙대로면 기존 코드에는 breaking changes가 없을 것 같고, 이후 유지보수할 때 늘어날 수도 있겠다 싶긴 하네요
Han BaHwan
05/08/2021, 12:34 AMMake non-nullability apply recursively 스펙은 있으면 진짜 편리할 것 같은데 쓰다가 partial optional이 필요할 때엔 어떻게 해야 될지 모르겠네요. (안쓰면 되겠지만)
h
Hyeseong Kim
05/10/2021, 4:45 AM어떤 새로운 breaking change가 생기는 건가요?아주 새로 생기는 건 아니고요. 기존 스키마 레벨 nullability 에선 non-null 필드에서 null 허용으로 변경하는게 타입 레벨에서 브레이킹 체인지가 아닌게 보장되지만 그걸 client 에서 결정하게 타입 레벨 nullability 는 신뢰할 수 없게 되니까요
u
김영민
05/10/2021, 9:52 PM아 그렇군요. 저는 client가 nullable field를 nonnullable로 생각하는 시점에서 리스크는 client가 지는 게 당연하다고 생각했어요 ㅎㅎ typescript에서 any 쓰는 거랑 같은 거죠
h
Hyeseong Kim
05/14/2021, 9:51 AMGraphQL Meetup 얘기는 잘 되었나요 👀 미팅노트 이제 읽어보려는 참인데
Hyeseong Kim
05/14/2021, 9:55 AM역시 Relay 가 RFC 여기저기서 Prior art 로 활약하는군요
u
김영민
05/14/2021, 9:03 PM페이스북이 가장 열심히 쓰니까요 ㅎㅎ 이 Proposal은 Stage 1이 되서 implementation 해보는 게 다음 스텝이에요
김영민
05/14/2021, 9:04 PM방식 차이는 있는 것 같지만 다들 필요하다고 생각하더라구요