https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
This message was deleted.
# 잡담
s
This message was deleted.
u
@문운기 🥳
u
UI 드리븐 스키마 설계 근거를 찾아야 해요
단단한 근거!
급해요
ㅎㅎㅎㅎㅎㅎㅎ
h
하이용
어떻게 도와드리면 될까요 ㅋㅋ
#C01PACBHTNE 가 필요하신건가요
u
힘 겨루기 입니다.
h
아니면 도입근거를 찾으시는?
u
일종의 힘겨루기
데이터 기반 모델링이냐, UI 드리븐 모델링이냐의 힘겨루기
h
맥락을 주시면 긍정의견 부정의견 다 던져드리겠습니다
아 대충 알거같은데
저는 유즈케이스 드리븐이 맞다고 생각합니다. GraphQL 의 장점은 도메인을 바깥에서 바라보게 한다는데 있어요
u
아 맥락은 대략 이렇습니다. REST -> GraphQL 넘어가는 건 오케이 너무 좋다. 그럼 그래프 구조의 데이터 모델링을 해야하는데, 데이터 기반이냐 UI 기반이냐 이런 맥락이에요
h
REST나 GraphQL 이나 본질은 stateful client 를 얼마나 쉽게 "생성"할 수 있냐라서
데이터 기반 모델링은 클라이언트에 별로 도움되진 않습니다
도메인 유즈케이스 기반으로 모델링을 해야....
u
도메인 유즈케이스
키워드 겟!
부정의견은 혹시 어떤 건가요
u
살짝 무슨 느낌인지 알거같네요
h
음 아까 맥락을 잘못 파악해서 다른 생각을 하고 있었는데
일단 아직은 모르겠습니다 ㅋㅋㅋ
그냥 Server-driven UI 같은거 고민하시는 줄
순수 모델링 얘기였군요
근데 왜 Reason Seoul graphql 채널에서 얘기 안하시고 일로 오셨나요
어차피 양쪽다 답변달 사람이 똑같은데..ㅋㅋㅋ
😂 3
u
server driven UI 마침 제가 착각하고 키워드 던졌다가 역공 당했어요
h
사실 스키마 두 벌 있어도 됩니다
u
아 저도 둘 중 하나는 아니라고 생각하고 있어요
h
옛날에 Prisma 1 이 GraphQL SDL 쓰던 시절에 워크플로우가 그런식이였어요. DB 스키마 GraphQL 로 한 벌 짜고 API 스키마 한벌 더 짜고
u
데이터 기반 모델링 + (유즈 케이스 기반 모델링)
h
GraphQL 은 SDL이랑 Operation definition 이 분리되어 있잖아요
그래서 사실상 "엔드포인트를 만들지 말고 엔드포인트 생성기를 만들자" 에 가깝거든요
u
데이터 기반 모델링 스키마로는 UI에 필요한 데이터 페칭 할 때 쿼리가 어마무시하게 복잡해질 수도 있을 것 같은데, 당근은 어떻게 하고 계세요?
당근은 어떻게 하냐고 말하니까 좀 이상하군요;;
h
순수 RESTful 엔드포인트가 (HATEOAS 없이) 멀티 클라이언트 환경에서 망가졌던 사례들을 떠올려보면
실제 쿼리가 어떤식으로 사용되는지를 고려하는건 API 디자인에서 꽤 중요한 부분입니다
그래서 저는 이걸 아예 documents-first 라는 접근방식으로 고착화 시켰어요
쿼리를 먼저짬
Figma 를 유심히 들여다보면 GraphQL fragments 들이 보여요
그걸 병합하면 스키마가 어떤식으로 발전해야하는지 보입니다
u
GraphQL 은 SDL이랑 Operation definition 이 분리되어 있잖아요
이게 오히려 데이터 기반 모델링만 하면 되는 것 아니냐의 근거도 되잖아요
h
음
순수하게 데이터에 집중할 수록 유즈케이스 표현이랑 멀어지는 경우가 많은데요
뭔소리냐면 파생 상태를 표현하기 위해 클라이언트에 별도의 "상태관리 레이어" 가 필요해집니다
리액트에서 상태관리 어쩌고 얘기가 그렇게 큰 건 다 클라이언트와 기반이 되는 API 디자인이 구려서 그래요
다행히 GraphQL 은 꽤 유연하게 enhance가 가능해서
둘 다 동시에 시도하실 수 있는데요
여러가지 방법이 있습니다. 서버가 필요에 따라 root field 이던 derived field 이던 다 제공해놓고 뭐가 더 많이 쓰이는지 보거나
아니면 클라에서 직접 리졸버를 구현하거나... ㅋㅋㅋ
u
오노 ㅎㅎ
h
이걸 잘 설명하는 원칙으로 아폴로에서 소개한게
https://principledgraphql.com/ 이 사이트에요
u
흥미로워보입니다!
u
오 감사합니다.
아 연오님 안오셨으면 나만 알고 근거 댔을텐데
😂 1
똑같은 선에 섰군요
h
DDD 로도 비슷하게 설명할 수 있습니다
u
적을 알고 나를 알아야...
😤 1
h
실제로 일반적인 GraphQL 서버 아키텍처는 DDD 프랙티스의 많은 부분을 구현하고 있습니다. GraphQL이 메타언어처럼 작동할 뿐 https://gist.github.com/OlegIlyenko/a5a9ab1b000ba0b5b1ad
GraphQL SDL 이 데이터 구조를 표현하는 언어로도 쓸만한건 사실인데, API 표현까지 실제 애플리케이션에 필요한 것과 거리를 벌려서 다시 임피던스 불일치 문제를 재현할 필요는 없는것이고요
GraphQL 은 언어 사양에도 스스로를 "Product-centric language" 라고 표현하고 있어요
👍 2
이걸 좀 데이터(그래프)스럽게 일관적인 패턴으로 표현하는 프랙티스가 Relay specification 인데
아시다시피 관계 문제에 그래프 컨셉(Node, Edge)을 도입해서 스키마 디자인을 합니다.
마치 옆동네 JSON:API 랑 비슷한 물건인 셈이죠
Relay 스타일 스키마랑 클라이언트 스키마 확장 같은걸 활용하시면 두분 다 만족하시는 이상적인 디자인이 나올거라 생각하는데요
이게 진입장벽이 있는 편이에요
퍼블릭 API 만드시는게 아니라면 저는 시작으로 UI 에 맞추는걸 더 권장합니다.
그게 더 GraphQL 장점도 많이 접하면서 서로 API 스키마 논의하는 연습을 이어나가기 쉬워요.
이게 진입장벽이 있는 편이에요
아니 사실 그래프를 활용하는게 튜플/정규화보다 쉬워야하는데, 실제 세계에선 반대인거 보니 사람들이 너무 고였어요
반대의견은 뭐 그렇습니다. 다른 API format 이라고 크게 다르진 않고, 실제 데이터 액세스랑 멀어지면 클라이언트(유즈케이스) 가 확장될 때 유연성이 떨어지죠.
뭐 애초에 정답이 있는 문제는 아니니... 케바케로 잘 찾아가시면 되겠습니다
u
UI 기반으로 스키마를 정의하면 UI의 변화에 따라 스키마도 계속 변해야하잖아요? 이 지점은 REST에 비해 나아지는 점이 있나? 싶은 생각도 들었어요. 선배인 당근마켓은 어떻게 하고 계세요?
(아, 물론 REST도 UI 기반으로 해줬을 때나 가정할 수 있는 얘기... ㅎ)
h
생각보다 엄청 그렇진 않습니다
적절한 수준의 추상화가 들어가거든요
예시로 올려둔게 많이 없긴한데
이건 전회사에서 만들었던 스키마고 https://www.npmjs.com/package/@devsisters/web-pre-registration-schema
현회사는 아직 뭐 공개한 스키마가 없네요
음 예시가 안되네
아무튼 추상화를 지원해서 괜찮습니다
UI 기반으로 스키마를 정의하면 UI의 변화에 따라 스키마도 계속 변해야하잖아요?
그리고 애초에 클라이언트가 하나면 GraphQL API가 BFF처럼 활용되는게 상당히 자연스러운 흐름이기도 합니다
나중에 갈아엎어도 늦지 않음
이 지점은 REST에 비해 나아지는 점이 있나?
디자인 방향성이 비슷해도 훨씬 낫습니다. 스키마와 구현에서 재활용되는 부분이 엄청 많거든요
퍼블릭 API 만드시는게 아니라면 저는 시작으로 UI 에 맞추는걸 더 권장합니다.
다만 다시 돌아가서... 저는 일단 좀 UI 에 맞추더라도 변경하기 어려운 스키마 먼저 작성해보는게 좋다고 봅니다. 똑같이 실패했을 때 결과가 추상화가 되있는게 더 고통스럽습니다. 추상화는 좀 스킬이 쌓인 다음에 해야 실패할 가능성이 낮죠
u
혜성님 인사이트 넘치는 의견 공유해주셔서 감사합니다. 자주 와서 힘을 길러야겠군요. 위급할 땐 또 도움 요청드릴께요 ㅎㅎ
h
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
🤣 3
Open in Slack
PreviousNext
Powered by