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

GraphQL Korea

오... 클라에서 리졸버 함수를 사용 할 일이 있나요??

적극적으로 쓴다면야 많이 있죠

<https://docs.google.com/presentation/d/1XQWrYrz8wr8DzXV4e8Ffhhb9pjrAu8BXq2xrNdE1pW4/edit?usp=sharing>

홍진호님 발표자료입니다 ㅎㅎ 한승호님 발표자료는 아직 안올라왔어요

타입 에러 아닌가요?? TypeGraphQL을 써보진 않았지만, Schema를 토대로 Resolver의 return 타입을 체크하는거같아요

프로젝트를 새로 파서 코드 고대로 가져다가 적용하니 돌아갑니다 :eyes:
diff 떠서 확인해보고자 했으나 이유를 알 수가 없네요…

Nexus 쓰시면, `typegenAutoConfig`로 리졸버 별 `parent`에 자동으로 타입 주입 해줄 수 있어요.

감사합니다!
typescript을 기본인걸로 개발된게 많아서 골라쓰는 재미가있네요 ㅋㅋ

left join은 dataloader사용했고
innerjoin은 상황에 따라 다르게 했습니다.

일반적인 구조라면 inner join은 1:1일테니 스키마 구조에따라 다르게 설계했습니다.
맞는 방법인지는 모르겠네요.

dataloader 반드시 사용하셔야해요~

mutation 내에 필드로 추가하시면 될거같아요 ㅋㅋ


```type Mutation {
  updateReservation(where: UpdateReservationWhereInput!, data: UpdateReservationDataInput!): Reservation!
  # 또는
  updateReservationStatus(where: UpdateReservationStatusWhereInput!, status: ReservationStatus!): Reservation!
}```

같은 느낌으로 할거같아요

저라면 (REST더라도) 상태 변경을 프론트엔드에서 결정해서 PUT 하게 만들지는 않을 것 같습니다.

1. 음, <@UN0GLRW14> 님 좀더 자세히 설명해주실수 있을까요?
2. <@UN4AJARCN> 님 왜인지 여쭤봐도 될까요? :eyes: 

```mutation {
  updateReservationStatus(where: { id: "1249" }, status: Pending) {
    id
    status
  }
}```


단순한 상태값이 아니라 비즈니스 로직이기 때문입니다.

대충 상상해봐도 예약완료,예약대기,결제 트랜지션에 필요한 필드들이 다 다를텐데 그럼 그에 맞춰서 타입을 추상화하고 뮤테이션도 다 쪼개는게 좋다는 생각이에요

저도 혜성님 말씀에 동의해요 ㅎㅎ

다만 현실세계는 언제나 아름답지는 않으니 ㅠㅠ 어떻게 더 자세히 설명해드릴까요?

REST 는 이러면 엔드포인트가 무진장 쪼개져서 안하는데 GraphQL  로 풀면 쉬워지죠.

~다만 예제를 쓰려면 무슨 도메인인지 힌트를 주시면 좋을듯한데..~ “예약” 인가요

대략 이럴거같은데

```type Reservation {
  id: ID!
  status: ReservationStatus;
}

input RegisterInput {
  ...
}

type RegisterOutput {
  reservation: Reservation!
}

input PurchaseInput {
  reservationId: String!
}

type PurchaseOutput {
  reservation: Reservation!
}

type Mutation {
  register(input: RegisterInput!): RegisterOutput!
  purchase(input: PurchaseInput!): PuchaseOutput!
}

mutation {
  purchase(input: { reservationId: ... }) {
    reservation {
      id
      status
    }
  }
}```

결제처럼 Reservation 상태에 따라 로직이 많이 다르면 status 필드보단 interface or union 으로 다형성 구현하는게 낫습니다.


```query ReservationInfo($id: ID!) {
  reservation(id: $id) {
    id
    memo
    ...on NeedPurchase {
      # 결제 관련 정보 격리
      ...PurchaseInformation
    }
  }
}```

음.. 사실은 그냥 예를 들다보니 생각난게 예약이어서 대충 적은것이었습니다.. 죄송합니다.. :eyes:

그러나 도움이 많이 되었습니다. 감사합니다

연습삼아 프로젝트하나 해보려고하는데

GraphQL쪽은 serverless like한 solution이 이 FaunaDB 아니면

AppSync는 작년에 잠깐 만져본기억이있는데 너무 구려서 바로 버렸던

ㅋㅋㅋ 저는 그동안 서버리스 굉장히 하드하게쓰다가

현타와서... 도커 환경으로 다시 돌아왔어요

서버리스에서 어떤 현타를느끼셨나요? 궁금하네요

저는 zeit now 굉장히 잘쓰고있어서

ㅋㅋㅋ  Production에서 성능 최적화시키기가 까다로워서요. DB Connection 이슈랑 ㅠㅠ 저는 Lambda 주로 사용했었어요

아하 성능최적화라하면.. AWS Lambda같은 서비스들이 어떤부분에서 성능병목이발생하는건가요?

ㅋㅋㅋㅋㅋ 흠... 성능이 빠르다/느리다라는게 되게 서비스마다 다를텐데, 저는 얼마전부터 무조건 80ms 안으로 끊는걸 목표로 하고있어요

아무래도 인프라 레이어가 다 추상화되어있다보니까요 ㅠ 인스턴스 레벨 올리고싶어도 못하고, 그냥 코드 최적화만 간신히 하는정도가 되어서

제가 서버리스를 잘 못쓰는거일수도 있어요 ㅋㅋ

저도 FaunaDB 사례가 궁금해요~~ 서버리스 원하시면 Prisma Cloud도 있지 않나요??

Cloud쪽은 대시보드도 괜찮고 잘만들었는데

GraphQL의 확장?이라는 느낌이들어서

ㅋㅋㅋㅋ 그쵸 애초에 graphql backend를 지향하는 제품이 아닌거같아요

Lock-in 이 좀 심한느낌이라고해야하나

그냥 프론트엔드에서 GraphQL을 사용하게하기위해서

백엔드쪽은 우리가 DB가뭐든 레이어하나로 다추상화해주겟다

FaunaDB는 레퍼런스가없네요 ㅋㅋㅋ

<https://github.com/netlify/netlify-faunadb-example>

오 .. 감사합니다 Netlify에서 FaunaDB를 Addon형태로 지원하는군요

그냥 netlify functions 라는 aws lambda 사용하는 서비스가 있고 faunadb 활용하는 예제에요

<https://docs.netlify.com/partner-add-ons/get-started/#add-on-providers>

주신링크에 README에 애드온처럼 되어있는데

FaunaDB를 애드온 커맨드로설치하길래
저런건 처음봐서.. ㅋㅋ

근데 addon 이래 봐야 별 다를건 없네요 그냥 integration preset

환경변수 설정 이런것들해주는거군요

FQL(Fauna Query Language)라는 이름을 붙여서 Prisma처럼 자체 클라이언트를 제공하는군요..

네 어차피 클라우드 DB 라고 서버 안거치고 바로 쓸 수 있는 케이스는 한정적일것이라

FaunaDB 테스트한번해봤어요.
zeit now랑 비슷하게 백엔드에선 cloud big3 쓰면서 serverless 를 지향하는거같은데
아직 제일가까운 region이 싱가폴밖에없네요
query 기준 평균 300ms 정도..
사용하기는 굉장히 쉬웠습니다
그냥 Create DB하면 바로 GraphQL 서버하나 생기는..
무료플랜도 data transfer 빼고는 나쁘지않아서 간단한 테스트해보기는 괜찮은거같아요 ㅎㅎ
<https://fauna.com/blog/announcing-new-global-regions-for-faunadb-south-america-and-asia>

이번 소모임 주제였는데 ㅎㅎ 자료 공유해드릴께요

<https://docs.google.com/presentation/d/1JOAOhsJ0CBra-qMfrqao6DsNgtuxJz0CRHl36Y0hYBc/edit?usp=sharing>

결론은 DataLoader로는 힘들고... Hasura 같은 엔진을 쓰면 편하다 였습니다 ㅋㅋ

오오 감사합니다 이번 소모임에 Hasura, Prisma, Postgraphile 관련도 너무 듣고싶었는데 ㅠㅠ 혹시 소모임에서 했던 발표 자료가 더 있을까요??

뭐 다른 종류의 엔지니어링 이슈가 나오겠지만 인메모리 캐시를 쓰는게 더 나을 것 같네요. (프리즈마랑 동일한 접근)

발표자님 호출드렸는데 ㅠㅠ 늦으시네요...

<@UN0GLRW14> 핸드폰으로 답변  쓰다 길어져서 컴퓨터로 이동했습니다 ㅎㅎ Notification 감사해요 :)

<@UQKT4NCJ1>
먼저 정확하고 깊이 있는 답변을 해주셔서 감사드립니다.
각 서비스들의 기본 설명들을 해석하면서 공부했지만, 언어적 차이 때문에 모호하게 이해했던 점을 확실하게 잡을 수 있었습니다. 감사합니다 :heart_eyes:

[prisma2]
1. 기존 Prisma와 같이 db schema와 resolve 생성 및 관리
=> prisma2에서 소개하는 3가지 서비스에 대해서 서로 통합 또는 연동에 대해서 어느정도 가능한지와 퀄리티는 어떤지 확인을 해야겠다는 생각이 드는 답변이였습니다.
독립적으로 지원하는것에 장점은 확실하게 있으나, 나눠진만큼 앞으로의 업데이트를 통해 '어쩔수없는' 연동 불가가 생길 수 있으니깐요.

2. 요청된 Graphql Query에 맞게 db쿼리 재조합 및 1:N관계의 쿼리 요청 최적화
=> 설명해주신대로는 진짜 꿈같은 이야기입니다 ㅎㅎ 하나의 큰 서비스는 단일 DB로는 불가능한게 현실이도 서로 통합한다는 것 자체가 이슈 덩어리에 개발요소가 들어갈수밖에 없는 요소인데 이걸 해결해준다는 것에 감격할 수 밖에없네요.
말씀해주신 Photon의 행보를 추척해 나아가겠습니다.

3. 개발되는 서비스 API 서버안에서 Graphql 관련해서 사용되는 느낌.
=> 답변 해주신거에 hasura와 차이점을 통해 아키텍처 구상에 도움이 되었습니다. 감사합니다.

[Hasura]
1. 요청된 Graphql Query에 맞게 db쿼리 재조합 및 1:N관계의 쿼리 요청 최적화
=> 최적화에 너무나도 맘에 들고 Main이됬든 Sub가 됬든 하나의 독립적인 서비스를 위한 선택에 대해서는 과감하게 선택할만 한 것 같습니다 ㅎㅎ...   (private성 강하게 하려면 Docker로 해야되는것만 빼면...)

2. 개발되는 서비스 API 서버와 별개로 backend, frontend 상관없이 최적의 Query로 data 사용(read,write)을 할 수 있는 서버, 그 외 서비스적 처리(알림전송, 정산금액계산등...)는 microservices단위 개발이 더 효율적
=>설명해주신 6가지의 지원 기능에 대해서 설명해주셔서 감사드립니다. 좀 더 명확한 아키텍터 구상에 도움이 됩니다 ㅠㅠ
제가 serverless 또는 microservies 단위 개발로 넘어가지 못한 이유가 '솔로'개발이기 때문에 개발효율 면에서 큰 이득 을 못가진점을 가장 크게 가졌었는데...
코드의 신뢰성, 데이터의 신뢰성을 어느정도 보장해줄 수 있는 기능이라고 생각되기에 충분한 검토를 해야되겠다는 생각이 드는 설명이였습니다.

다시 한번 질좋은 답변에 감사드립니다. :grinning:

당연히 요구사항에 따라 다르겠지만, 데이터 소스가 분산되는건 엄청 일반적인 유즈케이스니 별로 걱정하실 필요 없을 것 같습니다.

<https://medium.com/brikl-engineering/graphql-schema-directives-as-orm-ec635fdc942d>

맘편해지시라고 아주 극단적인 케이스 올려드려요 ㅋㅋ

데이터 소스가 분산된다는게 client에서 하나의 쿼리 호출 시 resolver 에서 여러 데이터들을 분산해서 조회한다는 뜻인가요?

분산된 스키마를 클라이언트에서 하나로 합쳐서 요청할 수도, 합쳐주는 서버가 있을 수도, 애초에 스키마는 하나로 스토어만 나뉘어 있을 수도 있습니다. 그때그때 필요에 맞는 선택을 하되 최종 클라이언트에서 하나의 엔드포인트(데이터그래프) 를 보게끔만 하면 됩니다.

apollo federation 같은 주제는 microservice 식 접근이라 현재 구현이 monolith 하다면 별로 신경쓸 주제가 아니긴 합니다.

다만 리졸버 구현 디테일 수준에서 참조하는 서비스가 많을 수록 monolith 서비스의 장애 확률은 커지기에.. 적어도 폴백을 포함한 아키텍처를 구성하는 것을 권장드립니다.

아 좀 더 찾아볼껄 그랬네요… 해답까진 아니고.. 해결방안을 찾았습니다..

Webpack Uglify 문제인거같네요 ㅋㅋㅋ 맞죠??

흠... 보통 저는 prisma-nexus를 써서요 ㅋㅋㅋ 원하는 답을 얻으실수있을지 걱정이네요 ㅠ 나중에 공유해주세요~~ ㅎㅎ

Nexus를 지금 검토해봐야겠네요ㅋㅋ
넣는다 넣는다... 하기만했는데ㅋㅋ

말씀하시는게 `GraphQLResolveInfo` 를 파싱해서 client 가 요청한 subselection 을 알아내시려는 건가요?
예를 들면
```  myResolver: (_, _, _, info ) =&gt; {
    const subselection = library(info)
    // 이후 subselection 을 (편집 후 prisma에) 사용
  }```
이런 거라면
<https://github.com/robrichard/graphql-fields>
또는
<https://github.com/Mikhus/graphql-fields-list>
한번 살펴보시면 어떨까 합니다.

*robrichard/graphql-fields* 의 예를 들면,
좌측이 query 라고 가정할 때,
`posts` resolver에서 사용하면 중간과 같은 json 을 얻을 수 있고,
`author` resolver에서 사용하면 우측과 같은 json 을 얻을 수 있습니다.

여담으로, 저는 개인적으로 처음 이걸 알아보게 된 계기가 이전에 <@UNZ83BVGF> 님께서도 이 채널에 질문하신 _"필요한 것만 dynamic 하게 database query 를 요청"_ 하기 위함이었습니다.
`GraphQLResolveInfo`  가 문서화되지 않아서(오직 코드: <https://github.com/graphql/graphql-js/blob/c82ff68f52722c20f10da69c9e50a030a1f218ae/src/type/definition.js#L489-L500>) 디버깅으로 구조를 분류했고, 이후 라이브러리를 찾았습니다.

문제는
1. (field blacklisting, mapping 등으로) 매번 resolver 마다 작업하는 것이 번거롭고(특히 스키마 변경이 있을 때), 
2. dataloader 의 key 에도 field 정보를 포함시켜야 해서, 같은 데이터(RDB로 치면 같은 row)라도 사실상 key 가 겹치는 일이 적어 cache의 효용도 적어진다. (dataloader 작성이 좀 더 번거로워지는 것도 포함입니다.)
는 것입니다.

그래서
1. field 의 수가 많거나 큰 타입(긴 TEXT 등)의 field 가 있는 경우, 
2. schema type과 datamodel의 불일치를 어떤 이유던 resolver 레벨에서 해결하는데 필요한 경우, 
3. 또는 해당 정보가 필요한 특수한 경우 
등에만 사용하는게 좋겠다고 생각하고 있었습니다.

개인적인 경험과 생각을 적다보니 길어지네요. 질문의 요지를 이해하고 도움을 드린 게 맞으면 좋겠습니다.

<@UQKT4NCJ1> 저번에도 그렇고 계속 도움을 받네요 ㅋㅋㅋ
field관련 모듈을 싹다 찾아서 확인했는데
딱 입맛에 맞는게 없더라구요.
다시 prisma에 사용하기 위해 gql형식으로 주는게 없나 했는데... 없기에 만들 생각을 하다가 너무 비효율적일것같고...

 GraphQLResolveInfo를 가공을 해야되는 조건이 필요한 부분은 아에 다른 query로 만들어서 요청하는걸로 자체적으로 합의봤습니다 ㅋㅋ

혹시 어떤 라이브러리들이 있나요?? Java 생태계는 몰라서요 ㅠ

<https://github.com/graphql-java-kickstart/graphql-spring-boot> 뭐 이런 게 있긴하던데.. 어휴 어떻게 해야될 지 모르겠네요 ㅋㅋ ㅠ_ㅠ

저도 Java + GraphQL 국내 사례는 본 적이 없어서요 ㅎㅎ 직접 삽질을 해보셔야... 할 것 같네요 ㅋㅋㅋ 만약에 진행하시게 되면 나중에 공유 부탁드려요 ㅎㅎ

넵 열심히해보겠습니다 ㅠ 감사합니다

생각해보니 JS 진영에서는 TypeGraphQL 많이 사용하는데 비슷하게 Java 진영에도 있을거같긴하네요 ㅋㅋ

일단은 아래의 링크를 통해 이것저것 보고는 있는데 뭔가 정리가 되지 않은 느낌이네요..ㅎㅎ
<https://medium.com/@lvdbrink/graphql-meets-protocol-buffers-in-go-cdbf11090934>

주로 grpc 마이크로서비스 백단 쓰면서 클라와 맞닫는 부분을 GraphQL로 작성하는걸로 알고있어요

그래서 제가 아는 회사는 클라 개발자가 자기가 쓸 GraphQL 서버를 노드로 짜고있다고 들었습니다 ㅎㅎ

Domain model 을 하나의 proto 파일로 관리한다기보다 아예 분리를 해서 따로 사용하는 경우인 것 같네요 :eyes:

Schema first 형태로 GraphQL 서버를 운영한다면.. proto 파일로 도메인 명세를 주고받는 것도 가능하려나요..
뭔가 제겐 아직 추상적이라 먼저 해보신분 계시다면 사례를 알고싶었습니다. 답변 감사합니다 :pray:

`.proto` → `.graphql` 변환이 가능한지? 를 여쭤보는건가요??

해당 변환은 아래 내용들을 보면 가능할 것 같더라구요
<https://github.com/google/rejoiner>
<https://github.com/danielvladco/go-proto-gql>

실제 Real world 에서 gRPC/GraphQL 을 함께 사용하는데에 있어 아이디어나 실제 사례가 있는지 궁금해서 여쭤봤습니다.ㅎㅎ

`.proto` -&gt; `.graphql` 로 변환해서 Schema first 형태로 사용할수도 있지 않을까? 라는건 제 개인적인 아이디어였습니다.ㅎㅎ

다만 해당 아이디어가 얼만큼 현실성 있는지 등등에 대해 궁금하네요 :pray:
아니면 다른분들이 갖고계신 아이디어가 있으시다면 공유받고 싶구용

저라면, protobuf.js + TypeScript 이용해서 해당 도메인 모델의 타입을 Generating 한 뒤에 Nexus.js에 있는 typegen 기능 이용할거같습니다!

GraphQL은 Muti Data Source를 처리하는데 좋다고 생각되서요. (GRPC로 받아온 데이터와 Redis의 캐시를 조합하는 등) 추후에 다른 Data Source로의 확장성 위해 조금 번거롭더라도 GraphQL 스키마와 Protobuf 스키마는 분리해서 만들거같아요.

예를 들면 원래 하나의 GRPC 서버가 두개로 분리된다던지 할 때를 위해서요 ㅎㅎ 고통스럽긴 마찬가지겠지만... 조금이라도 고통을 덜기위해 ㅋㅋ

저도 위 의견 동의합니다. gRPC ㄱㅏ 메인인 서버에서 리액트 앱 쪽을 위해 엔드포인트를 하나 더 만들 필요는 없을 것 같고

클라이언트에서 gRPC 클라이언트를 GraphQL 스키마로 래핑하는 정도면 될 것 같네요

만약 서버쪽에서 같은 proto 파일을 모델로 둘 모두 서빙하게 하고싶다면 gRPC/GraphQL 를 이중으로 작업해야하는 구조겠군요 :eyes:

서버쪽에서 래핑해서 한번에 작업하는 방법은 없을지도 궁금하긴 하네요..ㅎㅎ

GraphQL이 특징적이라면 스키마를 데이터레이어의 어느쪽이 소유해도 이상하지 않다는 거니까요

래핑을 서버에서 해도 되겠지만

&gt;  해당 내용을 GraphQL 과 엮어 React 에서 사용하게 할 수 없을까.. 하는 고민 중입니다.
라고 하셨으니 필요한 클라이언트가 역할을 가져가고, 다른 클라이언트랑 공유해야 할 때 서비스로 추출해도 되지 않을까 해요

답이 늦었습니다 :bow:
전 Toy 프로젝트 정도로만 리액트를 다루는 서버개발자인데요, 저희쪽 프론트분들께 GraphQL 을 사용하게끔 해드리고 싶어서 시작한 고민이다보니.. 만약 하게되면 서버쪽에서 제공해주는 걸로 한번 고민해보려합니다. ㅎㅎ

<https://blog.apollographql.com/modularizing-your-graphql-schema-code-d7f71d5ed5f2>

서버에 웹팩을 쓰신다면,

<https://github.com/prisma-labs/graphql-import-loader>

이런 솔루션도 있긴한데요. 버그가 많아서 비추합니다~

<https://github.com/ardatan/graphql-import> 도 있습니다. .graphql 파일(또는 임의의 확장자)에 SDL 을 바로 쓰고, 주석으로 파일간 import 를  하는 방식입니다. 최종적으로 소스코드에서는 가장 상위의 .graphql 파일 하나만 읽는 것처럼 사용할 수 있어요.

엇 이번 1월 모임 발표 주제였는데요, 오늘 자료 올려드릴께요 ㅎㅎ

저는 보통 전체를 가져오구요. 추후에 최적화 니즈가 있을때 info 필드로 최적화하는거 같아요.

Apollo Engine으로 계속 모니터링해요 ㅎㅎ

Schema Convention이요 ㅎㅎ 스키마 바꾸려고하면 골치아픕니다 ㅋㅋㅋ

Schema Convention 이라하면 주로 네이밍 컨벤션을 말씀하시는건가요??

네네~ 그리고 Input type을 어떻게 쪼개는지 같은것두요.

GraphQL 안 좋다고 하시는분들 대부분이 스키마 변경에 대한 경험이 너무 안 좋아서거든요. (왜 맨날 바뀌냐, 뭘 바꾼거냐) 처음에 스키마 컨벤션을 안 잡고 서버 개발을 하면서 계속 바꾸는 경우가 있는데 그러면 클라분들이 고통받아합니다...

처음에 네이밍 컨벤션 잘 잡고, Apollo Engine의 Schema Check를 CI에 포함해서 적극적으로 활용하시면 좋을거같아요

그리고 저는 추후에 떼어내기 쉽도록 파일 구조를 잡을때 GraphQL Layer랑 Data Layer (ORM) 분리를 철저하게 하는 편인데요. (지금은 Nexus + TypeORM 사용해요) 만약, TypeORM + TypeGraphQL 조합으로 한 Class 내에서 같이 만들면 추후에 RDMBS를 다른 REST?, gRPC 서비스로 떼어내기가 힘들거 같긴 합니다.

근데 이건 취향차이라서~

오호 너무너무 감사합니다. `InputType 을 어떻게 쪼개는지` 는 주로 어떤 기준으로 쪼개시나요? mutation 하나하나 기준으로 하나요?

저는 `where`, `data` 쌍을 써요 ㅎㅎ
```type Query {
  user(where: UserWhereInput!): User
}

type Mutation {
  createUser(data: CreateUserDataInput!): User!
  updateUser(where: UpdateUserWhereInput!, data: UpdateUserDataInput!): User!
  deleteUser(where: DeleteUserWhereInput!): User!
}```


공통되는 부분을 빼도 괜찮은데 추후에 InputType이 추가될때 확장성이 별로더라구요.

제가 AWS 커뮤니티데이 발표때문에 미처 못올렸네요 ㅋㅋ 내일이나 내일 모레즈음 올리도록 할게요~

저는 Go는 안해봤는데요, gqlgen이 짱짱이라는 말만 들어봤어요 ㅋㅋ

gqlgen - codegen 기반, graphql-go 는 rtti 기반입니다

&gt;  graphql-go 는 rtti 기반입니다
아무래도 그러다보니 예전에 써볼 때 요딴 이슈가 있었는데 -&gt;
<https://github.com/graphql-go/graphql/issues/134>

놀랍게도 아직 오픈이군요 ㄷ;

CLI라함은 어떤걸 의미하시는건가요?? ㅎㅎ

아 create-react-app 처럼 폴더구조나 기본적인 라이브러리같은걸 설치해주는…? 그런거요ㅠㅠ

<https://github.com/prisma-labs/graphql-yoga> 이건 어떠신가요 README에 보면 `graphql-yoga is like create-react-app for building GraphQL servers.` 라고 하네요 ㅎ

사족이지만 Prisma 팀 개발 리소스 너무 분산돼서 이것도 업데이트 뜸해졌군요. Yoga 2 는… 안습 ㅠㅠ <https://github.com/prisma-labs/yoga2>

Yoga2도있었군여... 어쩐지 업뎃이 너무 안되는거 같았는데...

이제 신경 안써도 될 것 같습니다

아무래도 사전에 디자인 협의를 통해서 나온 부분이 아니면 자연스럽게 그렇게 되는 듯 합니다. (특히 ORM 쓰는 경우가 좀;)

저는 프론트엔드에서 사용하면서 스키마 구조 다시 잡고 이 후 백엔드로 다시 로직 마이그레이션 하고 불필요한 스키마 Deprecated 시키는 수순으로 진행하고 있어요.

방법론적으로는 괜찮다고 생각하는데 apollo client 버그가 좀 많아서 ㅎㅎ; 권장할만한 방법은 아니네요

네 특히 type-graphql 이랑 typeorm 사용하니까 더 그런거같기도 합니다 ㅎㅎ
Tony 님께서 nexus 의 장점으로 db model 단이랑 Graphql 이 완전 분리된 레이어로 구성된다고 한 점도 비슷한 맥락인거같네요.

저 스레드에서 urigo 가 엄청 좋은 요약을 해줬죠

&gt; GraphQL schema a simple aggregation of all your backend services...

넵 ㅋㅋㅋ 저도 비슷한 형태로 가는건 어쩔수 없는데, 분리되어 있어야한다고 생각해요. 그래서 Nexus 사용하고 있어요. RDBMS만 쓰면 사실 문제가 아닌데, RDBMS랑 gRPC 서비스, REST 서비스를 섞어서 쓰기 시작하면 문제가 시작되지 않을까요?

지금 저는 다 짬뽕해서 GraphQL 서비스를 만들고 있는 입장이라서 ㅋㅋㅋ

그러지 않아도 문제가 되죠. 추상화 없는 DB Entity 모델은 갖다 쓰기 썩 좋은 모양이 아니라서 ㅋㅋ

백엔드에서 호다닥 스키마 추가하면 항상 그대로 안쓰고 다시 클라이언트 스키마로 말아서 쓰게 되는데, 이건 RESTful API 쓸 때도 마찬가지였고, GraphQL 도입한 이점을 잘 못살리는 일이라고 생각되네요.

저는 커밋해요 ㅎㅎ PR 리뷰할때 좋더라구요.

오호 넵 공유해주셔서 감사합니다 ㅎㅎ

저는 충돌 때문에 ignore에 추가합니다

apollo-android를 사용하시는건가요??

apollo-android에서 해당 에러를 throw 해주지 않는건가요??

Throw한 Error에는 http Exception 관련 내용들이 가득하네요.

흠... React Apollo 웹 클라이언트는 보통 loading, error, data 같은 값들을 같이 주는데요. Android도 비슷할거같아요

흠… React는 loading처리도 지원하는군요 ㅠ

공식 문서들도 많이 읽어봤는데… 오류처리부분이 없는것같기도 해요.. 제가 못찾는걸수도 있지만..ㅠ

<https://www.apollographql.com/docs/android/essentials/queries/|https://www.apollographql.com/docs/android/essentials/queries/>

호오.. 리액티브 프로그래밍 하려다보니 그랬네요.. 한번 확인해보겠습니다 !

음 그냥 현상 그대로 400을 받은 것 같네요. graphql 미들웨어 앞단에 다른 녀석들 걸릴게 없는지 확인해보세요

<@UN4AJARCN> 서버에서는 성공(Status:200) 또는 오류(Status:400)으로 처리하고, 자세한 오류내용은 위 PostMan처럼 errors에 넣어서 보내줍니다ㅠ Token만료에 대한 처리를 하려고 하니.. 쉽지가 않네요.

?? GraphQL은 실패도 200으로 처리해야해요

<@UN0GLRW14> 지속적인 도움을 주셔서 대단히 감사드립니당ㅠ
서버는 제 친구가 작성했는데 Node.js로 짰다고 합니다..!

넵 ㅋㅋㅋ GraphQL HTTP 서버는 성공이든 실패든 200을 줘야하구요. 서버에서 400이 날아오니 Apollo 클라이언트에서는 GraphQL 오류가 아니라 뭔지 모를 서버 오류로 판단하고 메시지를 출력하는거같아요 ㅎㅎ

<@UN0GLRW14> 그럼 오류발생시 포스트맨 오른쪽 상단 Status에도 StatusCoderk 200으로 떠야하는건가요??

아마 apollo-server-express를 사용하시면서 서버 내에 res.status(400)을 하시는거같은데, 그부분만 삭제해보세요 ㅎㅎ

<@UN0GLRW14> 허허허… 친구한테 바로 전화해봐야겠습니다 ..ㅋㅋ 혹, Apollo나, GraphQL에서 자체적으로 status코드를 400으로 보내주는..? 경우는 없는지요 ??

<@UN0GLRW14> 하하하 너무감사드립니다ㅋㅋㅋ 오늘로 4일째인 삽질이… 서버쪽 문제였군요. 너무감사드립니다ㅠㅠㅠ

자체적으로 Error Handling을 하고있어서, GraphQL 구현체 내부에서 throw Error하게되면 무조건 GraphQL이 Catch해서 200으로 떨어집니다. 이런거때문에 에러핸들링하는게 조금 달라요 ㅋㅋ 저도 Sentry 잡느라 고생중입니다

<@UN0GLRW14> 아.. 그렇군요ㅠㅠ 너무감사드립니다.
아, 혹시 Github V4 Api(GraphQL API)에서는 토큰 문제시, Status를 401로 보내주는데.. 토큰관련 오류처리는 github처럼 status로 오류를 처리하는게 옳은걸까요?

인증 관련 로직이 미들웨어에 들어있냐 GraphQL 프레임워크 내부에 들어있냐의 차이일거같아요. 지금 발생하신 오류는 GraphQL 프레임워크 내부의 Context를 만들때 발생한 에러라 200을 내는게 맞다고 생각하구요. 만약에 미들웨어에 들어있는 로직이라면, statusCode를 사용해도 될거같아요 ㅎㅎ 그런 의미에서 둘 다 가능하니, Apollo Android에서 처리하는게 곤란하면 다 200으로 떨어뜨리시죠~

엔지니어링에 100% 옳은건 없다고 생각해요 ㅎㅎ 더 나은 방법이 있을텐데, 상황마다 다르니까 그때그때 여기에 여쭤보시면서 직접 결정하시면 됩니다!

그나저나 고등학생인데, 대단하세요~~

<@UN0GLRW14> 오호… 그렇군요. 사실 질문 적을 때 옳다 ? 라는 표현을 써도 될지 잠깐 생각했었는데 적절한 단어가 생각이 딱히 떠오르지 않았네요~ 이런저런 좋은 말씀들 얻을 수 있는 좋은 커뮤니티를 찾아서 기쁩니다~ㅋㅋ  나중에 기회가 된다면 오프라인 밋업에서 뵐수 있었으면 좋겠네요!!

아직 갈길이 멀었다고 생각합니다 :smile: 대단하게 봐주신다니 감사할 따름이네요~ 오늘 오후도 화이팅하시길 바래요~~

셀프 답변: graphql-middleware로 sentry middleware가 있네요.

<https://www.apollographql.com/docs/react/data/fragments/>

mutation 의 경우 list addition/deletion 에 대한 커밋(updater)은 따로 구현해줘야 하지만 나머지 경우는 ID 가 잘 있으면 정상적으로 캐시를 업데이트 합니다.

뷰 일관성을 지키려면 업데이트 하고 싶은 정보를 뮤테이션 응답에 정확히 표현하는게 중요한데요.

그 때 component colocation 패턴이 유용합니다.

colocation 이란 컴포넌트와 컴포넌트가 의존하는 데이터 프래그먼트를 같이 배치하는 패턴으로 relay 에서는 fragment container 로 1st party 로 제공하는 패턴입니다.

```const MyPosts = ({ me, posts }) =&gt; React.Element;

fragment MyPosts_me on Query { ... }
fragment MyPosts_posts on User {
  posts {
    # MyPosts 가 의존하는 데이터를 다시 명시
    ...PostCard_post
  }
}```
이런식으로 colocation 을 사용하면 컴포넌트와 의존성 데이터의 컴포지션을 항상 일치시킬 수 있어서 “선언적 데이터 패칭” 이 가능합니다.

그러면 나머진 자연스럽게

```mutation publishPost(...) {
  author {
    ...MyPosts_posts
  }
  post {
    ...PostCard_post
  }
}```
요렇게 뮤테이션에 의해 실제로 변경을 전파하고 싶은 구성요소(컴포넌트, 데이터 의존성 모두 표현함)를 선언함으로써 자연스럽게 달성할 수 있습니다.

자세하고 친절한 설명 감사합니다! 행복합니다:+1:

근데 사실 아폴로가 프래그먼트 처리하는데 버그가 좀 많아서 불행합니다 .... ㅠㅠㅠ

구현 다 갈아엎는다고 패치도 늦ㄱㅎ

저는 간단하게 할때는 그냥 refetch하는거 같아요 ㅋㅋ

리모트 폼이라는게, 서버에서 말씀하시는거에요??

<https://github.com/huv1k/nexus-arguments-validation>

저는 요거 사용하고있지는 않은데 ㅋㅋ 이런 Approach 좋은거같아요.

그 폼에서 submit 하기전에 부분적으로 필드별로

더 일찍 검증하고 싶은데 그런 쪽 어프로치 괜찮은게 없나 했어요

ㅋㅋㅋㅋ GraphQL로 할 수 있는게 있을지 ㅋㅋ 있으면 좋긴하겠네요

description같은데에 적어놓으면 스키마보고 자동으로 validation 로직 만들어주면요

GraphQL 로 할 수 있나 생각해보고 있었는데 이게 mutation 이 맞는지 아닌지도 모르겠는…;

<https://github.com/confuser/graphql-constraint-directive>

mutation 요청을 미리 날릴 수는 없으니 ;;

아니면 뭐 `@client` 뮤테이션 만들어서 쓸 수도 있겠네요

apollo-link 를 하나 만들어 써야하나

GraphQL 스키마에 input이 nullable한지 살펴보세요~

이게 client mutation인데..notNullㅇ네요ㅠㅠ

밑에 `String!` 에 느낌표를 빼보세요 ㅎㅎ

전자 느낌표 한거고 두번째가 느낌표 안한거구요… 세번째가 Input class인데 전부다 null을 막고있네요..

흠 ㅠㅠ 왜이런지.. 오류인건지...ㅠㅠ 도움 감사합니다 ~

해결했습니다!
mutation 빌드방법을 바꾸니 해결됐네요~
느낌표 떼구요~

헉... Apollo Engine 이라는게... Server 에 있는거죠 ? graphql-ruby 는 전혀 안해주는것 같더라구요.

Apollo Engine에 직접 통계치 쏴줄수있는 API가 있을거에요 ㅎㅎ

<https://www.apollographql.com/docs/graph-manager/setup-analytics/#sending-metrics-to-the-reporting-endpoint>

제가 시도해보진 않았는데요 ㅋㅋ 혹시 성공하시면 공유 부탁드려요 ㅋㅋ 저도 궁금해서요!

저 이거 붙여 쓰고있는데 apollo engine이 많은 메트릭을 수집하고 보이긴 다보이는데 이상하게 손이 잘안가네요ㅎㅎ 느리기도하구요

로깅을 통한 Schema Check가 저는 엄청 유용하더라구요 ㅎㅎ

Deprecation 했을때 각 유관 프로젝트에 Notify하기도 편하구요