다들 팀내에서 GraphQL 스키마 디자인 가이드를 어떻게하고 계신지 궁금합니다 ㅎㅎ 저...
# 질문
i
다들 팀내에서 GraphQL 스키마 디자인 가이드를 어떻게하고 계신지 궁금합니다 ㅎㅎ 저희는 두가지 스텝으로 가이드가 이뤄지는데요. 잘 작성된 스키마 엔티티 공유 코드리뷰로 미진한 부분 보완 단발성? 이라고 해야할까요, 전체적인 관점에서 룰이 잘 공유가 안되더라구요. 스키마 설계에 대한 방향성도 공유가 안되구요 🤣 이번에 새로 가이드가 필요한 팀원이 5명 이상이라... 결국 스키마 디자인 문서를 작성하려고 하는데, 얼마나 효과적일지 모르겠네요 ㅎㅎ 다른 분들은 어떻게 하고 계실지 도움을 구해봅니다 🙇‍♂️
u
저희 회사엔 스키마 디자인을 가이드하는 그룹이 따로 있어요. 그 그룹에서 best practice도 관리하고 새로운 스키마를 디자인할 때 컨설팅도 하고 있어요.
i
와우, 별도 디자인 그룹이 따로 있는건 엄청 부럽네요 ㅎㅎ 전사적으로 GraphQL 에 대한 강한 확신이 있나봐요 👍 해당 그룹에서는 아래처럼 가이드가 이뤄지는 상황인거죠? 1. best practice 기반 셀프 디자인 2. 모호한 부분에 대한 추가적인 컨설팅 요청
u
네 맞습니다. 디자인만 담당하는 엔지니어들이 따로 있는 건 아니고 초창기부터 사내 GraphQL ecosystem에 참여했었던 엔지니어들이 참여하고 있어요. 디자인하는 사람과 implement하는 사람이 다르면 best practice가 현실을 반영하지 못할 것 같아 그런 구조는 좋지 않을 것 같아요.
i
네, 말씀하신 부분에는 완전히 동의합니다. 설계만 별도로 이뤄지는 경우, 의도하지 않더라도 현실을 반영하지 못하는 경우가 생길 수 밖에 없으니까요~ 혹시 예전에 GraphQL DevOps 도 별도 조직에서 이뤄진다고 말씀해주시지 않으셨나요? 예전에 schema tooling 관련 질문에서 대답해주셨던 기억이 있어서 여쭤봅니다 ㅎㅎ
u
DevOps라고 하시면 툴링 얘기신가요? UI 쪽은 UI 엔지니어들끼리 알음알음하고 있지만 ㅠㅠ 서버쪽은 플랫폼 팀에서 지원해주고 있어요 (프레임워크, 모니터링 등)
i
서버쪽 모니터링, Schema Check 등 얘기였어요, 다른 분이었나봐요, 혼란을 드렸네요 ㅜㅜㅎㅎ
👍 1
그런데 서버쪽은 스키마 디자인 컨설팅 / 도구 지원까지 있다면, 환경이 정말 잘 구축되어있네요 👍
다른 분들도 어떻게 하고 계신지 궁금하네요~ 대부분은 별도 지원 없이 팀 내에서 작은 규모로 이뤄지고 있을 것 같아서요 ㅎㅎ
t
전체적인 관점에서 룰
요건 어떤 의미실까요?
i
요건 어떤 의미실까요?
Do & Don't 형태로 정리할 수 있는 내용입니다~ 예를 들면 pagination 스키마는 아래 세가지 형태 중 한가지만 사용해야 합니다
Copy code
1. page, size
2. limit, offset
3. first, after
pagination meta 정보는 선택한 형태에 따라 아래 위치에 있어야 합니다
Copy code
1. page, size or limit, offset
type EntityPagination {
  items: [Entity],
  totalCount: Int!
}

2. first, after
type EntityConnection {
  edges: [EntityEdge]!
  # totalCount 는 pageInfo 안에 위치합니다
  pageInfo: EntityPageInfo
}
t
아아... 컨벤션이군요 ㅎㅎ 저희는 Production Ready GraphQL의 Schema cheatsheet 를 일단은 공통으로 쓰고있어요. 사내에 아직 컨벤션 문서는 없습니다 ㅎㅎ
👍 1
i
과도기 적으로 적용한 스키마가 있어서, 기존 스키마에는 totalCount 의 이름이나 위치가 여러군데 퍼져있거든요 ㅎㅎ 그래서 이런거를 통일하는 룰을 정했는데, 팀내 공유는 잘 안되더라구요 ㅜㅜㅎㅎ
Production Ready GraphQL 은 한번 구매해서 확인해볼께요~ 감사합니다
👍 1
t
스키마 기반으로 커뮤니케이션하는 문화를 만들어나가는게 참 좋은데 ㅠㅠ 결국에는 커뮤니케이션도... 개발하는 방식과 툴에 맞춰서 따라가게 되는거 같습니다.
PRG에 Schema Design Cheatsheet가 딱 원하시는 모양일거같네요 ㅋㅋ
😁 1
i
네 그렇더라구요. 스키마 기반 커뮤니케이션을 해보다보니 가장 어려운게 마인드 셋을 바꾸는 거더라구요. 기존에에 "일단 한번 API 대충 만들어보고 적용해가면서 바꿔보죠" 라는 생각을 가지신 분이 있었는데, 커뮤니케이션 해보다가 포기했었습니다 ㅜㅜㅋㅋ
k
저흰 graphql schema는 아니지만 protobuf 기반의 idl, db schem를 관리하는 ddl 2개의 레포를 통해 중앙에서 스키마를 관리합니다. 스타일 가이드를 맞춘다는 명목 하에 리뷰 개수가 많아지다보면 의도치 않게 감정을 상하는 경우가 있을 수도 있어 각 레포의 README에 하나씩 원칙을 업데이트 해나가면서 진행하고 있습니다. 리뷰할 땐 가이드 링크를 최대한 주고 있구요
ohh 2