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

GraphQL Korea

질문 생기시면 많이 많이 남겨주세요 ㅎㅎ

한폭의 그림같은 스키마를 얻었습니다

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 그래프 스럽네요

뎁스 너무 깊은거 아닌가요;; ㄷㄷ

Event - Event 메타 - Event별 사용자 정보

맥락 분할해서 알아서 한줄씩 정렬되는 중

Image 프로세싱은 gatsby-image 쓰랴고 그냥 거기있는 스키마 복붙했어요

스크롤 기능을 저렇게도 리팩토링 할 수 있구나 띠용~ 한 발표였습니당.
빨리 다들 GraphQL 뽕이 차오르시길....

크으~~ 사실 예제가 좀 불명확해서 ㅠㅠ 아쉬웠어용

서버쪽이 더 띠용한 리팩토링이 많습니다 ㅋㅋ

이제 혜성님 발표 기다려야겠당 흐흐

네 그런것도 있고 뮤테이션 쪽도 그렇고요

<https://graphql-korea.slack.com/archives/CN0G9HJAJ/p1604640031402400?thread_ts=1604638971.397000&amp;cid=CN0G9HJAJ>

어 이거 뮤테이션 그래프만 따로 어떻게 그리셨나요

띠용? 그 아래에 셀렉트 박스가 있어요 ㅋㅋ

이게 UI 인줄 몰랐어요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

인증메서드가 좀 많아서 이런식으로 분할하다보니 긴머리처럼 나왔네요

```type PreRegistrant implements Node {
  id: ID!
  eventTarget: EventTarget!
}

type Mutation {
  preRegister(input: PreRegisterMutationInput!): PreRegisterMutation!
}

enum AppPlatform {
  PLAY_STORE
  APP_STORE
  ONE_STORE
}

type PreRegisterMutation {
  sms_otpAuth(input: PreRegister_Sms_OtpAuthInput!): PreRegisterMutationOutput!
  sms_noAuth(input: PreRegister_Sms_NoAuthInput!): PreRegisterMutationOutput!
  email_noAuth(input: PreRegister_Email_NoAuthInput!): PreRegisterMutationOutput!
}

input PreRegisterMutationInput {
  platform: AppPlatform
  userAgent: String
  inviterCode: String
  eventTargetId: ID!
}

type PreRegisterMutationOutput_PreRegistrant {
  preRegistrant: PreRegistrant!
}

type PreRegisterMutationOutput_AuthSession {
  authSession: AuthSession!
}

union PreRegisterMutationOutput =
  | PreRegisterMutationOutput_PreRegistrant
  | PreRegisterMutationOutput_AuthSession

input PreRegister_Sms_OtpAuthInput {
  phoneNumber: String!
}

input PreRegister_Sms_NoAuthInput {
  phoneNumber: String!
}

input PreRegister_Email_NoAuthInput {
  email: String!
}```

저번에 State of JS 그래프 보고 감명받은게 좀 도움이 된 것 같아요

혹시 무슨 툴로 그리신건지 여쭤봐도 될까요?? :slightly_smiling_face:

<@UQ2FQ6US3> <https://github.com/APIs-guru/graphql-voyager>

GraphQL Voyager라는 서비스에요 ㅎㅎ GraphiQL이나 Playground처럼 서버에 붙일수있습니다!

친절한설명 항상 감사드립니다!!

유지보수 좀 오래 안되긴 했네요

Production Ready GraphQL에는 directive 사용한 방법이 나오는데, 이걸 기본적으로 사용할거같구요

다만, 예를 들면 updateArticle이라는 Mutation이 있다면, 해당 Article 수정 권한을 context.me가 가지고 있는지 체크해서… 처리하고 싶은데, 이런 상황에 어찌해야될지 고민중입니다.

shield가 잘하면 타이핑이 어렵지 않게 할 여지가 있긴 한데 (generated type 을 파라미터로 넘겨서) 좀 서커스가 필요하겠네요

퍼포먼스 이슈는 어떤걸까요 :eyes:

일단 role based 리소스 접근 제어 하는 경우에는 필드를 다 쉽게 조회할 수 있도록 풀어두는게 간단한 것 같고

가령 User.roles: [String!]! 이라던가

디렉티브 기반이라고 하셨으니 info 를 보면 판단 가능하겠네요

사실 mutation 마다 제어가 필요한지 모르겠고, mutation 은 mutate하고 싶은 녀석을 body에 들고있을 테니 거기 디렉티브가 있으면 쉽게 판단 가능하지 않을까욤

```mutation {
  updateArticle(input: { ... }) {
    ...Article @role(has: "updateArticle")
  }
}```

<https://github.com/maticzav/graphql-shield/issues/812>

이런 이슈가 있어요. graphql-middleware 쪽 문제인거같은데 메인테이너가 약간 무책임함…

&gt; I don’t think there’s an easy solution to this problem and I don’t have the time capacity at the moment to rewrite `graphql-shield`. Thank you for posting benchmarks. For now, I cannot promise much.

성능을 위해서 타입을 하나 더 만들어야될까요 ㅠ

<https://github.com/zalando-incubator/graphql-jit/issues/81>

결국 스키마를 포기하고… 성능을 택했습니다 ㅋㅋㅋㅋ

```input ArticlesWhereInput {
  _id: String
  type: String

  OR: [ArticlesWhereInput!]
}```
요런식으로 쓰고있어용 ㅋㅋ

```{
  articles(where: {
    _id: "...",
    OR: [
      { _id: "..." },
      { type: "business" }
    ]
  }) {
    _id
  }
}```

될거라고 생각도 못했지만 확실히 jit 돌리기 애매해지긴 하겠군요 ㅋ-ㅋ

찍는다는게 무슨뜻인가요?! ㅋㅋㅋ

```type Query {
  articles: [Article!]! @filter(by: ["_id", "type"])
}```

```input ArticleFilterInput {
  ...
  OR: [ArticleFilterInputOrInput!]
}

input ArticleFilterInputOrInput {
  ...
}```
이렇게 찍으면 되는거 아닌가용

네 ㅋㅋ 그렇게 하면 되죠 ㅋㅋ 근데 제가 스키마는 필드 하나하나 다 Description 달아놔야 직성이 풀리는데…

Description을 두번씩 달아야해서 굉장히 찝찝하네요 ㅋㅋ

설마 저 directive가 Input 타입을 자동으로 만들어주나요?

아님 주석을 찾아서 복사하거나

그 맛에 메타프로그래밍 하는 거 아니였습니까 ㅋㅋ

ㅋㅋㅋㅋㅋ 이제 저도 custom directive의 세계로 발을 들이게되는건가요

```import { makeExecutableSchema } from '@graphql-tools/schema';

import typeDefs from '@devsisters/web-swt-graphql/schema';

const OUTPUT_PATH = resolve(process.cwd(), 'shared/graphql/schema/executable-schema.graphql');

const schema = makeExecutableSchema({
  typeDefs,
  schemaDirectives: {
    constraint: ConstraintDirective,
    formatDate: FormatDateDirective,
    formatDuration: FormatDurationDirective,
    pagination: PaginationDirective,
    // ...
  },
});

writeFileSync(OUTPUT_PATH, printSchema(schema), {
  encoding: 'utf-8',
  flag: 'w',
});```

스키마가 로컬에 있을 때는 코드젠에 훅걸어서 쓰고

전 근데 전에 얘기한거처럼 시작을 코드로 했다가 스키마 뽑아내서 전환하는거 좋다고 생각해요 ㅋㅋㅋ

전환이 어렵진 않았어요 ㅋㅋ 스키마 한 천줄짜리 코드였는데 5시간 정도 걸린거같네요

아 ㅋㅋㅋ 아래 제가 공유한 일자리 서비스가 양천구에만 오픈되어있어서요 ㅎㅎ

PQ 하면 한번더 확 줄고 JIT 달면 또 확 줄겠네요? ㅋㅋㅋ

마찬가지로 recursive input type 때매…

근데 이 서버가 어차피 레거시라서 ㅋㅋ 여기서 멈출려구요

PQ하면 퍼포먼스 개선 효과가 좀 있나요?

CPU 는 따로 관찰 안해봤는데 아폴로 서버 기준으로는 별로 없었어요 ㅋㅋ

fragments 를 많이 쓸 수록 query playload 는 무지막지하게 커지고 상식적으로 구현했을 때 파싱타임이 없어져야하니까

개선이 있을거라 생각했는데 왠지 차이가 없음... ㅋㅋㅋ

와 Latency 튀는게 어떤 의미인가요? 잘 몰라서 ㅠㅠ

트래픽 느니까 이따금씩 응답이 2s ~ 10s로 튀는 경향이 좀 심했어요 ㅠ

스트레스테스트해보고 프로파일링 결과를 공유해드리면 좋겠지만 ㅠ 로컬에서 재현이 안되서

일단은 프레임워크를 바꿨더니 개선되기는 했어요 ㅎㅎ

아하 간헐적으로 느려졌던 현상이 개선된 거군용

아 공유로 물어볼거면 질문 채널에 공유할걸 그랬네요

fs로 읽고 맞춰서 뽑으시는거같아요 ㅋㅋ

<https://youtu.be/tVNOKT7xqPo?t=4831>

발표자료 얍

directive 핸들링은 graphlq-tools 쓰시면 되고

지금 소리 끄고 간단간단히 보고 있는데 이 밋업만 정리해도 아티클 하나는 나오겠네요 ㄷㄷ..

따로 셋팅 안해줬는데 react-relay-network-modern에서 자동으로 PQ요청 날리더라구요;; 서버가 준비 안되서 ㅋㅋㅋ 에러 났네요

레이어 정리가 잘 되었다는 게 어떤 맥락인지 설명을 조금 들어볼 수 있을까요?

스토어랑 상태머신이랑 코드 격리가 잘돼고 주입하기가 쉬우어용

data fetch layer (gql 클라이언트), UI 상태 관리 레이어 이 정도인가요?

저희 도입 준비중인데요 ㅋㅋ recursive input type이랑 @skip, @include 빼고있어요

At this moment, the only missing feature is support for the @skip and @include directives.

<https://github.com/zalando-incubator/graphql-jit#support-for-graphql-spec|https://github.com/zalando-incubator/graphql-jit#support-for-graphql-spec>

프로덕션 레벨에서 별 문제 없을까요 ㅋㅋㅋ

야아악간 끌리는데… 진짜 볼만한게 있으려나요 ㅋㅋ

근데 이거 테스트해야할 케이스가 너무 많네요 ㅋㅋㅋㅋㅋㅋ

여기서 mutaion에서 refetchQueries를 사용한 것과 차이가 있나요?

mutation body 는 rpc payload 라기 보단 커맨드 호출 후 사이드 이펙트에 대한 선언입니다. 이거에 대해서 쿼리를 구독하는 대상들에게 변경을 전파하는건 GraphQL 클라이언트의 역할이에요

페이지네이션이 좀 특이한 케이스라 릴레이 페이지네이션 컨테이너 처럼 따로 유틸이 제공되긴 하죠

그 외에는 사실 updater 를 작성하거나 cache-first 에서 벗어날 일이 거의 발생하지 않아요

appendEdge, deleteEdge 맛은 어떤가요

`@appendEdge`는 아직 안쓰고있어요 ㅋㅋ

아뇨 UI상태는 본질적으로 트리가 아니라 그래프라는게 중론이라 일반적인 것 같습니다. 다만 리액트로 다루는 부분이 아니니 "외부 스토어" 가 필요하겠죠

아하 일반적이군요~ 아마 구현을 한다면 추상화할 단위마다 지역적(?)인 context 를 만들어서 사용하려고 했는데 그 부분을 외부 스토어로 이해해도 맞을지요

서브트리가 알아야하는 지역적인 컨텍스트를 위해 React Context API를 사용하는건 좋지만 그 자체로 추상화를 제공하는 독립적인 레이어를 만드는건 Context API의 역할이 아닙니다. Context API는 이름 그대로 그냥 서브트리 중 원하는 컴포넌트에 맥락을 주입할 뿐이지요

Context Provider 주변에 생길 코드를 더 중점적으로 생각해보시는게 좋을 것 같습니다

오오 네 감사드립니다 말씀해주신 것 좀 더 깊이 생각해보겠습니다

제가 영감을 받은건 약간 <https://github.com/adobe/react-spectrum/blob/main/packages/%40react-spectrum/radio/src/context.ts> 이런 느낌이었는데 여기서는 context 가 state 에 비해서 어떤 이점을 갖고 쓰인건지 아직 잘 이해가 안되네요..

어음… 컨텍스트랑 state 는 서로를 대체하는 관계가 아니에요

저런식으로 Context 만드는건 굉장히 흔합니다. 그리고 저렇게 만든 Context는 State 를 주입하기 위함이지 State를 쓰지 않기 위함이 아니에요

아 지금까지 비슷하다고 생각해왔는데 다시 생각해봐야겠네요,,

안녕하세요! graphql 자료를 찾아보다가 지혁님이 강연하신 영상을 보게 되었고 이렇게 슬랙 워크스페이스까지 오게 됐어요! ㅎㅎ 감사합니다!:raised_hands:

허거걱 영광이네요 ㅋㅋㅋ 환영해요~~

오 저는 백엔드는 거의 건드리질 않아서,, 좋은 아이디어라 생각했었는데 협업에선 또 이슈가 있나보군요 ㅎㅎ

넵 예를 들면 갑자기 핫픽스를 나가야되는데… 코드 하나만 고치면 되는게 아니라, 로컬에서 `yarn dev`를 해야된다던지 이런게 엄청 어색하더라구요!

그냥 Schema first 면 CI에서 codegen 돌려버리면 어떻게든 될테니까요 ㅋㅋ

Nexus.js 생태계에 모든 팀원이 익숙해져야하는데, 이게 어색…

사실 어느쪽이던 핫픽스에서 스키마가 깨진는일은 없어야한다고 생각합니다 ㅋㅋ

사실 얼마전에 저희 백엔드 쪽에서 nexus 버전 범핑으로 스키마가 변경된 일이 있었는데 프론트엔드 입장에서는 쿼리의 리턴타입이 변경된 경우까지는 type generation 에서 에러가 안나지만 generated type은 모조리 바뀌었기 때문에 typed query 를 쓸 때는 에러가 났었거든요,, 근데 스키마에서 리턴타입의 변경은 일반적 breaking change로 취급하지 않는거 같더라고요 아래와 같은 경우였어요

<https://github.com/kamilkisiela/graphql-inspector/discussions/1808>

음 nullable -&gt; non-null 은 브레이킹이 아니긴 할텐데

저건 브레이킹이 맞는거같은데요

앗 그런가요,, 하긴 그때는 인스펙터가 적용이 안되어있어서 감지 못했던거같네요

그래서 하여튼 백엔드측에 migration guide 다 따라달라고 부탁드렸던 기억이

공개 API를 다룬다면 스키마가 조금 더 strict 하게 브레이킹을 감지하는게 좋은 것 같은데

클라이언트랑 서버 전부 코드젠 돌려서 타임검사해보면 브레이킹인지 아닌지 나오겠죠 ㅋㅋ

근데 이게 확인하는데 스텝이 많아서 타임검사가 피드백 루프를 길게 늘어트리니까

네 결국 프론트엔드에서 브레이킹이 확인되었었어요 ㅋㅋ

정적분석으로 대체하려는 것 같아요. 다만 워크플로우가 통합되어있다는 전제하에요

워크플로우가 강제되지 않으면 문제가 말씀해주신것처럼

이미 스키마는 배포되었는데 클라이언트에서 브레이킹이 뒤늦게 감지된다거나 그래서

그리고 사실 PQ 같은거 쓰려면 어차피 통합해야되기도 합니다

Persisted Query 라고, 앱에서 쓰는 쿼리를 AOT 방식으로 미리 파싱해두고 API 쪽에 저장해두고 쓰는 방식이에요

Get 요청으로 쿼리의 해시값만 요청에 보내면

서버는 해시테이블에서 미리 저장된 AST를 보고 응답을 내려줍니다

요청 페이로드 사이즈나 파싱과정을 생략하게되서 필수적으로 권장되는 베스트 프랙티스 중 하나에요

관련발표가 2015년부터 있었습니다.. 페이스북에서는 GraphQL 이렇게 쓴다.. .식으로

&gt; 미리 저장된 AST를 보고
음 이거는 relay에서 지원 안하지 않나요? relay compile --persist-output 하면 그냥

```{
  [queryHash: string]: string // GraphQL Full Query
}```
으로 나오더라구요

와우 하나 배워갑니다 키워드는 종종들었는데 뭔지는 이제 알았네용

&gt; 음 이거는 relay에서 지원 안하지 않나요? relay compile --persist-output 하면 그냥
페북에선 DB에 넣는다고 들었던거 같은데.. 어차피 그냥 JSON 형태라 어디넣을지는 자유롭지 않나요

보통은 APQ 같은건 그냥 LRU에 넣긴하지만

물론 graphql-jit으로 한번 말아서… 저희 내부적으로는 그게 그거긴해요 ㅎㅎ

저희는 MongoDB에 저장해요. 근데, output으로 AST가 나오진 않더라구요. 그냥 풀 쿼리가 나와요

어쨋든 이런식으로 프리컴파일을 안해주면 GraphQL 런타임이 굉장히 cpu intensive 하게 돌아서 너무 느린거 아니냐는 오해를 받을수있어요

그냥 introspection 하면 될것 같은데

&gt; 어쨋든 이런식으로 프리컴파일을 안해주면 GraphQL 런타임이 굉장히 cpu intensive 하게 돌아서 너무 느린거 아니냐는 오해를 받을수있어요
실화입니다. Node.js 경우에는 갑자기 요청 몰리면 (외부의 워커등에 의해서) 레이턴시 2s-3s씩 툭툭 튀어요

import { buildClientSchema, getIntrospectionQuery } from ‘graphql’

get introspection 따로 할 필요 없겠네요 그냥 스키마 객체 만들어서 JSON으로 시리얼라이즈 하면 될듯

`import { introspectionFromSchema } from 'graphql'` 이거네요

<https://github.com/cometkim/gatsby-plugin-typegen/blob/59189de/plugin/src/workers/emit-schema.ts#L41-L45>

아 스키마가 아니라 document node 군요

그냥 parse 하면 될듯
<https://graphql.org/graphql-js/language/#parse>

그래서 결국 요청 형태가 `GET /graphql?query=${hash}` 식으로 바뀌게 되면 엔드포인트에 따라 응답을 CDN에 올리거나 해도 됩니다 ㅋㅋ

오 생각해보니

`GET /graphql/${hash}` 형태로 바꾸면 쿼리 별로 Datadog에서 퍼포먼스 모니터링 하기도 더 쉽겠네요.

ㅋㅋㅋㅋㅋㅋ 크으 1월에 추진해볼게요 ㅋㅋ

늦게 봤네요! ㅎㅎ 환영해요 재영님~~

여담: 키노트라는 좋은 도구가 있지만.. 슬라이드 쉭쉭 넘기는 용도면 이쪽이 차라리 더 간결하고 집중도 잘될듯 해서 찾아보고 있습니다

키노트로 작성하는 시간의 50%는 애니메이션 효과 만지는데 다쓰는듯

대부분의 발표자료 mdx-deck 으로 쓰는데요. 테마깎는데 시간도 많이 걸리고 static asset 효율적으로 처리하도록 커스터마이징 하기가 어려운 것 같아서 그냥 담부터는 Gatsby 로 만들고. 썼던 리액트 컴포넌트는 어디 좀 모아두려고요

테마 한번만들어놓은거 계속 쓰면 말씀하신대로 컨텐츠만 집중해서 볼수도 있을거같은데

막상만들때는 또 욕심 생기죠 ㅋㅋ

그래서 뭐 소스가 절반 마크다운 절반 jsx 입니다

gatsby.. gatsby .. 아이디어 괜찮은데요!? ~일단 이번엔 대충 떼우고,,~

이미 theme 찾아보면 다른사람들 쓰는거 많을걸요

gatsby 커뮤니티 사람들이 mdx에 환장을 해서요

오호 그렇담 이쪽으로 한번 살펴보겠습니다
<https://github.com/jxnblk/mdx-deck/tree/master/packages/gatsby-theme>

서버 컴포넌트.. 클라이언트에서 서버 리소스를 상태 관리하는게 재미없는 일이니까 아예 서버에서 컴포넌트를 사용한 결과를 내려주는 방식인가요.. 제가 이해한게 맞나용

<https://github.com/reactjs/rfcs/blob/2b3ab544f46f74b9035d7768c143dc2efbacedb6/text/0000-server-components.md> RFC 한 번 찬찬히 뜯어보셔요