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

GraphQL Korea

유리님 반가워요~ 궁금하셨던 부분들 꼭 질문부탁드릴께요 ㅎㅎ

네~! 조만간 정리해서 질문 채널에 올려볼게요 ㅎㅎㅎ :pray:

저번에 질문 채널에서 질문드리고 시간되실때 스키마 리뷰 해주신다고 하셨었는데, 그런 채널이 있으면 너무 좋을거같아요! 비슷한 고민을 하시는 분들과 공유도 하구요 ㅎㅎ

근데 전 아직 스키마 작성을 하지 못했네요.. :disappointed:

One Step at a time
&gt; Get validation and feedback more frequently
Don't try to model your entire business domain in one sitting. Rather, build only the part of the schema that you need for one scenario at a time. By gradually expanding the schema, you will get validation and feedback more frequently to steer you toward building the right solution.

곧 relay 11에 포함되겠네요 ㅎㅎ

그치만 저도 Nexus.js를 꽤 오래 팠기때문에… 이해합니당

풀스택으로 GraphQL을 써본적이 없지만 풀스택이면 code first를 선호하게 되지 않을까요 ㅎㅎ

관련 인사이트가 좀 궁금한데 공유해주실 수 있나요? ㅎㅎ

<https://graphql-korea.slack.com/archives/CN13FD736/p1613993340005200?thread_ts=1613989211.004600&amp;cid=CN13FD736>

schema-first 방식이여야, 더 나은 API 구조에 대한 논의를 할 수 있을거같아서요 ㅎㅎ

&gt; 풀스택으로 GraphQL을 써본적이 없지만 풀스택이면 code first를 선호하게 되지 않을까요 ㅎㅎ
그럴수도 있겠네요 ㅎㅎ 한명이 개발한다면 굳이 스키마 리뷰가 필요없을테니까요.

답변 감사합니다. 의사소통 관점에서 코드퍼스트보다 스키마퍼스트가 유용하겠네요.

네네 ㅋㅋ 저희팀에서는 스키마 회의 되게 잘 이루어지고있는데, 되게 즐거운 경험이더라구요. 이름 하나하나 같이 지어가는 재미가 있어요

이미 다 만든 상태에서는 필드명 하나 바꿔달라는게 쉽지 않아서요 ㅠ

희태님 반갑습니다! ㅎㅎ 잘 부탁드려요~

라니님 안녕하세요!! 반가워요 ㅎㅎ AWS Amplify 개발 경험은 어떨지 궁금하네요 ㅎㅎ

진짜 디렉티브 메타프로그래밍의 무궁무진한 가능성을 보여주는군요

<https://twitter.com/michaeldgrahams/status/1378746406677061633>

Neo4j 도 ㅋㅋㅋ

아 아직 Rust 버전이 릴리즈 안된거였나요???

저 이름으로 0.0.1 릴리즈된지 2주쯤 된듯

구조적으로 당연하게도 language plugin 을 못붙일텐데 Flow 타입은 기본으로 생성하도록 하나보네요

타입스크립트 지원 어떻게 붙일지 매우 궁금

깃헙엔 버전 3 얘기만 있는데 어디서 보셨어요? <https://github.com/apollographql/apollo-client/blob/main/ROADMAP.md|https://github.com/apollographql/apollo-client/blob/main/ROADMAP.md>

<https://github.com/apollographql/apollo-client/projects/4|https://github.com/apollographql/apollo-client/projects/4>
여기서 확인했습니다

Urql 도 프레임워크 만든다는 얘기 하고있어요! 전 왜 아폴로는 기대가 안될까요 ㅋㅋㅋ.....

아폴로.. 쓰면 쓸 수록 relay쓰고 싶네요 ㅠ 수 많은 레거시들 고통스럽습니다

더 가볍고 테스트하기 쉽고 잘 짜여 있어요

장점 나열하면 정말 많이 나열할 수 있는데...
• 일단 기능이 확실하게 좋고, 모두 opt-in-out 이 가능하고요 (아폴로는 그냥 다 때려밖혀 있음)
• 구현이 훨씬 깔끔하고 테스트하기 쉬워요
• 많이 가벼워요. 기능 최소한으로 쓰면 7.6kb 수준이고 완전히 side-effect free 라서 그 이하로 쓸 수 있어요.
• exchange를 끼워서 기능을 확장하는데 populate cache 라는 강력한 유틸도 있고 서스펜스도 지원하고 등등....

제일 중요한건 버그가 적습니다

아폴로 클라이언트는 진짜 끔찍할정도로 버그가 많아요

지금 테스팅 힘들다고 한것도 아폴로 테스팅 라이브러리 버그 때문이였고.... 허허;

그리고 아폴로 인터페이스 이상해요 너무 over exposed 되어있음

아 그리고 urql 이 문서도 더 친절해요

끝도없네 그냥 모든 방면에서 더 낫습니다

후.. 아폴로 버리고 릴레이로 갈지 urql로 갈지 고민되네요
아폴로에서 배치 쿼리나 Persisted Query 이것도 exchange로 따로 만들어야할까요

배치는 모르겠네요 커뮤니티 찾아보면 뭐 있을법한데 직접 만든다고 해도 그렇게 어렵지 않아요

apollo 배치는 비표준 쿼리니까 ㅎㅎ.....

아 @defer, @stream urql에서 지원하나요?

그냥 아폴로 서버랑 같이 갖다 버리시죠

defer &amp; stream 은 지금 릴레이만 지원하나

피쳐 테이블 여깁니다 <https://formidable.com/open-source/urql/docs/comparison/>

아폴로 서버도 참 여러모로 이상한 물건인데...

아폴로 3.5부터 defer, stream 지원한다는대.. 어려운건 아니니 urql에 그냥 exchange 하나 만들어서 쓸 수 있으면 써봐야겠네요

전 지금은 apollo 긴 한데 ㅋㅋㅋㅋㅋㅋㅋㅋ 좀 전엔 mercurius 썼었고

속마음은 node를 탈출하고 싶습니다

<https://github.com/FormidableLabs/urql/projects/4> 요거 와칭하시죠

아 하나 더 있다 Urql Devtools 도 더 좋아요

Apollo DevTools 는 너무 느리고 버그 많아서 캐시 디버깅할때 뒤집어질 뻔

오 그건 혁신적이네요 ㅋㅋㅋㅋ

아폴로 개발자도 DevTool 안쓰고 콘솔로그 쓴다는..

근데 GraphQL 생태계에서 백엔드는 노드쪽이 가장 크지 않나요?

프레임워크는 그렇지 않습니다

되려 노드쪽에 쓸만한 프레임워크가 없고... 다른 언어 보면 굉장해요

아 생각해보니 Dgs나 graphql ruby같은게 있네요

(다른 언어는 언어 통합 포인트가 JS 보다 월등히 많기 때문에 애초에 툴링이 그렇게 필요하지 않았을 수도)

네 Dgs 이전에도 JVM GraphQL 생태계 거대하고요

GraphQL Java, GraphQL Kotlin, Sangria, Caliban...

지금은 ORM 장사하고 계신 그... 쪽에서

예전에 GraphCool 일떄 만들다가 접은게 있긴 합니다만

파이썬은 그래핀 있고, 고도 gqlgen 있죠

지금 언급한애들이 다 데이터 모델이 이미 통합되어있거나 통합하기 어렵지 않아서 빠르게 뭐 만들때 괜찮아요

<https://github.com/graphql-rust/juniper>

예전에 채널에 함 공유했었네요

시간날때 Actix에 붙여서 써봐야겠네요 ㅋㅋㅋ 

사실 굳이 따지면 node 도 있을거 다 있는데

(그렇다고 Nest 같은걸 끼얹자는 얘기는 아님)

노드쪽은 Typegraphql 이랑 많이 쓰는거 같더라고요 

graphql-ruby 수준의 무언가가 나오면 편할거같긴하네요

아 전 그거 굉장히 싫어함 ㅋㅋㅋ

ㅋㅋㅋㅋ 프로덕션 레벨에서 쓰긴 해서 썼는데 불편함이 후..

데코레이터 표준도 아니거나와

ES 데코레이터가 자바 어노테이션 만큼 할 수 있는게 많았으면 몰겠으나

좀 아닌거같습니다... 괜히 다 클래스로 만들어서 타입 다루기도 불편해지고

타입이랑 하등 상관도 없는데 그냥 ObjectGraphQL 이라고 하지 허허

Typegoose나 TypeORM 처럼 데코레이터가 타입추론 가능해서 붙인건가 싶기도 하네요 ..ㅋㅋ

:ear:가 얇아서 urql 함 써보기로… ㅋ

사실 저 훅들 원래 다 있었고 (experimental) 커뮤니티 relay-hooks 는 열화판 복제에 불과합니다

홈페이지 겁나 바뀌었네요 ㅋㅋ

<https://graphql.org/community/upcoming-events/#asia> PR 하나 가시죠

John Resig은 어떤 사람이에요? 저 사람 블로그는 본적이 없는 것 같은데 ㅎㅎ

그러게요 ㅋㅋㅋ <https://lorensr.me/> 블로그는 이쪽인 것 같고 컨설턴트 같네요 저도 아직 컨텐츠에 대한 확신이 없어요 ㅋㅋㅋ

그렇군요 ㅌㅋㅋ Production Ready GraphQL 는 믿음이 갔는데

그 분은 Visibility 가 워낙 좋았으니까요 ㅋㅋㅋ 근데 그러고보니 요새 Marc-andre 뭐하시는지 트위터에서 안보이네요 :eyes:

<https://twitter.com/__xuorig__/status/1382763752274202626>

는 그냥 제가 놓친것

호오... 혹시 메모리 부족해서 문제됬던 경우는 없으셨나요?

m1 맥미니 구매해서 썼는데, 저도 bahwan님과 비슷한 도구들만 썼는데 문제없이 잘 동작했습니다.

메모리 부족한 것도 경험을 하진 못했습니다.

오 ㅋㅋㅋㅋ 백수기간동안 할만한 뭐 재밌는거 찾아봐야겠네요

음... 이해도 되고 굉장히 유용하겠네요. 다만 스키마 nullability 디자인의 중요성을 떨어트릴까봐 다소 걱정되긴 합니다

&gt; Marking Schema fields as non-null can introduce particular problems in a distributed environment where there is a possibility of partial failure regardless of whether the field is intended to have null as a valid state.
이걸 인정하면 외부 시스템에 의존하는 모든 필드는 nullable 하게 표현되고 모든 nullability 는 클라이언트에서 결정해야 한다고 비약할 수 있는게 아닌가 싶기도 하고요

그리고 재귀 적용 항목은 없었으면 좋겠군요

저도 이거 되면 당장 필요한 곳이 있긴해요. 원래 정적분석 짜서 해결해야 하는걸 그냥 클라이언트에 선택권을 쥐어줄 수 있으니...

페이스북 엔지니어가 언급한대로 프래그먼트 사용하면 복잡성이 좀 높아보이네요 (그리고 당연히 프래그먼트를 써야함)

Relay는 자체적으로 컴파일러가 있고 런타임통합이 있으니까 sensible default 를 제어할 수 있는데 보편적으로는 어렵지 않나...

그리고 스키마 안정성을 떨어뜨리겠다는 생각도 들어요. 사실상 모든 필드에 대해서 nullability 의미론을 무효화 할 수 있게 된다는 소리니까 Breaking change 범위도 훨씬 넓어지겠네요

회사 내부에선 언제 새로운 microservice가 생겨서 federate할 지 모르는 상황이라 이미 모든 필드는 nullable해야한다는 쪽으로 가고 있어요 그러다보니 이런 syntax/directive가 더 필요해지긴 했네요 ㅎㅎ <https://graphql-korea.slack.com/archives/CN0G9HJAJ/p1620406976092600?thread_ts=1620403285.091600&amp;cid=CN0G9HJAJ>

fragment 끼리 겹치는 건 어떻게 할지 좋은 생각이 안나고 있어요 ㅜㅜ

Relay 아닌 client들은 미리 compile 하는 스텝이 필수도 아니라서 linting이나 compile check을 할 수도 없고

어떤 새로운 breaking change가 생기는 건가요?
<https://graphql-korea.slack.com/archives/CN0G9HJAJ/p1620409460093600?thread_ts=1620403285.091600&amp;cid=CN0G9HJAJ>

위 스펙대로면 기존 코드에는 breaking changes가 없을 것 같고, 이후 유지보수할 때 늘어날 수도 있겠다 싶긴 하네요

Make non-nullability apply recursively 스펙은 있으면 진짜 편리할 것 같은데 쓰다가 partial optional이 필요할 때엔 어떻게 해야 될지 모르겠네요. (안쓰면 되겠지만)

&gt; 어떤 새로운 breaking change가 생기는 건가요?
아주 새로 생기는 건 아니고요. 기존 스키마 레벨 nullability 에선 non-null 필드에서 null 허용으로 변경하는게 타입 레벨에서 브레이킹 체인지가 아닌게 보장되지만 그걸 client 에서 결정하게 타입 레벨 nullability 는 신뢰할 수 없게 되니까요

아 그렇군요. 저는 client가 nullable field를 nonnullable로 생각하는 시점에서 리스크는 client가 지는 게 당연하다고 생각했어요 ㅎㅎ typescript에서 any 쓰는 거랑 같은 거죠

GraphQL Meetup 얘기는 잘 되었나요 :eyes: 미팅노트 이제 읽어보려는 참인데

역시 Relay 가 RFC 여기저기서 Prior art 로 활약하는군요

페이스북이 가장 열심히 쓰니까요 ㅎㅎ 이 Proposal은 Stage 1이 되서 implementation 해보는 게 다음 스텝이에요

방식 차이는 있는 것 같지만 다들 필요하다고 생각하더라구요

엄청 짜증났었는데 빨리 써보고 싶네요 ㅎㅎㅎ

ㅋㅋㅋ 별건 아니고 원래 생성된 타입이 boundary type 인데 type annotation 이 없었다고 하네요

타입 어노테이션만 붙여서 20% 정도 개선....

GCG는 마스터 머지될 때마다 카나리 빌드가 돌아서 지금 바로 쓰실 수 있어요

오 네 알겠습니다. 한번 써볼께요!

생각해보니 저기서 업데이트된 plugin을 쓰지 않고 있네요…

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

리터럴리 GraphQL 안쓰는게 오버킬이라는 얘깁니다 ㅋㅋㅋㅋ

ㅋㅋ아 말그대로 엄청난 찬양이었군요 ㅋ

전 상당히 진지하게 동의합니다

저도 뭐 graphql 접한뒤론 rest 를 굳이 쓸 상황이 있나싶어요

백엔드 개발자 한 명이고 프론트엔드 개발자 5명 있고 그러면 의미 있긴 할듯

그럴땐 DB 인터페이스(CRUD)만 적당히 처리하고 대부분 로직을 프론트엔드에서 구현할 수 있긴 하죠 ㅋㅋ

ㅋㅋ거기서도 grapgql로 해서 prisma 로 generated crud 로 해버리면 백엔드는 ㄹㅇ 셋업만하고 끝나는 셈 인가요

음 해당 서버쪽 이슈일거같은데요 ㅎㅎ

네 ㅜㅜ <https://issuetracker.google.com/issues/117181234?pli=1|https://issuetracker.google.com/issues/117181234?pli=1> 이슈인듯 해요

반갑습니다~~ Apollo iOS 관련 노하우 한번 듣고싶네요 ㅋㅋ

저도 아직 입문 단계라서요 ㅋㅋ
공부하다가 괜찮은 자료가 있다면 공유할 수 있도록 하겠습니다~

반갑습니다~~ <@U027AET136C> 님도 반갑습니다 ㅎㅎ