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

GraphQL Korea

띠용? 이거 GraphQL 문법에 추가되나요?

하하 논의만 오래 있었죠…. ㅠㅠ

많이 쓰이기 때문에 가능성이 큽니다. 구현은 쉬워서 금방 추가 될 것 같은데 문법 디테일가지고만 질질 끌리는 중이죠…

다음 스펙 개정때 포함되지 않을까요..? ㅋㅋㅋ

firebase function에서 튀는건 cold start 문제가 아닐까요?

네 맞습니다. graphql 하나의 펑션으로 작성하고, 코드의 양이 커지다보니 코드가 올라가는데 시간이 걸리는 것 같아요.

근데 제가 람다같은걸 안써봐서 그러는데, 요청을 지속적으로 보내면 콜드스타트가 발생하지 않아야 하지 않나요? 가령 싱글 프로세스로 로드테스트를 해보면 중간에 하나가 튀곤 하네요.

어... 한번 웜업 된 뒤에는 일관적인 레이턴시를 보장해야 되는데요.

혹시 memory cache를 많이 사용하시나요?

네, 요청의 양이 적어서 우선순위가 뒤로 밀린건지는 모르겠지만, 요청이 중간에 튀는게 감이 잘 안잡히더라구요. 전체 코드를 다시 리로드 하는 것 같습니다.

캐시 없이 firestore를 직접 호출해서 쓰는데, 내부 로직이 메모리를 쓰진 않을 거라 예상하고 있어요.

중간에 함수 micro VM들이 죽으면 다시 시작하긴 할텐데..
혹시 함수 내부에서 매번 리퀘스트마다 비싸게 재계산 하는 녀석은 없을까요?
이쪽 계열에서는 재사용가능한 녀석을 전역변수로 빼는 패턴을 선호하긴 합니다.

전체 코드를 다시 리로드하는 경우는 모든 microVM들이 죽었다(...)고 생각되는 케이스같은데

별도의 exception은 발생하지 않았나요?

음 근데 사실 Hello World만 응답으로 내려주는 펑션을 짜서 똑같이 테스트해볼때도, 중간에 하나씩 튀는걸 보긴 했습니다. 다만 코드의 양이 작아서 딜레이가 짧은 걸 봤었어요.

제 코드에선 튈때 10초가 걸리고, 헬로월드는 1초가 걸리는 차이 정도랄까요

그래서 최대한 최적화를 위해 웹팩으로도 말아보고 그런 시도를 해왔습니다.

어... 혹시 firebase function region은 서울인가요?

클러스터 자체가 도쿄였던거 같긴 한데요..

제 기억에 함수마다 리전을 설정하는걸로 기억하는데..

asia-northeast1 입니다. 서울리전이 나오기 전에 만들었던 것 같아요.

아 정말 궁금하네요 왜 레이턴시가 튀는지

도움되지 못해 죄송합니다 ㅠㅠ

아닙니다, 양질의 조언 잘 구했습니다. 말씀주신 방향으로도 디버깅을 해봐야겠어요!

지금 요청 100개를 동시에 보내면 모든 응답의 도착 시간이 다른가요?

제 로컬에서 측정하는거긴 하지만, 대부분의 리퀘스트는 비슷하게 측정되고 한두개만 튀긴 합니다.

나름 최적화를 시켰더니 10%에서 1%로 줄긴 했었습니다

아아 지금 말씀 주신건 웜업 된 이후죠?

웜업이후에도 1%정도가 튀는건 불안정하네요

아 100개를 동시에 보내진 않고, 블록킹 콜 100개를 순서대로 보냈습니다. 

음 레이턴시가 튀는 녀석은 맨 처음 요청인가요? 아니면 요청 중간에 요청한 녀석인가요?

모든 microVM이 죽는다는 것도 말이 되는 케이스는 아니라서요

제 코드는 아니더라도 같은 환경을 구축해본 뒤에 공유를 드리던가 해야겠네요

그러면 뒤에것도 느려야 하는데

음 구글 클라우드 함수가 노드버전 10이면 아마 베타긴 할텐데 설마...

그거 요청 레이턴시 말고 다른 지표는 더 없나요? ㅋㅋ

아니네요. 노드 10이면 이제 베타에서 정식으로 넘어왔네요

익스프레스 미들웨어로 레이턴시 로그 찍어봐도 비슷했고

혹시 클라우드 펑션 외에 외부 서비스 레이턴시는 보장이 되는 상태인가요?

아웃바운드 네트워크를 통하는 녀석들이요

그 튀는 요청에는 무언가 코드를 다 로딩하는 로그가 찍히긴 했어요

음 slack api, sentry, kakao, fb, google, apple, android

디펜던시를 호출하지 않는 콜로 테스트해보긴 했었어요

아 외부서비스 영향은 아니라는 말씀이시군요.

그냥 요청 많이가서 인스턴스 확장되는 타이밍에 튀는거 아닌가요? 그럼 같은 테스트 시간 두고 테스트했을 때 일정하게 재현될 것 같은데

몇배수로 확장하는 식일테니 선형적이진 않을가ㅓ고

무료플랜을 사용하시더라도 microVM 엄청 많이 처음에 띄워서

일단 AWS는 그런데 GCP는 좀 적게 띄우나 (..)?

TPS 적어도 일단 GraphQL 서버고 PQL 안쓰는 이상은 다른 api 서버보단 리소스 괴물같이 먹긴 하겠죠

스키마가 어마무시하게 크다거나

근데 지금 질문에서는 GraphQL 처리 외에도 hello-world 수준 애플리케이션에서도 발생한다고 하셔서요

네, 레이턴시의 차이는 없지만요

비슷한 환경을 구축해서 코드로 공유드리는게 좋을 것 같네요!

일단 말씀주신 것 보면 GCP버그에 한표입니다 (..)

AWS Lambda에서는 본적없는 현상이에요

그 사실 재현되는 환경 만드시면 여기보단 GCP 지원팀에 직접 던지는게 빠를거에요.. .ㅋㅋㅋㅋ;

헐 근데 저도 지금 hello world 하나 만들어서 GCP에서 테스트해봤는데 재현되네요

이건 GCP 지원팀에 물어보는게 좋을듯하네요

TTFB받는데 갑자기 중간에 500ms 늘어나는 케이스가 있네요 10번 요청중에

헛 저도 같은 증상이었는데, 같이 고민해주셔서 감사합니다.

저는 그게 10s까지 가는게 고민이었어요

네... 아마 10s까지 간건 인스턴스 추가할당하는 시간이 맞는 것 같네요

제 코드의 크기에 따라 다르더라구요. 웹팩으로 실험을 좀 했었습니다.

근데... 저로서는 잘 이해가 안되네요. 이러면 너무 일관성을 못지키는 것 같은데

 정 안되면 앱엔진으로 갈아탈까 고민하고 있었어요

이게 AWS Lambda처럼 켜놓을 인스턴스 숫자도 설정하는게 안되네요 콘솔에서는

Serverless로도 제어못하는지 알아보는걸 추천드립니다.

App Engine은 정말 추천드리지 않습니다. (...)

배포하는데 훨씬 오래걸리고... 테스트하기 어려울거에요.

와.. 심지어 GCP cloud function은 concurrency 예약도 안되네요...

<https://cloud.google.com/functions/docs/max-instances>

에고.. 제가 GCP에서 제대로 해본적이 없어서.. 나중에 해결하시면 공유부탁드릴게요!

클라이언트 엔지니어로서는 Optimistic update pattern 을 추천드립니다. ㅋㅋㅋㅋㅋㅋㅋ;

넵 제가 아직 퇴근을 못하고 있어서 응답이 늦었습니다.

optimistic update pattern은 제가 검색을 못하는건지 어떤 내용인지 감이 잘 안잡히네요

<https://story.pxd.co.kr/1193>

이 글이 좋아요

낙관적 업데이트는 일반적으로 클라에서 API 응답이 오지 않더라도 클라에서 선반영 하고 문제가 생기면 나중에 사용자한테 알려주는 UI 패턴이에요.

아 보통 비동기적인 프로세스를 태울때 쓰는 방법이군요

command의 경우엔 좋을 것 같네요

요즘은 널리 쓰이는 인지심리학적 해킹이죠. 사실 UI 자체가 transactional 해야 하는 케이스가 생각보다 없어서 별 문제 안될수도 있고

공유해주신 아티클은 양질의 내용 같네요. 시간내서 읽어보겠습니다

graphql client 는 기본적으로 이 패턴과 stale-while-revaildate를 기본으로 두고 있어서

잘 활용하면 응답 느린게 크게 문제 안될수도 있습니다 (더 유용한데 먼저 시간을 쓰실수도…)

제가 클라개발을 안하고 있어서 조심스럽긴 하네요.

네 뭐 사실 offline capability 같은거 고려하면 레이턴시가 불안정하다 못해 끊기는 경우까지 고려해야되는것도 있긴 해서요

물론 문제해결이 훨씬 복잡해지겠지만 ㅋㅋ

stale-while-revalidate 이라는 키워드도 오늘 얻어갑니다:smile:

복잡해진다기보단 사고방식이 바뀌죠 ㅋㅋㅋㅋ

뭐 앱개발하시는 분들이면 이미 익숙하실수도 있고

오.. 혹시 어떤식으로 래핑하시나요? OpenAPI -&gt; GraphQL Mesh?

스키마가 있는 서버가 아니라면… 화이팅입니다 :sob:

스키마가 없는 서버에서의 최선은 무엇일까요?

스키마가 없으면 스키마 만드는게 젤 빠릅니다

어차피 통합테스트하려면 필요한 것

Django로 되어있어서 화이팅하고 있습니다 ㅋㅋㅋㅋ

Django model + serializer와 원래 쓰고있던 rest api의 response 값을 보고 한땀한땀...

제가 django 는 안써보긴 했는데 그 동네 swagger integration 잘 되어있다고 들었는데요

기작성된 swagger 문서 있으시면 transform 할 수 있을건데

그렇긴한데... json schema가 제대로 선언되어있지 않으면 크게 소용이 없더라구요...

뭐 오히려 잘 됐을 수도 있는데 엔드포인트 모양과 그래프 모양이 항상 일치하지 않아도 됩니다. 이참에 원하는대로 리모델링 해보세요 ㅋㅋ;

ㅋㅋㅋㅋㅋ 제품 이름에 의견이 많은 투자자가 있다거나

?! 해봤는데 띠용하네요 ㅋㅋㅋ 이게 의미가…. 있나요??

전 schema first 를 훠어어얼씬 좋아해서...

코드랑 잘 동기화할 수 있다면 왠지 쓸법도 하다는 생각이 드네요

ㅋㅋㅋㅋㅋ 써보긴했는데… 그냥 또다른 GraphiQL 아닌가요??

궁금해서요… 그거 플랫폼에 붙어있고 따로 풀 계획은 없는거겠죠?

아하 그렇겠죠? ㅋㅋㅋ 에디터가 Monaco 기반이라서 훨씬 좋은 느낌? 이긴해요 ㅋㅋ 저는 잘 안씁니당

패턴적으로 맞는건지는 모르겠지만… 로딩 처리가 컴포넌트 안에서 완전하게 되면 좋을거같다… 라는 생각은 하고 있어요 ㅋㅋ Relay는 useQuery에서만 로딩 처리가 가능하다보니…

이전에는 각 컴포넌트에서 loading 분기쳐서 스켈레톤 보여줬는데요. 그걸 useQuery 아래에서만 하려니까 스타일 코드가 좀 중복되는거 같아요.

Fragment 변경시마다 Codegen 없이 Prisma Client 처럼 스키마 변경때마다 한번 Codegen 돌려놓고 TypeScript로 뚝딱뚝딱 Fragment를 작성하고 싶다… 라는 생각도 있습니다 ㅋㅋ

&gt; Fragment 변경시마다 Codegen 없이 Prisma Client 처럼 스키마 변경때마다 한번 Codegen 돌려놓고 TypeScript로 뚝딱뚝딱 Fragment를 작성하고 싶다…
Reason Relay go brrrr…………. ㅋㅋㅋㅋ

&gt; Relay는 useQuery에서만 로딩 처리가 가능하다보니…
이거 어려운 주제라고 생각합니다.

사실 기존에야 구분할 수 있는 단위가 별로 엎어서 쿼리 렌더러를 많이 분할해서 쓰게 됐는데 preload, normal, deferred, lazy 앞으로 이런식으로 다 구분되서 더 머리아픈것도 사실 ㅋㅋㅋ

제가 지금 다루는 제품은 카드형 위젯을 써서, 각 카드마다로 쿼리 렌더러를 분할하고 있습니다.

쿼리 렌더러가 많아지면, 네트워크 요청이 많아지지않나요? Relay에서 합쳐주나요?

아폴로 씁니다. 아폴로나 릴레이나 안합쳐주는 걸로 알고 있고 따로 debounce 같은걸 붙여서 배치로 처리할 수는 있습니다

그래서 제가 fragment 공격적으로 쓰기 어려웠던 이유를 뽑자면… 아폴로 클라이언트 버그 ㅎㅎ;

&gt; 네트워크 요청이 많아지지않나요?
일단 cache-first 정책을 쓰긴 해서, 많이 커지진 않습니다.

오 Go로 GraphQL 개발 궁금하네요!

<https://gqlgen.com/getting-started/> gqlgen 이라는 툴이 있어서 SDL을 작성해 넣으면 뼈대는 만들어 주고 DB 연동하는 식으로 수련하고 있습니다.
REST API 서버도 안 만들어보고 바로 넘어와서 뇌가 순수한? 상태 입니다. ㅎㅎ

발표신청이 부족해서 ㅠ 밋업을 못열었네요 ㅠ

dgraph 에서 조용히 베타하고 있는 GraphQL BaaS 있어요

오오 아틀라시안 생태계안에 계신건가요?!! 혹시 문서화도 컨플루언스 쓰시나요:eyes::eyes:

그건 좀 파편화되서 컨플런스 반 노션 반 같은 느낌

노션은 integration 이 안되서 개인적으로 안좋아해요

그렇군요ㅜㅜㅋ 저희는 문서는 노션, 이슈 프로젝트 관리는 깃헙으로 했었는데 뭔~~~가 좀 아쉬워서요ㅜㅋㅋ

Securing… 재밌겠네요 ㅋㅋㅋ ㅠㅠ 하지만 요새 일이 너무 많아요 ㅠㅠ

Relay 공부는 정말 값지죠~~ 제가 어쩌다보니 당근마켓 FE 메인 스택으로 정착시켰습니다 ㅎㅎ (클라이언트 스키마 + Relay)

relay 숨은(undocumented) 기능이 참 많아서 또 딥다이브 하는 재미도 있죠 ㅎㅎ….

제가 먼저 도입하고, 다른 분들 도입한다고 하셔서 ㅋㅋㅋ 저는 어렵고 짜증나고 복잡하다고 극구 만류했는데요 ㅋㅋ 그게 오히려 다른 개발자분들한테 있어서 더 하고싶은 마음이 들도록 만든거같아요 ㅋㅋㅋ

<https://mrtnzlml.com/docs/Relay>

꿀 리소스

페이스북 개발팀에서 클라 관련해서 고민한걸 릴레이 공부하면서 흡수할 수 있어서 꿀이에요...!

저희 회사도 도입할까 고려중입니당. 아폴로 -&gt; 릴레이

저희는 서버도 graphql이라 넘나 신나용

저희 relay-hooks 쓰고있는데 그건 쓰지마세요 ㅠ 문제가 좀 있는거같더라구요

우선 스테이블부터 도입하구 훅이 스테이블 되면 점진적으로 도입하려규용~~

거둬낸다는게 그냥 릴레이 모던을 쓰신다는건지 experimental 을 가신다는건지

(왜 reason relay 를 안쓰시는지 :smirk:)

오... 혜성님께서 추천하시니 그것도 한번 봐야겠어용

seamless하진 않아요 ㅎㅎ

• 자잘자잘한 워닝이 왠지 모르게 뜨고 (unmount된 component에 state 변경이 일어남) - 이건 제가 잘못했을수도 ㅋㅋ
• refetch때 callback이 제대로 호출안된다던지
• 에러 object가 문서에는 온다고 되어있는데 안온다던지
하는 문제가 있어요. 이게 구체적으로 체크해본건 아니라서... ㅋㅋㅋㅋ 여튼 이제 프로젝트 시작한다면 저는 안쓸거같아요

페북 오픈소스 특징이라면 특징인데

experimental 태그 붙어있는 녀석들이 실제 페북 프로덕션에서 활발히 쓰이는거에 제일 가깝고

내부에서 수 없이 갈아엎다가 한 2~3년 후에나 정리해서 공식으로 내기때문에

experimental은 브레이크 체인지가 빈번하다구 하셔가지구 쪼끔 많이 두렵네요:scream:

우선 stable이 hoc기반으로 강제성이 더 많은 것 같은 느낌?이라서 stable로 멘탈모델부터 잡고 hook을 좀 보려구 우선 생각줄이에용

서스펜스 없는 릴레이라니 개인적으로 조금 상상이 안된달까

• experimental 유저: 서스펜스 너무 좋은데 페북이 api 를 자꾸 지우고 새로 만들어서 버전 올릴때마다 힘들다
• stable 유저: 나도 서스펜스 써보고 싶지만 꾹참고 2년정도 기다렸는데 아직도 안나왔다.

relay experimental 도 요새 transport 관련 코드 엄청 들어가던데 뭐 나올ㅈ

relay stable버전에서는 `QueryRenderer` api로 페이지 단위 서스펜스를 하는 느낌이었는데 맞나용? relay-hook으로 들어가면서 이것이 component 단위로 서스펜스가 되는 것이 맞을까용?

아뇨 말씀하신건 둘다 서스펜스 안써용 그냥 다른 클라이언트처럼 on error, on loading 상태가 컴포넌트 안에 따로 들어옵니다

서스펜스의 의미를 더 공부해야겠어용~ ㅎㅎ

suspense for data-fetching 이라고 불리는. 다음 버전의 리액트에 있을 핵심 기능 중 하나입니다

<https://ko.reactjs.org/docs/concurrent-mode-suspense.html>

릴레이의 주장에 따르면, relay@experimental 만이 Concurrent React를 out-of-box 로 제공하는 유일한 프레임워크고 페이스북 제품에 의해 battle tested 되고 있다고…

battle tested ㄷㄷ 뽕이 차오르네요

으흠... React에 `Suspense`라는 컴포넌트가 있고 해당 컴포넌트가 child 컴포넌트의 fallback을 기다리는데 relay만이 이 fallback을 `Suspense` 컴포넌트에 전달할 수 있다. 이런걸까요? 어후 짧은시간에 이해하려니 어렵군요

<https://overreacted.io/ko/algebraic-effects-for-the-rest-of-us/>

대수적인 렌더링 모델을 만드는게 큰그림이고

그 반쪽이 훅이고 (비동기 값에 대한) 나머지 반쪽이 서스펜스라고 보시면 될듯

Concurrent mode 의 핵심은 렌더링을 time slicing 해서 병목을 줄이고 우선순위 높은 일들을 먼저 처리할 수 있게 스케줄을 조정하는건데

이게 가능하려면 렌더링 자체가 더 잘게 쪼개지고, 언제든지 “중단” 됐다가 “재개“될 수 있어야함 -&gt; 이걸 위한 api 모델이 훅이랑 서스펜스고 파이버 아키텍처에 의존함 (콜스택을 직접 구현)

개발할 때는 컴포넌트 안쪽에서 비동기 상태 제어를 고민할 필요가 없어져요. 데이터가 “항상” 제공되서 엄청 편해요

주신 링크랑 설명해주신 것을 읽어보니 살짝 감은 옵니다! 제대로 이해하려면 더 공부해야겠지만, 정말 좋은 정보 알아가네용 ㅎㅎ

토이프로젝트로 experimental을 꼭 써봐야할것 같아요

흠 혹시 Relay 컨테이너 React 외에도 잘 구현되어 있나요?

아뇨 릴레이는 리액트 기반 프레임워크입니다

클라이언트 라이브러리가 아니에용

근데 포팅이 있긴 하군요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

<https://github.com/relay-tools/Relay.swift>

<https://wiki.lucashan.space/programming/introduce-a-graphql-to-odc.html>

완전 공감하며 재미있게 읽었어용~~

드디어…. 발표자가…… (감격) (오열)

유튜브에 올라왔습니다.

<https://youtu.be/e5Y7Ruj4glI|https://youtu.be/e5Y7Ruj4glI>

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 충격과 공포다

<https://github.com/APIs-guru/graphql-lodash>

Predictable response format 돌려줘요…. 흑흑

GraphQL 잘 써먹는 조직은 혼자 그 일을 하지 않죠. 현대적인 기술은 결국 커뮤니티 리소스를 어떻게 활용하느냐에 따라서 할 수 있는 일과 쓸 수 있는 기술이 많이 달라지는데, 그걸 적응한 조직과 적응하지 못한 조직의 온도차가 큰 것 같아요.

제가 보기엔 GraphQL이 다루는 주제를 공유하는 곳은 지금 시장에 굉장히 흔해빠졌어요. 문제가 달라서 적합하지 않거나 도구가 충분히 발전하지 못해서 시기상조인게 아니라 도구가 다루는 “철학적인” 부분이 달라진게 문제같아요.

아 사실 GraphQL 이 RESTful 구현의 일종이라고 생각하면 달라진게 없긴한데 (웹 자체에 의존하지 않고 JS에 의존하는 사실 빼고)

네 RESTful 측면에서는 오히려 GraphQL이 잘한 부분도 있다고 생각하는데...

어렵네요 잘 떠오르는 부분이 없군요

이게 조직구조가 백엔드-프론트엔드로 나뉘어 초반에야 다루기 훨씬 편한데 장기적으로는 언어를 바꿔버리기 때문에 좋을게 없다고 생각하구요

이건 스케일 상관없이 시간지나면 문제가 생기는 것 같아요

위에 공유해주셨던 ODK 사례에서도 잘 드러나는 부분이지 않나 싶구요

<https://graphql-korea.slack.com/archives/CN0G9HJAJ/p1598887393028600>

모델이 늘어나면 결국 SDK가 필요하다 -&gt; 언제 다 만드냐 스키마/DSL로 찍자(OpenAPI, Protobuf) -&gt; 동기화 점점 복잡해지는데 어쩌냐/오프라인 지원 한다는데 어쩌냐 (Managed cache layer) 순으로 문제 해결하는건 GraphQL이 아니여도 다 일어나는 수순인 것 같은데,

GraphQL은 꽤 빠른 시점에 저런 부분을 고려하게 만드는 것 도 있고

저도 이걸 하려면 당연히 클라가 요청을 해야 한다고 생각하는데
기존 어프로치를 뒤집어서 얻을 이득을 제시하는게 정말 어려운 일인 것 같아요.
사실 GraphQL을 도입하려면 백엔드쪽에서 고생을 정말 많이 해줄 부분도 있으니까요...

개인적으로 회사에서 서버, 프론트 모두 GraphQL을 써서 정말 좋네용 ㅎㅎ 모두들 만족하며 사용중.... 아 서버쪽에서 페더레이션으로 잠깐 고생하신 것 빼곤...?!

그래서 클라이언트 스키마부터 도입해보고 점진적으로 옮겨가지고 이야기 하든지 ~아니면 제가 서버쪽 기능 하나씩 빼와서 새로 만들든지~ 하는 상상을 하고 있습니다 요샌,,

신규 프로젝트는 아니구 기존 리액트 프로젝트 개발에 참여하게 됐습니닿

기존 스토어가 얼마나 더럽고 복잡하냐에 따라 설득력이 달라지겠네요 ㅋㅋ

살펴보니 GraphQL 이 붙어야 하는 시점은 이미 왔었지만 필요성을 못느꼈고 + 일하기 바빠서 못하지 않았나 싶은 부분들은 있더라구요
• API 응답을 하나하나 인터페이스/타입으로 하거나 아니면 `any`
• 클라이언트에서만 사용되는 필드…를 위해 만든 별도의 `type` (나름의 차선책)
• API 캐싱 없음

graphql 파일 로딩하는 방법은 굉장히 많은데 저 상황이면 바벨 매크로를 권장드립니다.

<https://github.com/evenchange4/graphql.macro|https://github.com/evenchange4/graphql.macro>

Relay는 스토어 인터페이스에서 local state management를 따고 제공하고 있긴합니다.

<https://relay.dev/docs/en/local-state-management|https://relay.dev/docs/en/local-state-management>

사용법은 이쪽에 꽤 자세하게 나와있어요

<https://mrtnzlml.com/docs/relay/local-schema|https://mrtnzlml.com/docs/relay/local-schema>

다른 구현체에선는 예를들면 아폴로에선 schema link를 사용하는 방법하고

URQL 에선 서비스 워커를 사용한 예제를 제공하고 있습니다

<https://github.com/FormidableLabs/urql/blob/main/packages/react-urql/examples/1-getting-started/src/sw/graphql.ts|https://github.com/FormidableLabs/urql/blob/main/packages/react-urql/examples/1-getting-started/src/sw/graphql.ts>

아 릴레이쪽은 저거 말고 서드파티 네트워크 구현도 있네요

<https://github.com/relay-tools/relay-local-schema|https://github.com/relay-tools/relay-local-schema>

근데 구현이 별거없네요 글에 정리하신거랑 똑같은듯 ㅋㅋㅋ

그 커스텀 스키마를 통해 클라이언트 리졸버랑 나머지 리모트 필드들을 동시에 처리하는건 아폴로가 유일했ㄴㄴ데 그 개념을 v3에선 버린거같아서 아쉬워요

퍄퍄.. 언제나 양질의 정보를 나눠주셔서 감사합니다

사실 애초에 클라이언트 사이드 스키마, 그러니까 클라이언트 주도로 스키마를 정의하고 API 응답을 매핑하는 방식이 좋은 방법은 아니라고 생각되어서 제공해주신 링크나 릴레이 문서에 있는 로컬 상태 관리와는 약간 차이가 있는 것 같아요. 그래서 별도로 리졸버를 정의해서 API 응답을 매핑하는건 없는 것 같은데 제가 놓친 부분이 있을까요?

하지만 잘 쓰면 리덕스까지 걷어낼 수 있겠네요 :eyes:

다시 <https://github.com/relay-tools/relay-local-schema|relay-local-schema> 를 살펴보니, 거기서 제공하는 `schema` 부분에 graphql-tools makeExecutableSchema 로 만든 스키마를 넘겨주면 되겠네요..! 그리고 코드를 정말 살펴보니 말씀하신 `구현이 별거 없다` 를 이해했습니다. :zzzz: