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

GraphQL Korea

<https://stitches.dev/docs/introduction>

여기에 .gif들 보고 빠져들었습니다... 타입추론 미쳤네요

저도 블로그 stitches 로 작업해보고 있는데 꽤 괜찮은 것 같습니다 :thumbsup: 혜성님 gatsby-theme-stitches 잘 쓰고 있어요 :relaxed:

Utility, variant, theme 을 일급시민으로 지원하는게

ㅋㅋㅋ 혜성님이 추천해주시면 바로 회사 슬랙에 퍼다나르는중 ㅋㅋ

그리고 Stitches 를 기반으로 나온 디자인 프리미티브

<https://radix-ui.com/primitives/docs/overview/introduction>

Java 쪽은 전혀 몰라서... 어떤 라이브러리가 좋을지 감이 잘 없네요 ㅎㅎ

플스택은 이거네요 <https://expediagroup.github.io/graphql-kotlin/docs/getting-started.html|https://expediagroup.github.io/graphql-kotlin/docs/getting-started.html>

근데 혹시 스칼라는 생각없으신지 ㅋㅋㅋㅋ

graphql-java + codegen-gradle 생각중이에요 ㅋㅋ

스칼라 가나요?! ㅋㅋㅋ 아쉽게도 언어는 Kotlin으로 통일해야될거같아요 ㅠ

봤는데, code-first 느낌이더라구요. SDL-first로 작업하고싶어서요 ㅋㅋ

Spring Boot 쓰시는걸로 알고있어요

음 webflux는 쓰시려나 모르겠네요 ~물어봐야겠다~ 안쓰신다고 하네요.

제가 백엔드 개발하는건 아니라서 ㅎㅎ

오?! 디자인도 하시나요!?!?:+1::skin-tone-2::+1::skin-tone-2::+1::skin-tone-2:

다행이네요! ㅎㅎ 감사합니당 ㅋㅋ

오 Reactive variables는 어떤 기능인가요?!

저는 토이프로젝트로 잠깐 써봤는데 2.6버전대에 local state management 기능보다는 나은 것 같아요 ㅎㅎ
타입스크립트를 사용하신다면 타입 지정도 더 간편하고 네트워크 응답을 캐시하는 공간이랑 분리되어서 사용성이 좋은 것 같습니다
근데 한번은 useReactiveVar() 인터페이스로 변경하지 않고 실수로 직접 값을 assign 했더니 원본 object 가 변경이 되어버리더라구요..버그인지 뭔지 모르겠지만 그 점이 약간 찝찝했던 ㅎㅎ 실무에선 아직 2.6대를 사용하고 있어서 제 의견은 가볍게 참고만 하시면 좋겠어요

질문에 살짝 빗나간 답변이지만...

전 개인적으로 서버응답을 관리하는 스토어와 UI나 지역적인 데이터를 관리하는 스토어를 구분하는걸 선호합니당.
그래서 Apollo를 쓰는 프로젝트에서 서버응답은 Apollo에 전임하고 이 외에 전역으로 혹시 지역적으로 관리돼야하는 상태들은 Redux나 Recoil로 관리했습니당.

<@UN0GLRW14> Apollo에서 제공하는 지역 상태관리 방법인거 같아요 ㅎㅎ 저도 학습중이에요!

흠 왠지 디스코드를 썼으면 이런게 더 유리했을거같긴 하네요

그냥 음성채널을 하나 열면 되니...

그치만 일하면서 흘깃흘깃하기에는 슬랙이 짱입니다 ㅋㅋ

(저는 눈치 안보고 그냥 키는데....)

눈치는 아니고 ㅋㅋㅋ 뭔가 일하기 싫을때 손이 가요.

그럴땐 음성채널 들어가서 "아 일하기 싫다~"

데이터 구조 어떻게 잡냐 나름인거같은데

많이 쓰는건 두 방식 중 하나인데요

사이드바 소스를 별도 파일로 분할하거나

컨텐츠 자체 규격에 포함시키거나 (fs 구조나 frontmatter 등으로)

저는 전자 + 컨텐츠자체는 플랫하게 관리하는걸 선호하는편

결국엔 따로 파일로 관리하는게 제일 낫겠네요 ㅠ sidebar.json으로 만들어야겠어요

<https://github.com/cometkim/gatsby-plugin-pagemeta|https://github.com/cometkim/gatsby-plugin-pagemeta>

<https://www.gatsbyjs.com/plugins/gatsby-transformer-yaml-plus/>

요런게 있네요!

어떤게 암묵적으로? 느껴지셨어용??

필드 포맷은 충분히 명시적일 수 있고 다이나믹하게 결정되는 경우가 없는데 왜 저렇게 써야하는지 잘 모르겠어요

• 혜성님이 말씀하시는 필드포맷? 이 어떤건지 궁금하고,
• 그럼 YAML 통해서 하려면 어떤 방식이 좋다고 생각하세요?

약간

```/sidebars
  /js-sdk.yml
  /openapi.yml```
```- name: 시작하기
  path: /js-sdk/getting-started
...

- groupName: 결제 플러그인
  children:
    - name:
      path: ...```
요런식으로 관리하려고했어요 ㅎㅎ

네비게이션이 계속 바뀌는건 사용자 인지에 악영향을 끼칠거같은데

또잉? 계속 바뀌지는 않을거같아요.

일단 GraphQL SDL 부터 선언하시는게 좋아요

Yaml 은 그냥 소스 컨텐츠입니다.

마크다운 필드 같은건 여기 예시처럼 스키마 필드 익스텐션으로 만들어도 좋겠네요

<https://www.gatsbyjs.com/docs/reference/graphql-data-layer/schema-customization/#creating-custom-extensions>

음 제가 갯츠비 지금 3일차라...

요 문서 쑥 보시면 뭔가 익숙한 느낌을 받으실겁니다

헐 createSchemaCustomization 이 되는군요

아 발표 내용 여기서 스포일러 하는건가

Gatsby 진짜 짱짱이네요. 더 해보겠습니당...

갯츠비 쿼리 컴파일러는 (당연하게도) GraphQL 스키마를 기반으로 정합성을 검사하는데요

암묵적으로 사용된 node data 에 대해 스키마를 직접 추론하는 동작이 있어요

그래서 아무 json이나 yaml 소싱하면 사용한대로 string? 필드가 생기는게 그 덕분인데

아 근데 그게 별로라고 하신거군요

저는 개꿀? 이러고 쓸려고했는데 ㅋㅋㅋㅋ

네 저는 content awareness 라고 칭하는데

스키마 선언하면서 갖추는게 좋다고 생각하고

개발할때도 타입 안전성 갖추기가 훨씬 쉽습니다

컨텐츠 모델링에 대해서 소개한 Sanity의 가이드: <https://www.sanity.io/guides/content-modeling-guide-introduction>

제가 gatsby-plugin-typegen 개발하면서 왜 Maybe 필드가 나오냐는 관련질문을 자주 받아서...

그리고 GraphQL SDL 을 먼저 선언하시면 자연스럽게 GraphQL Korea 채널에 스키마 리뷰를 올릴 수 있다는 장점이...

문서 네비게이션은 아니고 GNB지만 예제: <https://github.com/devsisters/web-packages/blob/fc65a8f/packages/gatsby-source-site-navigation/src/gatsby-node.ts#L64-L99>

만약 i18n도 하시면요( 하실거같지만) 스키마 레벨에서 "아 이게 생각보다 복잡하구나"를 미리 아실 수 있다는것도 장점이라면 장점이군요

ㅋㅋㅋㅋ i18n은 지금은 안할거같아요 ㅋㅋ 오오오 예제 좋네요! 감사해요!

이제 저희도 Gatsby 쓸일이 점점 생기는거같아요 ㅋㅋ

채용 페이지 노션 쓰지 마세요.... ㅠㅠㅠㅠㅠㅠ

ㅋㅋㅋㅋ 채용 페이지 곧 만들거같아요

Greenhouse 얼마전에 도입해서... 이제 Gatsby + Greenhouse 해야돼요.

전회사에서 계속 생각하던건데 개발자 JD  관리하기 제일 좋은 플랫폼은 역시 깃헙입니다

근데 그것도 지혁님이 하세요...?

ㅋㅋㅋㅋ 아뇨 그건 다른 분이 하실듯해요 ㅎㅎ

제가 여기저기 발을 다 걸치고 있어서... ㅋㅋㅋ

음 저는 꽤 만족중이에요 ㅋㅋ 일단 새 이메일이라 이메일이 그냥 덜 와서 UX가 만족스러운걸수도 있어요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

아 근데 이건 좀 논외로... <http://hey.com|hey.com> 도메인을 ~validation에서 튕겨내는 서비스들이 좀 있어요.~

이메일 확인을 hey.com이 스팸으로 파악해서 "이메일 확인" 버튼을 안눌리게 만들달지...

쿠팡이 그러길래 문의 넣었더니 담당자분이 잘 못 알아들어서 ㅠㅠ 뭐 어찌저찌 웹으로 열어서 이메일 확인했어요 ㅋㅋ

아 다른 사이트가 <http://hey.com|hey.com> 을 블락한다는게 아니라

<http://hey.com|hey.com> UI가 그런가요

컨트롤 다 뺏고 "선언적 inbox 관리" 라고 포장하기 (아무말)

Gmail 이 jQuery라면 hey는 React입니다 (아무말 2)

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

다른 논외로 저도 <http://hey.com|hey.com> 보니까 메일 어드레스 뽐뿌가 와서

<mailto:hey@hyeseong.kim|hey@hyeseong.kim> 으로 메일 주소를 바꿈

ㅋㅋㅋㅋㅋ comet.kim은 선점되었나보군요

네 그건 저에게 선점되었습니다(?)

하하 도메인 쇼핑을 자주하는 편이라

ㅋㅋㅋㅋ <mailto:hey@comet.kim|hey@comet.kim> 이 더 이쁘고 쉽지 않나요?! ㅋㅋ

cometkim 너무 말장난같은 핸들이라서 풀네임을 주로 쓰거든요 ㅋㅋ

그럼 잡담채널이 또 조용해질까봐 조심스럽네요 ㅋㅋㅋㅋ

저도 리액트 채널 만드는거 찬성입니다…

리액트 아니더라도 웹 개발의 영역은 상당히 넓으니 괜찮지 않을까요 ㅎㅎ

그럼 `frontend` 채널을 파고 전체 유저가 들어올수있도록 설정하면 어떨까요? ㅎㅎ 숨겨진 채널이 있으면 새로 들어오신분들이 접근하시기 힘들거같아서요 ㅠ

저는 GraphQL Korea 슬랙은 북적북적 시끌시끌한 느낌이 유지됐으면 좋겠어요 ㅎㅎ

프론트엔드 채널이 있으면 좋겠네요! 하긴 여기는 GraphQL 슬랙이니 그게 맞는 것 같네용

<#C01J2H4J1QV|> 채널을 새로 팠어요! ㅎㅎ

채널 이름이 한글이라서 조금 불-편하긴한데 ㅠㅠ 다른 한국 유저분들이 쉽게 접근하기 위해서 기본 채널은 한글 이름으로 하려고해요 ㅠ 양해 부탁드려요 ㅋㅋ

안녕하세요 우찬님~ 반갑습니다 ㅎㅎ

ㅋㅋㅋ 발표하길 잘했네요 ㅋㅋ 모르고 지나갈뻔 했어요 ㅎㅎ

음 사실 apollo 처럼 하려면 "컴파일 타임에 쿼리를 최적화" 한다는 relay 이점을 잃어버릴 수도 있어서, 런타임이 아니라 컴파일러를 확장해야 할 것 같아요.

음 아무래도 민감한 정보이기 때문에 GraphQL Korea보다는 따로 Private 채널에서 공유하심이 좋다고 생각돼요.

저는 웹 페이지 선호하지만 노션은 비선호해요. 접근성 떨어지고 느려요

<@UN4AJARCN>  아하 그렇군요 :D
요즘 꽤 많은 사람들이 노션으로 포트폴리오를 작성하시길래 저도 노션으로 적어볼까 생각중이거든요.. 혹시 접근성이 떨어지고 느리다는걸 어떤 부분에서 체감하셨나요 ??

음... 노션 접속할때 확 체감되지 않나요 ㅋㅋ;

들어가서 컨텐츠 볼 때 까지의 딜레이, 컨텐츠 내에서도 디테일 expand 할 때 동적으로 컨텐츠 로딩하면서 생기는 딜레이, 네비게이션 할 때 딜레이... 온갖 딜레이들이 조금 짜증나요

모바일에서 접속하면 더 심하고, 일단 앱이 깔려있으면 딥링크되어버리기 때문에 더 짜증나고

링크도 대부분 자동생성된 block id 기반으로 그대로 사용하시기 때문에 permalink 관리 안되서 날아가는 경우가 빈번했고요

노션까기를 시작하면 온종일 깔수있지만... 용도만 맞다면 괜찮다고는 생각합니다. 다만 말씀하신대로 너무 널리쓰이는거같아서 그 부분이 맘에 안드네요 ㅋㅋ;

말씀듣고 켜보니까 하나씩 보이기 시작하네요...ㅋㅋㅋㅋ 의견 감사합니다 :D

접근성 좋은 웹사이트라면 보통 pdf 로 이쁘게 출력하는데 문제가 없어요. css가 애초에 프린터도 지원을 하기 때문에 마크업 하나로 대응할 수 있습니다.

어떤 포맷을 쓰냐보다는 내용이 훨씬 더 중요한거같긴해요 ㅎㅎ 근데 질문에 대한 답은 저는 PDF ㅎㅎ

이제는 시도조차 안하니까 pptx, hwp 는 논의로 하고 ㅋㅋㅋ.. 노션 이력서를 보기 힘든게 속도도 속돈데 음. 저는 그냥 pdf 로 된 문서면 충분한데 노션 이력서는 본질보다 다른 것에 더 힘을 주는 느낌을 받는 케이스가 많은 것 같아요

노션 페이지는 에디터를 기쁘게 하는 도구지 최종사용자를 기쁘게 하는 도구는 아니라는 의견입니다 ㅋㅋ;

속도나 접근성문제는 좀 개선(완화 수준에서)해주는 서비스들이 있긴 합니다. <http://oopy.io/> 라던가 <https://super.so/> 라던가

둘 다 Next Static Regeneration 쓸거고, Oopy 같은 경우는 한국 개발자 분이 만들어서 서비스하고 계세요

<@UN4AJARCN> <@UN0GLRW14> <@U012FUYCZ8X> 의견 감사드립니다 ~ :smile:

저자가 DX 장인정신을 발휘하는 중이에요

Relay 본가가 Reason Relay 개발환경의 반만이라도 어떻게...

이번에 새로 표준에 들어가나요?

워킹그룹에서 굉장히 활발히 논의중이에요

Input은 거의 확실한데 Output 은 어떨지 모르겠네요

<https://github.com/graphql/graphql-spec/pull/733|https://github.com/graphql/graphql-spec/pull/733>

어음 마지막 논의는 공개된게 없어서 못봤는데

<https://gist.github.com/benjie/5e7324c64f42dd818b9c3ac2a91b6b12>

tagged union 이 추가된다는 사실은 어느 맥락에서든 분명해보이네요 구문은 아직 오락가락 하는듯

페이스북에서 보고 들어왔습니다!~

안녕하세요 샛별님 ㅎㅎ 페이스북 그룹은 어떻게 알게되셨을까요??

개발 페이지를 많이 좋아요 해서 그런지 추천으로 떠서 가입하게 됐습니다 :slightly_smiling_face:

안녕하세요! 회사동료 소개로 들어왔습니다

오오... 뭔가 추천으로 들어오셨다니 뿌듯하네요 ㅋㅋ 좋은 정보 얻어가셨으면 좋겠어요~

안녕하세요! 지혁님 발표 영상 보고 들어왔습니다:smile:

저는 김승욱님 1월 밋업 영상보고 들어왔습니다

partial rendering 은 어떤 개념인가요?? 아폴로 쓰면서도 모르고 있었네요,,

별건 아니고 요청 상태랑 관계없이 캐시 상태에 따라 부분적인 렌더링을 허용하는지 마는지 여부 같은게 옵션으로 있어요

앞에 30분 정도 보다가 말았네요 ㅎㅎ 재밌는 내용이 있었나요?

아니요 그다지 특별한 내용은 없었어요 ㅋㅋ 그냥 언어 커뮤니티/WG 얘기 쭉~

네 저도 그래서 딴생각하면서 보다가 말았네요 ㅋㅋㅋ

ㅋㅋㅋㅋ 재밌네요 , 디바이스마다 다르게 동작하는군요 ㅋㅋㅋ

웹개발하면서 부족하다 느껴지는 경우 없으신지요

VSCode 여러개 띄울 때는 살짝 부족한 것 같긴 하더라구여

저도 16인데 너무 느려요 가끔 자동완성 안될때 하염없이 기다리는,,,

집랩탑은 32인데 요즘엔 32도 부족한 기분입니다 회사는 16이구용 많이 답답합니다

저는 아이맥 써요 ㅎㅎ 맥북 느려서요 ㅠㅠ M1은 좋다던데요 ㅋㅋ

m1맥북에서 16 뭔가 충분한것 같은 느낌적 느낌이였어요. 집에가서 하드하게 좀 돌려보고 말씀드리겠습니다 ㅎㅎ

회사에서 19년형 16인치 맥북 16기가 쓰는데 가끔 버벅입니다 :disappointed:

추가질문: 여러분 혹시 다 vscode 쓰시나요
+ 혹시 TypeScript 쓰시나요

VSCode 위에서 TypeScript 만 안하면 괜찮지 않을까 하는 이론을 갖고 있습니다 ㅋㅋㅋㅋ

웬지 그럴거같네요 타이핑할때마다 정적분석하느라 엄청 열일하고 있을 것 같은

아니 근데 생각해보니 둘다 마소에서 만든 기술인데 왜 최적화가 그런?!?걸까요

vscode 에서 typescript를 쓰고있습니다...ㅎㅎ
현재 회사에서 쓰는게 i9 - 메모리 32gb 인데 팬날라가고 쓰로틀링걸리는 느낌이 종종 들어요..ㅎㅎ

작업하면서 슬랙콜이나 행아웃하면 누구 팬소리냐고 자꾸 물어봅니다 그럴때마다 죄송합니다 하고 뮤트,,

회사에서 주는거 쓰고있습니다.
서버쪽 일을 주로 하고있고 과거엔 Node 를 주로 사용했지만 최근엔 golang 을 주로 하고있습니다.
GraphQL 은 관심있어서 눈팅만 하고있을 뿐 GraphQL 관련 개발은 하지 않고있습니다 :cry:

구현 좀 해보고 있는데 이거 가정이 더럽게 힘들긴 하네요 ㅋㅋㅋ

그럼 Styletron은 어떻게 했지? 라는 의문이 들어서 보니까 안함 ㅋㅋ

<https://www.styletron.org/concepts#selectors>

일단 적어도 제 컨셉에서는 구현이 불가능해보이고요

이건 시도는 여러번 있었습니다. 레거시가 남아있어서 쓰려면 쓸수는 있습죠

<https://github.com/rrdelaney/ReasonablyTyped> 이런거라던가...

ES2077 ㅋㅋㅋㅋㅋㅋ 웃었네여 ㅋㅋㅋ

제목이 "여러분들이 GraphQL 쓰면서 놓치고 있던 것" 정도면 이목이 끌리나요

말씀하신 부분 때문에 프래그먼트 찾아봤는데 다 resusable 얘기 밖에 안하던데 Reusable 필요없고 깊이가 1단계인 쿼리에 대해서도 fragment 가 필요하나요?

정확히는 colocated fragments 가 필요하고 "colocated fragment", "fragment colocaiton" 등으로 검색하면 좀 나올거같은데요

아님 Relay fragment container 라던가

일단 여기서 간단하게 설명하려고 노력해볼게요

fragment 라고 하면 쿼리의 특정 부분을 독립적으로 기술하고 나중에 재조합 할  수 있는 단위인데요.

이걸 UI 컴포넌트 구성할 때 컴포넌트 하나 당 한 개 내지 몇 개씩 같이 "선언" 함으로써 컴포넌트와 그 컴포넌트가 가지는 데이터 의존성을 같이 배치하는걸 co-location 이라고 해요.

넴 먼가 프래그먼트 - 컴포넌트 응집성을 높이는 느낌이 나네요

co-location 을 하게 되면 자연스럽게 UI 의존성과 데이터 의존성이 일치하기 때문에 가능해지는게 "선언적 데이터 페칭" 이라고 하고요

자연스럽게 의존성 역전이 일어나는 건 덤입니다

쨋든 이걸 하면 어떻고 안하면 어떻게 되냐를 예로 들어드리면

간단한 TodoItem CRUD를 한다고 쳤을 때

```query {
  todos(first: 10) {
    id
    title
    description
  }
}```
뭐 매번 이런 쿼리를 판단해서 예를들면 list container 컴포넌트 같은데 짱박아 둘 수 있을텐데요

이럼 순서가 list 에서 필요한 데이터를 자체적으로 판단해서 패칭해온 다음 그걸 item 에 driling 하는 식으로 개발될거에요?

근데 저희가 fragment container 만 사용한다고 가정하면 그걸 "애초에 신경쓰지 않게" 만들 수가 있습니다

`todos.map(todo =&gt; &lt;item des={todo.description} /&gt;)` 이런거 말씀하시는건가여?

&gt; 이럼 순서가 list 에서 필요한 데이터를 자체적으로 판단해서 패칭해온 다음 그걸 item 에 driling 하는 식으로 개발될거에요?
요게 정확히 어떤 문맥인지 이해가 안되네여

```fragment TodoItem_item on TodoItem {
  id
  title
  description
}```
뭐 이런걸 만들어서 TodoItem 과 선언을 함께 두는거죠

근데 List 도 생기고 뭣도 생기고 하다 보면

컴포넌트가 컴포지션되는것과 동일하게

프래그먼트를 컴포지션하게 되는데

프래그먼트가 잔뜩 있는 상황을 가정해볼 수 있겠죠

필드가 뭐가 필요한지 일일히 추적하지 않아도 굉장히 자연스럽습니다. 그냥 컴포넌트를 컴포지션한 것 그대로 컴포넌트 주변의 프래그먼트를 컴포지션하면 되거든요

일단 1. 관리 측면에서 훨씬 개선이 있고요

2. 중복이나 미스가 절대 발생하지 않게 됩니다

그리고 이제 여기서 createTodo 같은 뮤테이션을 정의한다고 쳐볼게요

mutation 은 이론적으로 커맨드 + 사이드이펙트인데

사이드 이펙트 부분은 리졸버 실행순서만 제외하면 쿼리랑 역할이 동일합니다

```mutation {
  createTodo(...) {
    todos {
      ...TodoItem_item
    }
  }
}```
(일단 예시입니다)

이런 관계로 원래 colocation 이 잘 적용된 코드베이스에선 데이터페칭에 따른 사이드이펙트 처리가 거의 다 생략될 수 있습니다

mutation response 를 직접 다루지 않아요

근데 주변에서 본 코드베이스는 대부분 그렇지 않더라고요

어쨋든 마찬가지로 Subscription 도 동일하고

뭔가 더 공부해야 알것 같지만 <https://dev.to/ricardoromox/colocated-fragments-organizing-your-graphql-queries-in-react-24a6> 이 링크랑 비슷한 건가여?

response 를 직접 안 다루고 props 로 바로 오는 방식?

아 네 프래그먼트 컨테이너는 이 글에 있는거처럼 사용되던게 맞고요

음 근데 뮤테이션이면 사용자 인터랙션에 따라 실행되지 않나요?

예시 코드만 있어도 이해가 빨리 될 것 같은데 혹시 관련 프로젝트 아시나여… 아니면 좋은 글이라도..

제가 회사를 다니면 그냥 회사 코드를 던졌을것인데

쿼리 + 컴포넌트 가 응집되는 건 알겠는데 뮤테이션이 잘 이해가 안되네요

<@UN0GLRW14> 혹시 적당한 예제 갖고 계신거 있습니까 ㅋㅋ

그니까 아폴로 써보셨으면 아시겠지만

뮤테이션 호출후에 뷰 일관성 맞추려면 똑같이 응답 바디를 기술할 필요가 있습니다

Typename 과 id 를 기반으로 추적하고 일치하는 노드가 있으면 in-place update가 되죠

mutation body 가 이런 사이드이펙트에 대한 선언 입니다

물론 필드 꺼내서 핸들링 하고 싶을 수 있지만 그건 부차적인거구요

View 일관성을 맞추기 위한 의존성 단위는 이미 프래그먼트로 단위로 잘 정리가 되어 있습니다