https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
This message was deleted.
# 잡담
s
This message was deleted.
t
자동보다는 한땀한땀…
a
오 저는 백엔드는 거의 건드리질 않아서,, 좋은 아이디어라 생각했었는데 협업에선 또 이슈가 있나보군요 ㅎㅎ
t
넵 예를 들면 갑자기 핫픽스를 나가야되는데… 코드 하나만 고치면 되는게 아니라, 로컬에서 `yarn dev`를 해야된다던지 이런게 엄청 어색하더라구요!
그냥 Schema first 면 CI에서 codegen 돌려버리면 어떻게든 될테니까요 ㅋㅋ
Nexus.js 생태계에 모든 팀원이 익숙해져야하는데, 이게 어색…
😔 1
h
사실 어느쪽이던 핫픽스에서 스키마가 깨진는일은 없어야한다고 생각합니다 ㅋㅋ
a
사실 얼마전에 저희 백엔드 쪽에서 nexus 버전 범핑으로 스키마가 변경된 일이 있었는데 프론트엔드 입장에서는 쿼리의 리턴타입이 변경된 경우까지는 type generation 에서 에러가 안나지만 generated type은 모조리 바뀌었기 때문에 typed query 를 쓸 때는 에러가 났었거든요,, 근데 스키마에서 리턴타입의 변경은 일반적 breaking change로 취급하지 않는거 같더라고요 아래와 같은 경우였어요 https://github.com/kamilkisiela/graphql-inspector/discussions/1808
h
음 nullable -> non-null 은 브레이킹이 아니긴 할텐데
저건 브레이킹이 맞는거같은데요
a
앗 그런가요,, 하긴 그때는 인스펙터가 적용이 안되어있어서 감지 못했던거같네요
그래서 하여튼 백엔드측에 migration guide 다 따라달라고 부탁드렸던 기억이
h
공개 API를 다룬다면 스키마가 조금 더 strict 하게 브레이킹을 감지하는게 좋은 것 같은데
공개 API 가 아니라면
클라이언트랑 서버 전부 코드젠 돌려서 타임검사해보면 브레이킹인지 아닌지 나오겠죠 ㅋㅋ
근데 이게 확인하는데 스텝이 많아서 타임검사가 피드백 루프를 길게 늘어트리니까
a
네 결국 프론트엔드에서 브레이킹이 확인되었었어요 ㅋㅋ
h
정적분석으로 대체하려는 것 같아요. 다만 워크플로우가 통합되어있다는 전제하에요
워크플로우가 강제되지 않으면 문제가 말씀해주신것처럼
이미 스키마는 배포되었는데 클라이언트에서 브레이킹이 뒤늦게 감지된다거나 그래서
그리고 사실 PQ 같은거 쓰려면 어차피 통합해야되기도 합니다
a
오 PQ 가 뭔가요??
t
Persisted Queries요 ㅎㅎ
h
Persisted Query 라고, 앱에서 쓰는 쿼리를 AOT 방식으로 미리 파싱해두고 API 쪽에 저장해두고 쓰는 방식이에요
Get 요청으로 쿼리의 해시값만 요청에 보내면
서버는 해시테이블에서 미리 저장된 AST를 보고 응답을 내려줍니다
a
헐....
요청크기를 확 줄이는건가요
h
요청 페이로드 사이즈나 파싱과정을 생략하게되서 필수적으로 권장되는 베스트 프랙티스 중 하나에요
관련발표가 2015년부터 있었습니다.. 페이스북에서는 GraphQL 이렇게 쓴다.. .식으로
t
미리 저장된 AST를 보고
음 이거는 relay에서 지원 안하지 않나요? relay compile --persist-output 하면 그냥
Copy code
{
  [queryHash: string]: string // GraphQL Full Query
}
으로 나오더라구요
a
와우 하나 배워갑니다 키워드는 종종들었는데 뭔지는 이제 알았네용
h
요청 캐시도 엄청 쉬워지죠
음 이거는 relay에서 지원 안하지 않나요? relay compile --persist-output 하면 그냥
페북에선 DB에 넣는다고 들었던거 같은데.. 어차피 그냥 JSON 형태라 어디넣을지는 자유롭지 않나요
보통은 APQ 같은건 그냥 LRU에 넣긴하지만
t
물론 graphql-jit으로 한번 말아서… 저희 내부적으로는 그게 그거긴해요 ㅎㅎ
저희는 MongoDB에 저장해요. 근데, output으로 AST가 나오진 않더라구요. 그냥 풀 쿼리가 나와요
옵션이 있나요??
h
어쨋든 이런식으로 프리컴파일을 안해주면 GraphQL 런타임이 굉장히 cpu intensive 하게 돌아서 너무 느린거 아니냐는 오해를 받을수있어요
그냥 introspection 하면 될것 같은데
잠시만요
t
어쨋든 이런식으로 프리컴파일을 안해주면 GraphQL 런타임이 굉장히 cpu intensive 하게 돌아서 너무 느린거 아니냐는 오해를 받을수있어요
실화입니다. Node.js 경우에는 갑자기 요청 몰리면 (외부의 워커등에 의해서) 레이턴시 2s-3s씩 툭툭 튀어요
h
import { buildClientSchema, getIntrospectionQuery } from ‘graphql’
API 이거 맞나
get introspection 따로 할 필요 없겠네요 그냥 스키마 객체 만들어서 JSON으로 시리얼라이즈 하면 될듯
import { introspectionFromSchema } from 'graphql'
이거네요
아 스키마가 아니라 document node 군요
t
그쵸그쵸 ㅋㅋ
upload때 parse 때리면 될듯.
h
그래서 결국 요청 형태가 
GET /graphql?query=${hash}
식으로 바뀌게 되면 엔드포인트에 따라 응답을 CDN에 올리거나 해도 됩니다 ㅋㅋ
t
오 생각해보니 
GET /graphql/${hash}
형태로 바꾸면 쿼리 별로 Datadog에서 퍼포먼스 모니터링 하기도 더 쉽겠네요.
Open in Slack
PreviousNext
Powered by