GraphQL is a query language for APIs and a runtime for performing queries on data that already exists.

GraphQL Korea

쿠팡이군요 ㅎㅎ 광운님은 여기엔 안계시네요 ㅠ 연락드려봐야겠어요

<https://github.com/dotansimha/graphql-yoga>

여기군요 ㅋㅋㅋㅋ

태헌님 반가워요! 잘 부탁드려요~~! ㅎㅎ

반가워요 유건님 ㅎㅎ GraphQL은 React와 환상의 짝꿍입니다 ㅋㅋ 앞으로 잘 부탁드려요!

민규님 반갑습니다 ㅎㅎ 잘 부탁드려요~

상훈님 반갑습니다! GraphQL에는 말씀주신거보다 더 많은 매력이 있어서 소개드리고픈데요. 혹시 어떤식으로 환경을 구성해서 쓰시나요?? ㅋㅋ

fragment 문법이나 code generation 도구 같은것들도 쓰시는지 궁금합니다 ㅋㅋ

Tony님 저도 너무 반갑습니다 ㅎㅎ!!

graphql 매력에 푹 빠진 게 최근 이어서
간단하게 graphql 스키마 서버에 띄우고
apollo 클라이언트 사용해서 데이터 불러와서 보여주는 정도까지 사용해 봤습니다!! :rolling_on_the_floor_laughing:

fragement 문법이랑 code generation에 대해서 는 잘 몰랐는데 이렇게 또 좋은 정보를 얻어 가네요 다음번에 꼭 활용해볼께요 감사합니다 :relaxed:

수동님 반갑습니다~ ㅎㅎ 앞으로 잘 부탁드려요!

오 지훈님 반갑습니다! 먼저 인사주셔서 감사하네요 ㅋㅋ 혹시 어떤 경로로 가입하셨나요??

반갑습니당ㅎㅎ 저 페이스북 보고 왔어요! 오랜만에 인사드려요 :)

juchoi님 반가워요 ㅎㅎ 많이 쑥쓰럽네요 ㅠㅠ 잘 부탁드립니다!

종은님 안녕하세요 ㅎㅎ 반갑습니다! 혹시 GraphQL Client는 어떤거 사용하시나요??

<@UN0GLRW14> 님, 아하.. 이거 글을 너무 늦게봤네요.ㅎ 저는 relay 사용합니다. 서버는 parse-server 쓰고 있어요. parse-server가 relay 의 graphql server 스펙을 따르기 때문에 별 문제없이 만족하고 있어요.

Nexus 는 컨셉 상 커스텀 디렉티브가 필요하지 않습니다.

필요하다면 플러그인을 만드시면 됩니다.
<https://nexusjs.org/docs/api/plugins>

커스텀 디렉티브와 동일한 기능, 동일한 역할입니다

_*Nexus 는 컨셉 상 커스텀 디렉티브가 필요하지 않습니다.*_

좀 더 설명해주실 수 있나요 ? 컨셉이랑 custom directive랑 어떤 연관성이 있는지 짐작이 안가네요..

왜냐하면 플러그인이 하는일이 커스텀 디렉티브로 하는 일과 정확히 일치하거든요

다른 기능이 연관성이 있는게 아니라 같은 기능입니다.

실제 커스텀 디렉티브 사용사례나 구현 예제를 찾아보시면 도움이 될거같습니다

custom directive랑 plugin이 동일한 기능을 한다는건 저도 동의합니다 !

근데 custom directive가 graphql spec문서에 포함된 내용인데 code-first에서는 제한이 있다는 말이 좀 와닿지가 않네요..

custom directive 는 구문이 아니라 구문 확장이고 실제세계에서는 사용되지 않아요.

실제 GraphQL 런타임을 구성하기 위해 다른데서도 보통 makeExecutableSchema 같은 유틸리티를 사용하는데요

SDL로부터 스키마를 생성하고, 스키마에 리졸버를 매핑하고, 지시자를 지우는 전처리 작업까지 완료해야 실행 가능한 런타임 (Executable Schema) 가 됩니다.

SDL 에서 쓰이는 디렉티브는 그냥 지시자이고 런타임에선 역할이 없습니다. Nexux 플러그인과 라이프사이클이 동일합니다

요컨데 쓰고 안쓰고 따질만한 부분이 없다는건데요

만약 질문하신게 "다른 사람이 makeExecutableSchema 호환되는 형태로 만들어둔 directive handler 를 라이브러리처럼 가져다 쓰고 싶다" 라는 의미라면 그건 Nexux 라고 못할 이유가 없습니다. 시그니쳐도 똑같아서 그냥 직접 실행하면 됩니다

SDL-first 에선 그냥 텍스트 정보밖에 없기 때문에 directive를 남겨 나중에 처리기에게 의도를 지시하는 건데, code-first 프레임워크는 처리기가 달라붙어 있으니 그냥 거기서 제공하는 도구를 쓰면 더 편하게 하는것이죠

마지막 내용이 인상적이네요… 답변 감사합니다. 원하는 답변이 된 것 같습니다 ㅎㅎ

UI 드리븐 스키마 설계 근거를 찾아야 해요

어떻게 도와드리면 될까요 ㅋㅋ

<#C01PACBHTNE|> 가 필요하신건가요

데이터 기반 모델링이냐, UI 드리븐 모델링이냐의 힘겨루기

맥락을 주시면 긍정의견 부정의견 다 던져드리겠습니다

저는 유즈케이스 드리븐이 맞다고 생각합니다. GraphQL 의 장점은 도메인을 바깥에서 바라보게 한다는데 있어요

아 맥락은 대략 이렇습니다. REST -&gt; GraphQL 넘어가는 건 오케이 너무 좋다. 그럼 그래프 구조의 데이터 모델링을 해야하는데, 데이터 기반이냐 UI 기반이냐 이런 맥락이에요

REST나 GraphQL 이나 본질은 stateful client 를 얼마나 쉽게 "생성"할 수 있냐라서

데이터 기반 모델링은 클라이언트에 별로 도움되진 않습니다

도메인 유즈케이스 기반으로 모델링을 해야....

`도메인 유즈케이스` 키워드 겟!

살짝 무슨 느낌인지 알거같네요

음 아까 맥락을 잘못 파악해서 다른 생각을 하고 있었는데

일단 아직은 모르겠습니다 ㅋㅋㅋ

그냥 Server-driven UI 같은거 고민하시는 줄

근데 왜 Reason Seoul graphql 채널에서 얘기 안하시고 일로 오셨나요

~어차피 양쪽다 답변달 사람이 똑같은데..ㅋㅋㅋ~

server driven UI 마침 제가 착각하고 키워드 던졌다가 역공 당했어요

사실 스키마 두 벌 있어도 됩니다

아 저도 둘 중 하나는 아니라고 생각하고 있어요

옛날에 Prisma 1 이 GraphQL SDL 쓰던 시절에 워크플로우가 그런식이였어요. DB 스키마 GraphQL 로 한 벌 짜고 API 스키마 한벌 더 짜고

데이터 기반 모델링 + (유즈 케이스 기반 모델링)

GraphQL 은 SDL이랑 Operation definition 이 분리되어 있잖아요

그래서 사실상 "엔드포인트를 만들지 말고 엔드포인트 생성기를 만들자" 에 가깝거든요

데이터 기반 모델링 스키마로는 UI에 필요한 데이터 페칭 할 때 쿼리가 어마무시하게 복잡해질 수도 있을 것 같은데, 당근은 어떻게 하고 계세요?

당근은 어떻게 하냐고 말하니까 좀 이상하군요;;

순수 RESTful 엔드포인트가 (HATEOAS 없이) 멀티 클라이언트 환경에서 망가졌던 사례들을 떠올려보면

실제 쿼리가 어떤식으로 사용되는지를 고려하는건 API 디자인에서 꽤 중요한 부분입니다

그래서 저는 이걸 아예 documents-first 라는 접근방식으로 고착화 시켰어요

Figma 를 유심히 들여다보면 GraphQL fragments 들이 보여요

그걸 병합하면 스키마가 어떤식으로 발전해야하는지 보입니다

&gt; GraphQL 은 SDL이랑 Operation definition 이 분리되어 있잖아요
이게 오히려 데이터 기반 모델링만 하면 되는 것 아니냐의 근거도 되잖아요

순수하게 데이터에 집중할 수록 유즈케이스 표현이랑 멀어지는 경우가 많은데요

뭔소리냐면 파생 상태를 표현하기 위해 클라이언트에 별도의 "상태관리 레이어" 가 필요해집니다

리액트에서 상태관리 어쩌고 얘기가 그렇게 큰 건 다 클라이언트와 기반이 되는 API 디자인이 구려서 그래요

다행히 GraphQL 은 꽤 유연하게 enhance가 가능해서

둘 다 동시에 시도하실 수 있는데요

여러가지 방법이 있습니다. 서버가 필요에 따라 root field 이던 derived field 이던 다 제공해놓고 뭐가 더 많이 쓰이는지 보거나

아니면 클라에서 직접 리졸버를 구현하거나... ㅋㅋㅋ

이걸 잘 설명하는 원칙으로 아폴로에서 소개한게

<https://principledgraphql.com/> 이 사이트에요

이 항목이랑 <https://principledgraphql.com/agility#4-abstract-demand-oriented-schema>

요거 <https://principledgraphql.com/integrity#2-federated-implementation>

아 연오님 안오셨으면 나만 알고 근거 댔을텐데

DDD 로도 비슷하게 설명할 수 있습니다

(스레드) <https://twitter.com/KrComet/status/1430597028296286209>

실제로 일반적인 GraphQL 서버 아키텍처는 DDD 프랙티스의 많은 부분을 구현하고 있습니다. GraphQL이 메타언어처럼 작동할 뿐

<https://gist.github.com/OlegIlyenko/a5a9ab1b000ba0b5b1ad>

GraphQL SDL 이 데이터 구조를 표현하는 언어로도 쓸만한건 사실인데, API 표현까지 실제 애플리케이션에 필요한 것과 거리를 벌려서 다시 임피던스 불일치 문제를 재현할 필요는 없는것이고요

GraphQL 은 언어 사양에도 스스로를 "Product-centric language" 라고 표현하고 있어요

이걸 좀 데이터(그래프)스럽게 일관적인 패턴으로 표현하는 프랙티스가 Relay specification 인데

아시다시피 관계 문제에 그래프 컨셉(Node, Edge)을 도입해서 스키마 디자인을 합니다.

마치 옆동네 JSON:API 랑 비슷한 물건인 셈이죠

Relay 스타일 스키마랑 클라이언트 스키마 확장 같은걸 활용하시면 두분 다 만족하시는 이상적인 디자인이 나올거라 생각하는데요

이게 진입장벽이 있는 편이에요

퍼블릭 API 만드시는게 아니라면 저는 시작으로 UI 에 맞추는걸 더 권장합니다.

그게 더 GraphQL 장점도 많이 접하면서 서로 API 스키마 논의하는 연습을 이어나가기 쉬워요.

&gt; 이게 진입장벽이 있는 편이에요
아니 사실 그래프를 활용하는게 튜플/정규화보다 쉬워야하는데, 실제 세계에선 반대인거 보니 사람들이 너무 고였어요

반대의견은 뭐 그렇습니다. 다른 API format 이라고 크게 다르진 않고, 실제 데이터 액세스랑 멀어지면 클라이언트(유즈케이스) 가 확장될 때 유연성이 떨어지죠.

뭐 애초에 정답이 있는 문제는 아니니... 케바케로 잘 찾아가시면 되겠습니다

UI 기반으로 스키마를 정의하면 UI의 변화에 따라 스키마도 계속 변해야하잖아요? 이 지점은 REST에 비해 나아지는 점이 있나? 싶은 생각도 들었어요. 선배인 당근마켓은 어떻게 하고 계세요?

(아, 물론 REST도 UI 기반으로 해줬을 때나 가정할 수 있는 얘기... ㅎ)

생각보다 엄청 그렇진 않습니다

적절한 수준의 추상화가 들어가거든요

예시로 올려둔게 많이 없긴한데

이건 전회사에서 만들었던 스키마고
<https://www.npmjs.com/package/@devsisters/web-pre-registration-schema>

현회사는 아직 뭐 공개한 스키마가 없네요

이런건 있음
<https://twitter.com/KrComet/status/1398344970482851842>

아무튼 추상화를 지원해서 괜찮습니다

&gt; UI 기반으로 스키마를 정의하면 UI의 변화에 따라 스키마도 계속 변해야하잖아요?
그리고 애초에 클라이언트가 하나면 GraphQL API가 BFF처럼 활용되는게 상당히 자연스러운 흐름이기도 합니다

~나중에 갈아엎어도 늦지 않음~

&gt; 이 지점은 REST에 비해 나아지는 점이 있나?
디자인 방향성이 비슷해도 훨씬 낫습니다. 스키마와 구현에서 재활용되는 부분이 엄청 많거든요

&gt; 퍼블릭 API 만드시는게 아니라면 저는 시작으로 UI 에 맞추는걸 더 권장합니다.
다만 다시 돌아가서... 저는 일단 좀 UI 에 맞추더라도 변경하기 어려운 스키마 먼저 작성해보는게 좋다고 봅니다. 똑같이 실패했을 때 결과가 추상화가 되있는게 더 고통스럽습니다. 추상화는 좀 스킬이 쌓인 다음에 해야 실패할 가능성이 낮죠

혜성님 인사이트 넘치는 의견 공유해주셔서 감사합니다. 자주 와서 힘을 길러야겠군요. 위급할 땐 또 도움 요청드릴께요 ㅎㅎ

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

뭐 어디 채널 따로 마련해드릴까요

저 분을 설득해야 합니다 보통 분이 아니에요

두 분이서 샘플 스키마 가지고 <#C01PACBHTNE|> 채널에 던져주시면 장단점 리뷰 같은건 가능합니다

hash 부분 말씀하시는거죠? versioning 이던가 graphql endpoint 가 여러개라 그중 어떤 endpoint 를 가르키는지 표시하는 hash 일 것 같네요 ㅎㅎ 아니면 로드밸런싱 용도이려나? twitter 급이면 부하도 많을테고 api gateway 부하도 고려해야해서 client level 에서 나눌수도..

아니면 위치기반으로 api endpoint 를 나눠놓은걸수도 있겠네요

원래는 <https://github.com/XiNiHa/vite-ssr-relay-template|이런 식으로> 만들어서 쓰는 정도로 만족을 하려고 했는데, Progressive Hydration 지원이나 defer/stream, 에셋 preload 등등까지 고려하려고 하니까 이거로는 안 될 것 같다는 생각이(…)

SSR 스트리밍이라니;;;; 저는 문제인식이 없어서 시도해보지 못했었는데,  뭔가 생성된 문서 자체가 엄청 큰가요?

아 아직 리액트 18 SSR 스트리밍 관련해서 내용 못 보셨나요?

문서 크기 때문이라기보다는 Suspense 바운더리 때문입니다

18을 쓰고있긴한데... ㅋㅋ Next.js에 의존중이라서 구체적으로는 못봤네요. 한번 읽어봐야겠습니다

NextJS는 아직 공식적으로는 React.lazy/Next Dynamic 용도로만 스트리밍을 지원하는 것 같기는 하더라고요… 개인적으로 Suspense 기반 스트리밍은 리액트의 정말 매우 엄청난 혁신이라고 생각합니다 :+1:

사실 리액트가 공식버전이 나왔다는건

이미 옛날에 릴레이에서 풀린 문제라는 얘기이긴 합니다

아직 Partial/Selective Rehydration 제대로 통합된 프레임워크가 없긴하죠

저도 클라에서만 서스펜스 활성화중이긴 한데

넥스트는 애초에 인터페이스 자체가 HTML Flushing 이랑 호환 불가능이지 않나

스트리밍 친화적인 인터페이스가 아니라서

뭐 아예 새로 만들지 않을까요 async generator 기반으로 된거

오 react 18 이야기가 있었군요 ㅎㅎ 저는 클라이언트에서 ui performance issue를 너무 많이 겪어봐서 transition 이 엄청 반갑더라구요 ㅎㅎ 다른애들은 해당 usecase를 다뤄본적이 많이 없어서 사실 잘 모르겠던데 얘는 진짜 너무 반가웠어요

안녕하세요! Ivan님 반갑습니다 ㅎㅎ 앞으로 잘 부탁드려요!

안녕하세요~! GraphQL 공부를 시작하면서 들어왔습니다 반갑습니다~!

ㅎㅎ 근데 초기단계라서 아직 부족함이 많은듯해요 ㅠ 테스트 단계에서 멈춰있습니당 ㅠ

또잉?! 저희 Slack Huddle 기능이 켜졌군요? ㅋㅋ 무료는 안되는줄 알았는데...

ㅋㅋㅋ 얼마 전에 갑자기 켜졌더라고요 ㅋㅋ

시간을 정해서 두런두런 이야기 나누는 시간 가져보면 좋겠네요~ 굿굿

간단하게 CF Workers로 하나 만들었는데 바로 붙여봐도 될까요?

모바일에서 권한주는 옵션에 접근이 안되네요 ㅠㅠ

없어도 잘 설치되는 것 같네요 ㅋㅋㅋㅋㅋ

셀프 인사도 하는군요 ㅋㅋㅋㅋㅋㅋㅋ

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 의하님 최고네요~ 살짝 감동…

기존 GreetBot 앱 제거 했어요~ ㅋㅋ

<https://github.com/vladar/graphql-normalized>

이거 재밋는 실험이네요

미리 정규화하기… 상상도 못했네요. 스키마가 있으니 이런 최적화가 가능하군요

nexus에서 custom scalar type을 사용할 때 마다 매번 type assertion을 해줬는데, 찾아보니깐 type을 입혀주는 방법이 있네요 !!

공식 문서에는 안보였는데..그냥 d.ts 파일 열어 보니깐 사용법이 있네요
```export type DateTime = Date

export default asNexusMethod(GraphQLDateTime, 'date', {
  module: __dirname,
  export: 'DateTime',
})```