This message was deleted.

GraphQL 필드 제거에 대해선 보수적인 게 좋은 것 같아요. @deprecated로 표시를 해놓고 차차 안쓰게 되는게 명확할 때 제거하심이?!

ㅎㅎ 감사합니다. 필드 제거뿐만 아니라 필드명 변경, input 타입에 필드 추가 등의 경우에서도 배포 이슈가 계속 발생해서 근본적인 해결책이 없을까 고민이 많이되네요 ㅠㅠ

필드명 변경보다는 오히려 새로운 필드를 추가하고, input 타입에 필드 추가는 nullable로, non-nullable이라면 default 값을 최대한 활용하는게 어떨까요? 근데 생각해보니 클라이언트에서 codegen을 통해 확인도 가능 할 것 같아요 ㅎㅎ

클라이언트에서 codegen을 통해 확인도 가능할 것 같다는게 어떤 말씀이신가요?

클라이언트에서 사용하는 쿼리 타입을 graphql code generator를 통해서 만들 수 있는데 이때 서버와 타입이 동일한지 확인하게 되거든요! 적절한 방식인지는 모르겠지만 ㅎㅎ https://www.graphql-code-generator.com/

근본적인 해결책은 스키마 변경을 최소화하고 변경이 있다면 해당 변경이 파괴적 변환을 발생시킬수있는지 잘 트래킹하는거겠죠? ㅎㅎ 제안: Apollo Studio에 Schema 변경시에 Breaking changes가 발생할 가능성이 있는지 체크해주는 “schema check”라는 기능이 있어요. 활용해보시면 좋을거같아요. 이건 GraphQL의 이슈라기보다는 스키마 변경이 잦은게 문제일거같네요. 일반 JSON API에서도 필드명이 변경되거나 삭제되면 에러가 발생하는것이 맞을거같아요. Opinion: GraphQL은 오히려 스키마 변경 사항을 스마트하게 추적할수있는 기반을 제공해주기때문에 더 에러를 줄일 수 있습니다

답변 감사합니다 ㅎㅎ 생각이 닿으면 닿을수록 말씀해주신대로 애초에 스키마를 좀 더 장기적인 관점에서 설계를 했으면 좋았겠다라는 결론이 나오더라구요. 좋은 의견들 주셔서 정말 감사합니다 :)

시행착오가 있는게 당연한거같아요 ㅎㅎ 저도 처음에 스키마 많이 갈아엎었고 고통스러웠던 기억이 있어요 ㅠㅠ (GraphQL이 별로인건가 고민했던 기억이 나네요 ㅋㅋ) 그치만 어느정도 노하우가 쌓이면 생산성을 훨씬 더 높일수있어요. 화이팅입니다! https://book.productionreadygraphql.com/ 요거 책 추천드립니다 ㅎㅎ