https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
만약에 여러분들이 레거시나 migration 이슈없이 완전 새로운 독립된 graphql a...
# 질문
o
만약에 여러분들이 레거시나 migration 이슈없이 완전 새로운 독립된 graphql api 서버를 제작하려 할 때 처음부터 고려하면 좋다 할 만한 것들 있을까요? (또는 처음에 잘못쓰기 시작하면 나중에 고생하는 것들)
t
Schema Convention이요 ㅎㅎ 스키마 바꾸려고하면 골치아픕니다 ㅋㅋㅋ
o
Schema Convention 이라하면 주로 네이밍 컨벤션을 말씀하시는건가요??
t
네네~ 그리고 Input type을 어떻게 쪼개는지 같은것두요.
GraphQL 안 좋다고 하시는분들 대부분이 스키마 변경에 대한 경험이 너무 안 좋아서거든요. (왜 맨날 바뀌냐, 뭘 바꾼거냐) 처음에 스키마 컨벤션을 안 잡고 서버 개발을 하면서 계속 바꾸는 경우가 있는데 그러면 클라분들이 고통받아합니다...
처음에 네이밍 컨벤션 잘 잡고, Apollo Engine의 Schema Check를 CI에 포함해서 적극적으로 활용하시면 좋을거같아요
그리고 저는 추후에 떼어내기 쉽도록 파일 구조를 잡을때 GraphQL Layer랑 Data Layer (ORM) 분리를 철저하게 하는 편인데요. (지금은 Nexus + TypeORM 사용해요) 만약, TypeORM + TypeGraphQL 조합으로 한 Class 내에서 같이 만들면 추후에 RDMBS를 다른 REST?, gRPC 서비스로 떼어내기가 힘들거 같긴 합니다. 근데 이건 취향차이라서~
o
오호 너무너무 감사합니다. 
InputType 을 어떻게 쪼개는지
는 주로 어떤 기준으로 쪼개시나요? mutation 하나하나 기준으로 하나요?
t
저는 
where
, 
data
쌍을 써요 ㅎㅎ
Copy code
type Query {
  user(where: UserWhereInput!): User
}

type Mutation {
  createUser(data: CreateUserDataInput!): User!
  updateUser(where: UpdateUserWhereInput!, data: UpdateUserDataInput!): User!
  deleteUser(where: DeleteUserWhereInput!): User!
}
공통되는 부분을 빼도 괜찮은데 추후에 InputType이 추가될때 확장성이 별로더라구요.
Open in Slack
PreviousNext
Powered by