안녕하세요! 이번에 팀에서 GraphQL을 도입하였는데 배포시에 지속적으로 반복되는 이슈가 있어서 GraphQL을 사용하시는 다른 분들은 어떻게 대응하시는지 의견을 여쭙고싶어 질문드립니다 ㅎㅎ GraphQL 특성상 스키마의 필드가 제거되는 경우 조금 까다롭더라구요. 소스코드가 배포가 되어도 클라이언트에서 이전 버전의 번들을 사용해서 요청을 하게되면 서버에서는 제거된 필드를 요청하기 때문에 validation 에러가 뜨는 등 이렇게 클라이언트와 서버의 스키마 싱크가 맞지않는? 경우 배포시 항상 에러가 발생하더라구요. 그렇다고 매번 새로운 쿼리를 만들어서 버저닝을 하자니 조금 아닌 것 같기도 하고... 다른 분들은 스키마가 변경될때 어떤식으로 배포를 하시나요? GraphQL을 적용한지 오래되지 않아 아직 best practice를 못찾고있는것 같기도 합니다 ㅎㅎ 조언 많이 해주시면 감사하겠습니다

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/ 요거 책 추천드립니다 ㅎㅎ