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

GraphQL Korea

오… 그런가요?! 전 완전 반대로 생각했었는데..!! 말씀하시는 지표가 어떤건가요??

MAU 라던지 너무 뻥튀기되는거 같아요 ㅋㅋㅋ 이탈도 너무 많고

그렇군요!ㅋㅋ 저는 아이오닉 뽕에 취해있어서 그런지 아이오닉 기반으로 개발해서 출시하면 기반은 웹기술이지만 아웃풋은 앱이라서 이탈율 측정에 관한 건 생각 못해봤네요… :thinking_face:

Yarn 2도 pnp 때문에 문제가 많은거같더라구요.. 어휴 ㅠ

yarn 2 문제가 아닙니다 pnp 짱입니다 모든건 npm의 문제입니다

implicit transitive peerDeps 를 보시면 yarn 2 를 탓하지 마시고 해당 프로젝트를 PR로 혼내주세요

우리 노드 생태계 푸르게 푸르게

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 저도 pnp가 답이라고 생각은 하는데

요새 하는 개인프로젝트는 전부요

<https://github.com/cometkim/yarn-plugin-bump>
<https://github.com/cometkim/gatsby-plugin-typegen>
<https://github.com/cometkim/cometjs>

이제 install 5초이상 걸리면 답답합니다…

CI에서 restore_cache 할때마다 답답…

PNP 관련해서 webpack integration 진행이 많이 되었나요?

잠깐 가지고 놀긴 해봤는데 아직은 때가 아니라고 생각했었는데

네 뭐 관련해서는 딱히 문제 겪은 적 없네요

~는 댓글까지 올라가서 확인중이에요…~ 설정 완료

이제 150명 되면 GreetBot 끄려구요 ㅋㅋㅋ

ㅋㅋㅋㅋ 봇 그냥 계속 있어도 좋지 않을까요?ㅋㅋㅋ 들어오는 사람 반갑게 맞아주는것 같아서…ㅎㅎㅎ

ㅋㅋㅋㅋㅋ 그럴까요 ㅋㅋ 그럼 안 끄겠습니다 ㅋㅋ

ㅋㅋㅋㅋㅋ ReasonML은 이미 보고있었어요 ㅋㅋ 그냥 공부용으로요

저번에 todomvc 만들었고, 다음에 relay issue tracker example 만들려고 했는데 js resource 바인딩 하다가 막혔네요

물어볼 사람이 있으면 좋은데 커뮤니티에 죄다 ocaml 고인물들밖에 없어서 좀 그렇...

국내 reasonml 커뮤니티는 누가 안만들까요 :eyes: 내년 state of js 에선 분명 떡상할것입니다

저도 뭔가 Reason에서 JS 생태계를 깔끔하게 이용할수있으면 좋을거같은데, (제가 아직 잘 몰라서 그럴수도 있는데요 ㅋㅋ) 조금 힘든거 같더라구요.

BS 바인딩 엄청 쉽고 간결한편이에요! ㅋㅋ 거의 그대로 쓸 수 있습니다. 아쉬운 점이라고 하면 commonjs 기반인 것 정도

바인딩 자체는 쉬운데 js 라이브러리에 워낙 unsound 한 인터페이스가 난무하다보니… 지식이 부족해 변환을 못하고 unsafe하게 쓸 뿐

ㅋㅋㅋ 회사 코드에 Reason + ReasonReact 쓰면 쫒겨나는거 아닙니까… ㅋㅋㅋ 어디 쓸만한데 없나…

저도 팀장님한테 뺨맞을까봐 쓰자는 얘기는 아직 못해봤는데

개인 프로젝트는 조금씩 옮길 준비를 하고 있습니다 ㅋㅋ

저도 개인프로젝트 하면 쓸거같은데… 지금 학교랑 회사를 병행하고있어서 ㅋㅋ 전혀 여유가 안나네요

밋업 진행 하시나요? 저번 주제 이제 정리 시작하면 되려나 ㅋㅋ;

ㅋㅋㅋㅋ 일단은 보류중이에요 TS 온라인 밋업하는거 한번 보려구요 ㅎㅎ

는 제가 Codegen + Relay 발표합니다 ㅎㅎ

호호 저도 reason relay 보여드릴까요

어 뭐야 gql meetup 얘기하신게 아니라 ts meetup 얘기하신거잖아

codegen 이 동작 안해서 14.6.0 으로 사용중이에요 ㅠ

앗 ㅋㅋㅋ toolkit 이 버전 올려버렸더라고요

yarn resolution 으로 강제로 올렸더니 터지는 데가 좀 있는 것 같아요

와 이거 좋네요 ㄷㄷ.. 감사합니다.

ㅋㅋㅋㅋ 제가 필요한 Facebook Integration이 없군요 ㅠ

앗 그건 예정대로 직접 만들게 되시겠궅요 ㅋㅋㅋㅋ

<https://github.com/zth/reason-relay> 요거요??

이슈트래커 예제 클론하고 있는데

일단 릴레이 컴파일러 프로젝트들 중에서 제일 유지보수 잘되고 있기도 하고

요약: <https://github.com/zth/reason-relay/issues/48#issuecomment-620725931>

ㅋㅋㅋ 스타수가 적어서 봐야하나 생각만했는데… ㅋㅋㅋㅋ

제가 학업 + 업무를 병행하고 있어서요 ㅋㅋㅋ 회사에서 오프라인으로 열면 업무시간에 틈내서 준비할 수 있어서 좋은데… ㅋㅋ 뭔가 힘드네요 ㅠㅠ

그랬는데 최근에 엄청나게 개선한 것 같긴하네요. 패키지 관리를 The guild 로 넘기고 여기서 3.0 이후로 좀 유니버셜하게 사용할 수 있게 개선한 모양입니다. 번들사이즈도 좀 합리적으로 줄이고 트리쉐이킹도 되는군요

• graphql-tools: <https://bundlephobia.com/result?p=graphql-tools@5.0.0>
• graphql-utilities: <https://bundlephobia.com/result?p=graphql-utilities@0.0.14>

좀 예전엔 클라이언트 스키마 쓴다고 하면

Apollo Client 150K + link schema 12K + graphql-tools 250K 이런 식으로 늘어났거든요. ㅋㅋㅋ;

그래서 apollo-link-state가 apollo-utilities 라는 커스텀 경량 구현체를 들고 있었고

그런데 apollo client v3 는 apollo-utliities 조차 의존성 안쓰고 번들사이즈도 굉장히 크게 줄였군요 <https://bundlephobia.com/result?p=@apollo/client@3.0.0-beta.44>

Urql + populate + graphcache 쓰는거랑 이제 크게 차이 안나네요 와우

그래도 클라이언트에서 graphql-tools 를 쓰고자 한다면 더블이 되긴 하죠... 제가 번들사이즈에 너무 민감해서 그런지;

그러면 apollo client로 클라이언트 스키마 구성하고, relay network로 달아봐야겠네요.

저도 개발중인 프로젝트라... 아직 번들 애널라이저를 안돌려봤네요 ㅋㅋ

• <https://github.com/relay-tools/relay-local-schema>
• <https://relay.dev/docs/en/local-state-management>

<https://babangsund.com/relay_local_state_management/>

이 동네는 전부 수동... ㅋㅋㅋㅋ

`__clientField` 디렉티브가 존재하긴 하는데 이거 문서화가 안되어 이씅ㄹ 거에요

이래놓고 약을 이렇게 판다니 (웃음)

<https://github.com/hasura/graphql-engine/issues/2323>

Hasura도 이쪽은 상황이 비슷하군요. Relay 지원한다 하지 않았나...?

Prisma가 ORM보다 Control이 앞서나요…?

그들의 주장이자 목표죠. 일단 전 아니라고 생각하긴 하지만

차라리 더 Managed 인게 장점이라 했으면 팔릴 것 같은데

ㅋㅋㅋㅋㅋㅋㅋ 온라인이라서 영상으로 남는게 좋더라구요 (TS 온라인 밋업도 라이브로는 많이 안보시더라도 녹화는 꽤 많은 분들이 보시는거같아요)

ㅋㅋㅋㅋㅋ 저 그거 해결을 못하겠어요 ㅋㅋㅋ

그냥 고치긴 고치는데 Prettier 가 코드를 지워버리질 않나 문법에 안맞게 포매팅을 하질 않나

저는 아직도 사람들이 왜 프리티어 같은걸 좋아하는지 모르겠어요

포매터로써도 ESLint 가 우월한데...

암튼 이거 무시하는 방법 없나요

ㅋㅋㅋㅋㅋㅋ .vscode/settings 지우시면 됩니다

ESLint에도 포매터가 있군요 ㄷㄷ 몰랐어요

<https://github.com/cometkim/cometjs/blob/master/packages/eslint-plugin/index.js>

```{
  plugins: ['@cometjs']
  extends: ['plugin:@cometjs/auto']
}```
설정 미리 해두면 이걸로 끝

저도 미루다 미루다 한거지만 ㅋㅋㅋ

ㅋㅋㅋㅋㅋ 꿀냄새가 여기까지나네요 ㅋㅋㅋ

ignore 도 안먹히네요 짜증나네....

더 웃긴건 import type 문법은 이해를 못하는지 쓰면 모든 코드를 지워버려요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

ㅋㅋㅋㅋㅋㅋㅋㅋ yarn remove prettier 해주시죠 ㅠ

그래도 VS Code 플러그인은 깔려있나 봐요 ㅋㅋㅋ

PR로 드릴까요 가이드로 드릴까요 ㅋㅋ

음... NexusGen type 추론하기 짜치는군요

ㅋㅋㅋㅋ 제 비루한 코드에 컨트리뷰션이라니 ㅋㅋㅋ 감사합니다

음 Nexus 에선 추론 못할 것 같네요. 왠지는 모르겠지만

&gt;  nexus.d.ts(51, 3): The expected type comes from property 'User' which is declared here on type '{ Image?: undefined; Query?: undefined; User?: undefined; }'
선언 끝까지 추론해서 따라가도 유틸리티에서는 undefined로 잡혀버리네요.

예전에도 이래서 넥서스 버렸던 것 같은데

어차피 nexus 쓰면 이 라이브러리 안쓰겠죠 ㅋㅋ

아니 애초에 넥서스가 리졸버 타입을 생성해주면 간단하게 될 것 같은데 왜 없죠 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

덤으로 nexus plugin 만들어야겠다...

일단 타입 넣어둘게요. 넥서스는 망가져요

혹시 이렇게 리졸버 단위로 캐시해보신적 있나요?? DataLoader나 쿼리 단위 캐싱은 뭔가 다들 할거같은데, 리졸버 단위 캐싱 하는게 사례가 있나 해서요 ㅋㅋ

<https://www.apollographql.com/docs/apollo-server/performance/caching/>

이런거요? ㅋㅋ

이걸로 CDN 캐시 활용하는 사례는 몇개....

<https://www.notion.so/20b143881c534b3692d57928086227ed>

저도 이제 조금씩 써보는 입장이라 어떻게 하면 GraphQL을 더 쉽게 이해시킬 수 있을지 궁금합니다 아무래도 가장 좋은건 실제 사용 예시를 보여주는게 가장 좋을 것 같기도 하고…

서버 분들께 소개하는거라면, Resolver가 뭔지 + DataLoader까지 소개하시면 금상첨화일거같습니다 ㅋㅋ 자료 좋네요 ㅎㅎ

이런거 너무 좋은거같아요 ㅋㅋㅋ 공유해주셔서 감사해요~~

말씀해주신 내용을 넣으면 더 좋을 것 같네요! 고맙습니다 :smile:

아그렇군요??!!ㅋㅋㅋㅋ당연히 지난줄알았네요 ㅋㅋㅋㅋ 감사합니다:pray::skin-tone-2: 기다려지는군요:rocket::fire:

ㅋㅋㅋㅋㅋㅋㅋ 엇… 열심히 준비해볼게요!

<@UNWULF2DS> 발표 만족스러우셨나요? ㅋㅋ 걱정이네요 ㅋㅋ

좋았습니다:+1::skin-tone-2::+1::skin-tone-2::+1::skin-tone-2:선언적 프로그래밍 하루종일 찾아봤네요 ㅋㅋ 뭔가 이것저것 더 물어보고싶었는데 시간이 부족한게 초큼 아쉬웠습니닼ㅋㅋ

그 뭔가 스토리로 말씀해주시니까 지금까지 제가 사용했던 기술들을 고민하게 되었어요:+1::skin-tone-2: 

React 사용이 많이 증가했는데 negative 쪽으로 아주 약간 기울어진 이유가 궁금하네요. :thinking_face: CM이나 Fire같은게 늦어져서 그런가?

CM이랑 Fire가 어떤건가요? 단어가 짧아서 그런지 검색이 어려워서 링크같은거 던져주시면 감사하겠습니다!

Fire: <https://github.com/facebook/react/issues/13525>

CM: <https://reactjs.org/docs/concurrent-mode-intro.html>

이것들입니다

이유를 찾을게 어딨겠습니까 이미 저 끄트머리에 있는데 ㅋㅋㅋ

CM 은 나오면 오히려 negative 가 많아질 거라 생각합니다

전체적으로 전부터 다수의 선택을 받으면 부정적인 비율도 높아지는 추세였습니다. 유일한 예외가 Jest

Jest말고도 Vue, Svelte, Apollo 등 다양하게 오른쪽 상단으로 증가한 것 같아서요 ㅋㅋㅋ

node_modules를 버전관리한다는게, git에 커밋하는거 말씀하시는건가요??

차이 많죠 집도착하면 적어볼게용

일단 적어도 node_modules 는 vendoring 용이 아닙니다 지원 안함

그래서 벤더링하는건 예전엔 non_npm_modules 이런 디렉토리에 쓰기도 하고 그랬어요

좀 더 심플하게 vendor 디렉토리라던지

일단 yarn2 쓰기 전에 PnP 를 이해해아합니다.

• 백서: <https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-plug-an-play.md>
• 소개: <https://yarnpkg.com/features/pnp>

뭐 대충 요약하면 node_modules 는 IO 부하가 심각하고 require.resolve 알고리즘 자체가 너무 복잡하고 기타 등등 다양한 문제를 내포하고 있는데 이를 해결하기 위한거고

그냥 단순히 install 빠르게 하자고 벤더링으로 돌아가는 내용은 아닙니다

현재 yarn 2의 구현에서는 의존성들을 오프라인 미러 (cache)에 zip fs 로 가상화된 파일시스템과 .pnp.js 라는 단일 실행파일에서 직접 접근하기 때문에 현재의 yarn이나 npm 같은 "추가 런타임"이 필요하지 않게 되고 (적어도 CI에서는) 애플리케이션에서 모듈 resolve 하는 속도도 훨씬 빠릅니다.

install 빠른건 그냥 부가 효과구요

그리고 postinstall 없애고 패키지를 해시 포함해서 immutable 하게 관리하기 때문에 히트율이 로그스케일로 높아져서

글로벌 캐시를 사용하더라도 자주쓰면 빨라져요

(이건 pnpm이 공유하는 접근방식)

아 원래 질문으로 돌아가면 혹시라도 node_modules 커밋하시면 안됩니다. postinstall 패키지들 다 깨져용

(Crossenv 안됨)

아 감사합니다 전 단순히 yarn cache 나 node_modules 나 둘다 인스톨 한 패키지들 들어있어서 같은거 아닌가? 당연히 얘네들을 커밋하면 install 이 빨라지는거 아닌가? 라고 생각하고 단순하게 있었어요. 차이가 크네요.
링크들 감사합니다 조금 더 공부해봐야겠어요.

(graphql 질문은 아니니까 질문 채널 아니어도 괜찮겠죠?)

pnpm을 "지원하지 않는" 패키지는 없고요

implicit transive peer dependencies 문제인 것 같은데 이건 npm 생태계의 고질적인 문제에요

그냥 해당 패키지가 매니페스트를 잘못쓴거니까 PR 열면 됩니다

yarn 2 릴리즈 이후로 이슈화가 되서 요즘은 많이들 고친 편입니다 (관리되고 있는 라이브러리라면)

뭐 yarn 덕분에 다들 저 문제를 무시 못하게 됐다면서 pnpm 개발자들이 농담반으로 좋아하고 그랬었죠

저도 덕분에 이삭좀 많이 주웠고 ㅋㅋ

오홍 그렇군요. 다음에 주울 기회가 있으면 주워봐야겠어요 ㅋㅋ 감사합니다.

저는 다 씁니다. ignore로 빼고 files로 넣고

사실 이거, 자동으로 .yarnignore .npmignore .gitignore 순으로 대체 되어야 좋은데,
어떤 건 호환되고 어떤 건 호환 안 되고 그렇습니다.
그래서 같은 내용으로 .npmignore .yarnignore 같이 두는 게 안전빵이겠네요.

<https://github.com/yarnpkg/yarn/issues/754>

<https://github.com/microsoft/TypeScript/issues/38510>

아… 이거 저도 옮겨야될 프로젝트가 있는데, 안 옮기려구요… ㅎㅎ…..

TypeORM보다는 그래도 간결해보이네요

어제 발견 했는데 Star는 꽤 많더라구요

킵해놓고 다음에 도입해봐야겠어요 ㅋㅋ

이런 친구들은 타입매크로로 쿼리 분석하고 타입매칭 시켜주나요?

Sangria 가 좀 많이 verbose 해서 만들었다고 하셨는데 매크로보단 데이터 클래스 그대로 사용하는 걸로 보이고요

하지만 전 쿼리는 관심 없으므로 (프론트엔드는 어차피 Reason 쓸거기 때문에) 패쓰