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

GraphQL Korea

오잉 어디 올라가있는거 있나요

아뇨 저도 못 봤는데 그냥 있나 해서요 ㅋㅋㅋㅋㅋㅋ

아직 결정이 안된게 많아 보이던데

그렇군요….. 당분간 playground나 써야 하나

Yoga 에 붙어있는거 쓸만하던데요

Yoga에 붙어있는 거 괜찮았는데 npm에 배포가 안 되어 있어서

저는 그래도 Playground가 GraphiQL보단 낫다는 인상이었는데 ㅋㅋㅋㅋㅋ

GraphiQL은 계속 패치가 올라오고 확장 가능

죽었다는 사실은 알고 있긴 했는데

Yoga 가 쓸만한건 GraphiQL을 확장한거에요

일단 Monaco가 쓰고 싶다는 마음이 제일 큰 거긴 해서

업데이트: <https://www.npmjs.com/package/graphiql/v/2.0.0-next.0|2.0.0-next.0>이 npm에 올라왔었네요

오오.. GraphQL Editor 쓸만한가요?? ㅎㅎ

스키마 논의하기엔 좋아보여요 ㅎㅎ voyager가 탑재된 온라인 에디터 느낌? 

스키마가 다음과 같을 때
```type Book {
 name : String
}

type User {
 books : [Book]
}

type Place {
  owner: User
}

type query {
 user(id:ID):User
 place(id:ID):Place
}```
```{
 user(id:"1") {   // &lt;- user api를 호출해서 {books : [{id:1, name:'1번 책', report: true}, {id:2, name:'2번 책', report : false}]}
  books { // &lt;- book.report 값이 true 인 것만 보여줘야 함
    name
  }
 }
}

{
 place(id:"1") { // 장소 api 호출해서 user 정보 획득
  owner { // &lt;- user api를 호출해서 {books : [{id:1, name:'1번 책', report: true}, {id:2, name:'2번 책', report : false}]}
   books { // &lt;- book.report 값이 true 인 것만 보여줘야 함
     name
  }
 }
}```

`report` 값은 클라이언트 입장에서 필요 없기 때문에 스키마에 넣지 않았을 경우입니다.

1. `user` 필드 리졸버와 `owner` 필드 리졸버에서 `report` 값을 통해 `books` 정보를 필터링해서 리턴
2. `User` 타입의 `books` 필드 리졸버에서 유저 조회 api를 호출해서 `report` 값을 획득 후 필터링해서 리턴
3. `report` 를 스키마에 추가 후 `Parent` 타입에서 접근, 없으면 api 호출
위 세 가지 방법이 있는 것 같은데 graphql 릴레이션 관점에서는 2번이 더 맞아보여서요… 다들 어떠신가요?

아니면 스키마가 잘못 디자인 된걸까요?

저는 주로 2번으로 작성하고, 이걸 위해서 Lazy 캐싱으로 DataLoader 호출을 감싼 내부 필드를 가진 클래스를 만들어서 써요

클라이언트에서 사용하는 용도를 기준으로 판단하면 되지 않을까요?  어떤 프레임워크를 사용하냐에 따라 다를 것 같네요! <https://hasura.io/blog/graphql-nulls-cheatsheet/#different-approaches-by-graphql-clients|https://hasura.io/blog/graphql-nulls-cheatsheet/#different-approaches-by-graphql-clients>

_클라이언트에서 사용하는 용도를 기준으로 판단하면 되지 않을까요?_
좀 더 설명 부탁드려도 될까요 ?

프론트는 apollo-client 사용하고 있습니다.

요거는 정책에 따라서 다를거같은데요. 연호님 말씀하신대로 Facebook이나 Netflix는 부분장애를 허용해서 모든 필드를 Nullable하게 만드는걸로 알고있어요

다만 모든게 Nullable하면 클라단에 DX가 너무 별로이기 때문에, Relay에는 클라이언트 단에서 타입을 생성할때 non nullable 하다고 선언할 수 있어요. (만약 null 인경우 throw할지, log만 남길지도 클라이언트가 결정할수있답니다 ㅎㅎ)

<https://relay.dev/docs/next/guides/required-directive/|https://relay.dev/docs/next/guides/required-directive/>

Apollo Client에 있을지 모르겠네욤 ㅠ

<@UN0GLRW14> 님 말씀대로 장애가 발생할 수 있으니, profile을 nullable로 변경해도 될 것 같구용! (그럼 다른 유저 데이터는 클라에서 제대로 받을 수 있으니까요). apollo client에서는 요청시 error policy를 설정해서 non-null 필드에 null이 왔을 경우 부분 데이터는 그대로 받고, graphql error로 확인할 수 있습니다 (`errorPolicy`: `all`)

<https://www.apollographql.com/docs/react/data/error-handling/#graphql-error-policies>

답변 감사합니다.
realy, apollo client에서 null 데이터를 어떻게 처리할 지 따로 방법을 제공하고 있군요. 읽어 보겠습니다ㅎㅎ

위의 profile! 에 대해서도 저희팀에서 따로 얘기를 해보았는데…
1. 유저의 프로필이 없으면 프로필을 포함한 유저의 데이터는 의미가 없어 ! =&gt; profile! (error propagation)
2. 유저의 프로필이 없으면 유저의 데이터는 보여주고 이미지는 기본 이미지로 설정할거야 =&gt; profile
로 정리가 되었습니다.

<@UN0GLRW14> 님이 말씀하신 것처럼, 타입에 대한 정책을 어떻게 할 것인지가 먼저 정의되야 할 것 같습니다~!

저는 적합하지 않다고 생각해요. 왜냐하면 대부분의 서버가 분리된 이유는 관심사의 분리와 추상화 때문인데요. GraphQL은 관계에 대한 정보를 드러내고, 해당 관계에 대한 이해가 다른 서버에서 사용된다면 그 두 서버는 서로 강하게 결합된 형태가 될거에요. 따라서 굳이 분리하지 않아도 될 서버였던거죠! ㅋㅋ

GraphQL은 해당 스키마와 클라이언트를 강하게 결합하는데 최적화되어 있기 때문에, 다음과 같이 이해하는게 좋다고 생각해요.

```클라이언트 &lt;-강결합(GraphQL)-&gt; BFF 서버 &lt;-약결합(RPC)-&gt; 마이크로서비스```
사실 클라이언트와 BFF는 한 몸이지만... 인터넷이라는 비극으로 인해 찢어지게 된 거죠 ㅋㅋ (PHP 같은 친구들은 강결합 되어있죠 ㅋㅋ)

따라서 GraphQL은 클라이언트 상태와 리모트 데이터를 더 우아하게 강결합할 수 있는 방법에 가깝지 않나 하는 생각이에요.

아하 좋은 답변 정말 감사합니다!

먼저 이런 질문을 드리게 된 배경은 현재 팀의 상황이 MSA 환경에서도 중심에 가깝게 위치를 하고 있고, API가 굉장히 많은 상황인데, API 들 간에 중복도 많고, 오버페칭도 굉장히 많이 일어나고 있고 이러한 구조를 개선하고자, GraphQL을 도입해보면 어떨까하는 생각에 질문을 드려보았습니다!

말씀해주신 내용은 생각해보지 못한 내용이고 도움이 되었습니다.
그런데, 그런 점들을 제쳐두고 저희팀 같은 상황을 해소하고자 하는 용도로 사용하는 것에는 어떻게 생각하실까요??

&gt; MSA 환경에서도 중심에 가깝게 위치를 하고 있고,
요 이야기는 Aggregation을 담당하는 서비스를 만들고 계신다는 뜻일까요?

&gt; API가 굉장히 많은 상황인데, API 들 간에 중복도 많고, 오버페칭도 굉장히 많이 일어나고 있고
API가 파편화 된 상황에서 오버페칭은 피할수 없을거같아요 ㅎㅎ (조금 더 자세히 설명 주시면 의견 드릴 수 있을거같네요!) 만약 N+1 문제라면 batch get api를 통해서 최적화할 수 있을거같아요.

Aggregation이라기 보다는 저희팀 데이터(를 제공하는 API) 에 의존하는 타 시스템이 많다는 의미었습니다!

각 시스템에서 요구하는 API가 비슷하면서도 조금씩 다르기 때문에 각각의 요구사항을 다 들어주면서 API를 계속적으로 추가하다보니,
코드의 중복도 많고, 어떤 API가 여전히 쓰이고 있는지, 어떤 필드들이 쓰이고 있는지 이런것들이 시간이 지날수록 관리가 어려워지는 것 같아 GraphQL로 해소를 해보고자 생각을 해보았습니다!

아 그런거면 GraphQL 괜찮죠 ㅋㅋㅋ 필드별 Usage도 볼 수 있는 도구도 있구요

그러면 RPC스럽게 스키마 디자인을 하시면 될거같아요. 관계에 대한 정보를 쫙 빼시면 좋겠네요

서버 입장에서는 스키마만 정의하면 되고, 타 시스템에서 필요한 필드들만 요구하게 되니 단점들이 많이 해소가 될거라고 생각했어요!

넵 그치만 오용되기 시작하면, 다른 단점들이 나올 수 있으니 주의하시는게 좋을거같아요 ㅎㅎ GraphQL이 꽤나 강력해서요. 이것저것 기능이 많을거고, 그 중에서 menmen님 문제를 해결하는 것만 취하시고 다른것들은 쓰지 않으시는걸 추천해요 ㅎㅎ

그런데, 회사분들과 의견을 주고 받는데 Server to server에는 적합하지 않다고 생각하시는 분들이 많더라구요!
명쾌한 이유는 없었고, GraphQL이라는 기술의 스펙이 그렇다~ 하는 이유로..

넵 GraphQL이 풀고자하는 문제에 대한 방향성은 안 맞긴합니다 ㅋㅋ GraphQL의 부수효과중에 원하시는것만 취하는 형태에 가까울거같아요.

+ 만약에 Node.js로 서버 구현하신다면 Type checking에 대한 overhead가 좀 커서 확인해보시는게 좋아요. 한 요청에 대해 필드가 5000개가 넘어가면 급격하게 느려집니다. (왜냐하면 타입 시스템에 대한 보장을 GraphQL Layer가 해줘야하기때문에 JavaScript 구현체 같은 경우에 응답하는 모든 필드에 대해 타입 검사를 해요)

아하, 그렇군요..!
저희 서버는 스프링여서 그런 부분은 문제가 덜 할 것 같긴하네요!

말씀해주신 내용 가지고 생각해보니, 현재 너무 필요한 기능에만 집중해서 생각한 것 같긴하네요.
적합한지 판단을 하려면 좀 더 공부를 해야할 것 같네요 ㅠ

좋은 답변 감사합니다! 도움이 많이 되었어요~!

저희 회사 백엔드가 마이크로서비스 간 통신을 GraphQL로 하고 있는데, gRPC나 REST로 짤걸 그랬다고 많이 후회하고 있습니다 ㅠ

아무래도 마이크로서비스 간에 필요한 통신은 RPC인 경우가 대부분이고, 그렇다 보니 GraphQL은 사용이 좀 번잡해지더라고요

다만 Schema Stitching이나 Federation을 통해 각 마이크로서비스가 Subgraph를 노출하는 것 자체는 매우 선진적인 API 구축 방식이라고 생각합니다!

GraphQL이야기는 아니지만 저도 개인적인 의견하나 남겨요~
&gt; Aggregation이라기 보다는 저희팀 데이터(를 제공하는 API) 에 의존하는 타 시스템이 많다는 의미었습니다!
&gt; 
&gt; 각 시스템에서 요구하는 API가 비슷하면서도 조금씩 다르기 때문에 각각의 요구사항을 다 들어주면서 API를 계속적으로 추가하다보니,
&gt; 코드의 중복도 많고, 어떤 API가 여전히 쓰이고 있는지, 어떤 필드들이 쓰이고 있는지 이런것들이 시간이 지날수록 관리가 어려워지는 것 같아 GraphQL로 해소를 해보고자 생각을 해보았습니다!
이 부분에 대해서 두가지 측면으로 살펴봐야할거 같아요.
• 사내에 플랫폼으로서 만드는 서비스
    ◦ 제가 다니는 회사가 이런 접근을 많이 하는데요, 만약 채팅팀이 있다면 여기서는 하나의 서비스를 위해 fit하게 디자인 하지 않고 많은 서비스들을 위해 설계하고 있어요. 마치 제가 디스코드 API를 이용할때 디스코드 측에서 저한테 fit하게 api를 뚫어주지 않은것 처럼요. 다만 각 서비스들이 요구하는것을 사내서비스들이다보니 좀더 잘 들어주지만 결국 `유저의 목소리에 대한 플랫폼으로서의 대응` 을 하는거 같아요. 디스코드가 각각의 고객마다 API를 새로 파지 않고 각 고객이 만족할수 있게 기존 API에 기능이나 필드를 추가할거 같아요.
• 다른 사내 제품들을 서포트하기 위한 서비스
    ◦ 이러면 각 사내 서비스들에 하나 하나 fit하게 맞게 api를 만들어야해서 어떤식으로든 코드 중복은 피할수 없지 않을까 싶어요. 이게 서로 다른팀이 다른것을 요구하면 서로 다른 이유로 변경되기 때문에 중복으로서 추상화해야하는게 아니라 우발적 중복(우연히 비슷해보이는 중복)으로 봐야할거 같아요

<@U01SG1JDP1S> 좋은 답변 정말 감사합니다!

그렇다면 혹시, gRPC나 REST로 하시는걸 후회하는 것과 GraphQL 사용이 번잡해지는 이유를 간단하게 라도 말씀해주실 게 있으실까요~?

<@U018W3L7XCZ> 님 좋은 말씀 감사합니다!

말씀해주신대로, 저희팀의 역할은 사내 플롯폼으로써의 역할을 해야하는데, 현 상황은 후자가 되어가고 있어서 문제인 것 같네요!
API 구조를 개선하게 되면 전자의 컨셉으로 초점을 맞춰봐야 겠다는 생각이드네요!

GraphQL 쪽은 요청 하나를 구성할 때마다 쿼리를 짜고, 이걸로 코드젠을 돌리고, 갖다쓰고 하는 플로우 자체가 gRPC에 비해 좀 번잡하다고 느껴진 것 같아요. __typename 가지고 에러 처리하고 하는 것도 프론트에 적합한 방식이지 RPC용으로는 영 번잡하다는 생각만 많이 들었어서요

쓰세요. 설명해주신 것들 보면 굉장히 적합한 유즈케이스 같은데요

스프링 쓰시면 그냥 DGS 같은거 쓰심 될듯

gRPC 서버 있으면 rejoiner 도 괜찮을거같고요

구체적인 프레임워크는 조직간 협업이 어떻게 일어나고 있느냐에 따라 좀 다를 것 같은데요

사례 자체는 GraphQL 이 해결하는 좋은 지점이라고 생각해요. GraphQL 등장배경과도 밀접한 연관이 있고요

&gt; GraphQL은 server to server 용으로 사용하기에는 적합하지 않다고 생각하시나요??
깔끔하게 원 질문에 대한 답을 드리자면, 아니요 ㅎㅎ 다른 얘기는 대체로 근거가 빈약한 낭설이라 적당히 무시하고 직접 PoC 해보시는게 더 빠릅니다

음 그럼 그냥 제가 잘 못 써서 불편했던 걸로 (?)

그건 대안으로 제시하신 애들도 같은 문제를 겪어요. 그냥 어떻게 쓰냐 차이

저 문제를 안겪으려면 Schemaless RPC 를 써야합니다. (예시: BERT) 근데 그러면 뭐….

아마 코드젠 프로세스가 언어 툴체인에 연동되어 있냐 차이가 제일 크게 느껴졌던 것 같네요

(비교대상이 Rust 쪽 Tonic이었어서)

그건 GraphQL 논의에서 많이 벗어나는 얘기인듯

기술 자체랑은 연관성이 적었던 걸로....

<@UN4AJARCN> 님 좋은 답변 감사합니다!
사례가 잘 없긴하던데, 직접 해봐야겠군요,,

조직간에 GraphQL 통신이 익숙치 않은경우 아예 노출을 안하는게 나을수도 있어요

네 그게 가장 큰 문제점인 것 같기는 합니다..!

아니면 플레이그라운드만 노출해주고 URL 매핑을 요청받아도 되고요

요컨데 GraphQL 은 유즈케이스 제너레이터라서

처하신 상황에서 GraphQL 런타임을 사용하면 생산성 이점이 많은데요

외부에서 요구하는 인터페이스가 다르다면 매핑을 자동화할 수 있습니다

이 URL을 찌르면 이 GraphQL 오퍼레이션이 실행됩니다 식으로요

&gt; 이 URL을 찌르면 이 GraphQL 오퍼레이션이 실행됩니다 식으로요
저도 Persisted Query 생각났어요 ㅎㅎ

그럼 클라 시스템은 GraphQL을 몰라도 되고 필요할 때 요청해서 엔드포인트를 생성하면 됩니다.

저 워크플로우가 정적이 아니라 관리형 서비스이면 돼요

아? 제가 이해를 정확히 한게 맞나 싶은데요,,

endpoint는 REST로 열어놓고, 내부적으로 한단계를 더 거쳐서 GraphQL 을 사용한다는 말씀이실까요~?

아뇨 REST인지 뭔지는 관계가 없구요

&gt; Aggregation이라기 보다는 저희팀 데이터(를 제공하는 API) 에 의존하는 타 시스템이 많다는 의미었습니다!
&gt; 
&gt; 각 시스템에서 요구하는 API가 비슷하면서도 조금씩 다르기 때문에 각각의 요구사항을 다 들어주면서 API를 계속적으로 추가하다보니,
&gt; 코드의 중복도 많고, 어떤 API가 여전히 쓰이고 있는지, 어떤 필드들이 쓰이고 있는지 이런것들이 시간이 지날수록 관리가 어려워지는 것 같아 GraphQL로 해소를 해보고자 생각을 해보았습니다!
&gt; 
이 상황을 해소하는데 GraphQL이 도움을 주느냐는 Yes 라는건데

클라이언트 측에서는 GraphQL의 형식이나 언어를 원치 않는다는거잖아요

그럼 두개의 장점만 취하시면 되겠됴

엔드포인트 찍어내는데 GraphQL을 쓰시라는 얘깁니다. 손으로 해도 되고 자동으로 해도 되고

자동으로 해주는 솔루션이 Sofa나 Hasura같은게 있는데 이상황에 딱 맞진 않는거같고 개발방식을 바꾸는것도 큰 변경이니까

저라면 직접 만들텐데 어떻게 만들지를 제시한거에요

1. GraphQL 로 전체 서비스 suface 를 만듬 (feat. Resolvers)
2. 동적으로 확장할 수 있는 컨트롤러 레이어를 만듬
3. GraphQL 플레이그라운드(Graphiql)를 제공함 (보통 이건 좋아합니다)
4. 플레이그라운드의 결과(operation) 바탕으로 엔드포인트를 생성할 수 있는 Form 을 제공함

여기 까지 자동화하면 좀 풀리지 않을까요

HTTP 기준으로 얘기하고 있긴 하지만 gRPC 서비스로 제공하는 경우도 마찬가지

아~~ 이제 이해가 좀 가는 것 같습니다!
이런식으로 접근할 수도 있군요,,
신기하네요! 감사합니다~~!

GraphQL을 사용해서 개발한다가 반드시 GraphQL 엔드포인트로만 서비스를 제공한다는 얘기가 되야하는건 아닙니다

같은 내용의 스레드: <https://twitter.com/KrComet/status/1537495360196575232?t=lhJsQTsGVHukR_HezkWGwA&amp;s=19|https://twitter.com/KrComet/status/1537495360196575232?t=lhJsQTsGVHukR_HezkWGwA&amp;s=19>

Graphql BFF관련 질문이 있습니다!
js생태계가 graphql이 작성도 편하고 오픈소스들의 유지보수도 활성화 되어있을 것 같은데
node 서버를 만드시면서 인증/인가나 이슈 대응(java쪽 Zuul같은?) 등에 대한 처리를 프로덕션에서 어떤식으로 해결하시는지 궁금합니다!
(참조할만한 BFF 레퍼런스나 어떤 아키텍쳐로 설계해서 이 문제를 해결하는지 알려주시면 많은 도움이 될 것 같습니다!:man-bowing:)

시간적 여유가 있으면 스터디, 없으면 1-pager/cheatsheet 따위를 이용해서 일하면서 숙지할 수 있게 하면 어떨까요. 제가 전에 일한 곳에선 lint도 도움이 됐어요.

간략한 문서/치트시트도 고민했다가 초심자 입장, GraphQL 을 전혀 모르는 사람이 읽을 수 있는 문서를 쓸 역량이 나에게 있는가 (,,) 에 대한 고민으로 이어져서 망설였는데 일단은 마련해야겠네요

프론트는 Next.js 앱에 Relay 을 사용하고 있고

그 사람이 어려워하는 지점 어렵다고 생각하는 지점 같은걸 관찰해서 찾는게 도움이 됩니다

이해도는 어차피 시간지나면 따라오고요

본인이 다 이해해야겠다 하고 나서는거 아니면 굳이 이해하고 써야한다고 강요할 필요는 없는거같아요

같은 수준의 이해를 요구, 가 아니라 강요할 필요가 없군요

뭐 협업을 어떻게 하냐에 따라 다를거 같긴 하네요

아무튼 도입을 누가 했는지 맥락 상황을 전혀 모르지만

주변사람들의 이해도 부족에도 불문하고 도입한데는 그만한 배경이 있을거 아닙니까

그 배경근거를 납득가능한 형태로 증명하시면 됩니다

만약 이거 왜 일일히 이렇게해야하는지 모르겠다~ 류의 반발이 계속 나오고 있다며뇽

다행히 반발보다는 개념 자체가 익숙치 않은 것 같아요 조언 감사합니다!

반발이 없으면 좀 낫네요. 좋은 상황 위주로 많이 연출하시면 좋습니다

그분이 익숙한 도구에서 할 수 없는거면 더 좋구요

우선 왜 GraphQL 이어야 하는가에 대해서 확실하게 알려드리고 가는 것도 좋을 것 같아요. 별개로 저희 조직내에서는 production ready graphql 스터디를 쭈욱했는데, 강의식으로 챕터 하나하나 떼기만 하니 나중에 봤을때 분명히 다룬 내용인데 다들 잘 모르시더라구요..

저희도 스터디 했는데 제가 책 내용으로 레퍼런스해서 얘기하니까 잘 모르시긴 하더라구요... ㅋㅋㅋ ㅠㅠ 스터디는 빡세게 안 하면 그냥 견문과 용어 등에 익숙해지는 용도 정도로 생각하는게 좋을 것 같습니다(라기엔 좀 비효율적이긴 한데)

넵 단순히 듣기만 하는 것 보다 실무랑 관련지어서 스키마 설계를 직접 연습삼아 해본다거나 뭔가 인터랙션이 있어야 아무래도 더 기억에 남는 듯 하네요

저는 대부분의 경우 적절하지 않으며, 두 스키마를 분리하는 것이 대부분의 상황에서 좋은 결과를 낸다고 생각합니다.

진리의 케바케 아닐까요 ㅋㅋ 1-tier 아키텍처도 뭐 상황에 따라서는 아주 말도 안되는 얘기는 아닐 수 있고 DB 지원 범위에 따라 다르다고 생각해요. DB 자체가 애플리케이션 엔진일 수 있죠

약간 그전의 ORM 효용성 논의, 액티브 레코드 논의랑 맥락을 같이하는 것 같아요

근데 이 경우는 인터페이스가 해당 소프트웨어 외부로 노출되는 상황이다 보니 좀 더 레이어를 촘촘히 나누고 보수적으로 접근할 필요가 있죠

두 분 같은 회사 재직중이신가요

아 아뇽 스키마를 나눌 것인지 말 것인지요

&gt; 대신 DB schema가 변경되는 일은 적으니, 1:1 매핑했을 때의 이점을 더 중시한다고 하더라구요 
변경이 발생했을 때 드는 비용이랑 여기서 오는 이점을 비교해봐야겠네요. 그래도 레이어는 나누는게…ㅎㅎㅎ

케바케…. 무적의 단어..

저는 그럼에도 나누는게….예를 들어, 저희도 1:1 매핑 된 레거시 코드가 있는데, graphql D.name값을 얻기 위해서
질의할 때 굳이 A -&gt; B -&gt; C -&gt; D 타고 가야 하는 단점이 있더라구요.

클라이언트 입장에서는 ” 난 그냥 name이 필요한데 왜 DB 구조를 파악해가며 질의해야 하지?”

물론 A-&gt;B-&gt;B-&gt;D 이 구조가, GraphQL을 설계해서 나온 거라면 당연한 거지만, 그게 아니라 그냥 DB를 매핑해서 한게 문제더라구요.

다른 분들은 회사에서 어떤 방식으로 사용하시나요 ??

저는 스키마 나누는 방식으로 하되, 완전 분리되는 건 아니고 타입 자체는 대략 1대1 매핑되는 편이에요

그냥 computed 필드가 좀 들어간다거나 하는 식으로...

그냥 제가 말씀드리고 싶은 부분은

아키텍처마다 다르다는 것입니다

저는 디비 스키마가 구체적인 모델인 경우

넹 뭐 프론트에서 Dgraph 같은 거 바로 붙여서 쓰는 상황이고 그러면 사실 나누고 말고를 논의할 필요도 없긴 하죠

GraphQL 스키마는 유즈케이스에 해당한다고 보는데요

아시다시피 액티브 레코드 모델 쓰면 그 두가지를 분리해서 보지 않습니다

이 경우 디비의 표현력과 확장성이 충분하다면

아예 디비를 적극적으로 쓰는게 말이 안되지 않아요

실제 최근 DB-as-a-Service 들 보시면 기존 PaaS 보다 못하지 않습니다

애초에 디비가 얼마나 expressive 한 지가 중요하겠네요.

뒷북 쳐서 죄송합니다.
1:1 매핑하다보면 엔티티 간에 과도하게 조인되는 경우가 많지 않나요?
어쩔 수 없이 dto 객체를 만들면서 뭐가 맞는건지 궁금했었는데 좋은 의견을 나누고 있는 쓰레드라 참여해봅니다!

"과도하다" 기준이 다를 수 있겠지만 일반적으로 그 부분은 GraphQL이 해결하는 것 같아요. 서버에서 허용하는 + 클라이언트에서 요청한 만큼만 조인하겠죠.

DTO 만드는건 DAO랑은 조금 별개로 봅니다

<@UN4AJARCN> 그렇군요. 지금까지 resolver로 서비스 매핑정도로만 사용하고 있었어서 쿼리를 위해선 풀 조인을 했었는데, 관련 방식에 대해서 좀 더 찾아봐야겠습니다 

Untitled.ts

현재 코드는 이렇습니다. (GraphQL Yoga 3)

이 부분을 보면 `enableIncrementalDelivery` 옵션에 따라 createMultipartFetcher 를 사용하긴 합니다.
<https://github.com/graphql/graphiql/blob/main/packages/graphiql-toolkit/src/create-fetcher/createFetcher.ts#L38-L40>

createMultipartFetcher는 accept 에 multipart/mixed 를 붙이고, meros 로 리스폰스를 핸들링합니다.
<https://github.com/graphql/graphiql/blob/315feb6b41c5bcf1226a1c28165250e4669751b8/packages/graphiql-toolkit/src/create-fetcher/lib.ts#L151-L189>

제 상황에서 중단점을 찍어서 확인해보면, `isAsyncIterable(response)` 가 `false` 여서 `response.json` 으로 처리가 되고 있네요 흠

작업중인 코드입니다:
<https://github.com/iamchanii/graphql-yoga-defer-stream-practice>

오 재밌어 보이네요, 저도 한번 봐보겠습니다

아 일단 현 시점에선 experimental-stream-defer 대신 17 canary를 쓰시는 걸 추천드려요

음 그리고 Envelop 플러그인을 하나 만들어 넣으셔야 합니다

여기에서 setExecuteFn을 사용하셔야 하구요
<https://www.the-guild.dev/graphql/envelop/v3/plugins/lifecycle#before-3|https://www.the-guild.dev/graphql/envelop/v3/plugins/lifecycle#before-3>

그리고 거기에 experimentalExecuteIncrementally를 넘겨줘야 할 거에요
<https://github.com/graphql/graphql-js/pull/3703|https://github.com/graphql/graphql-js/pull/3703>

와우 좀 읽어보고 주말에 트라이 해보겠습니다

저는 GraphQL Yoga 꽤나 만족스럽게 쓰고 있습니다만, 사실 딱히 Relay와 함께 사용하기 좋다거나 한 게 있는지는 모르겠네요....?

어떤 백앤드도 relay spec 만 구현한다면 다 가능하지 않을까요?
다만 go 진영에서  facebook 이 만든 entgo 라는 orm 비스무리한 게 있는데 그건 built-in 으로 relay spec 에 맞는 connection 을 지원한다거나 하더라구요.

Relay 스펙 맞는 커넥션 지원이나 Node 리졸버 자동생성 같은 부분은 Pothos에 Prisma랑 Relay 플러그인 붙이는 쪽도 꽤나 괜찮습니다

단순히 어떤 라이브러리로 서버를 만들거냐는,
<https://graphql.org/code/>
<https://www.apollographql.com/docs/apollo-server/integrations/middleware#apollo-server-hapi>

위의 두개 참고하시면 될 것 같습니다

위에분 말씀처럼 Pothos도 괜찮은 것 같더라구요. 플러그인을 짱짱하게 지원해줘서, 그리고 nexus도 괜찮습니다 !

저희는 뮤테이션에만 union 타입의 에러를 사용해요

<@U02RB5J20EB> 답변 감사합니다! 혹시 그럼 query 에서의 에러는 어떻게 처리하시나요? 에러 상황일 때 모달이나 텍스트정도로 사용자에게 표시를 하고 싶은데 graphql error 를 내버리면 relay 에서 ErrorBoundary 를 그려버리니까 화면이 아예 바뀌어버려서요!

<@UNZ83BVGF> 저는 쿼리에서 리소스가 없는 것을 표현할 때 커넥션, 리스트는 빈 배열, 단일 아이템이나 부분 장애(MSA 혹은 스키마 스티칭)는 null을 반환할 것 같아요. 그 외 사용자 입력이 잘못된 경우 기획 적으로 막지 못했거나 구현상의 버그일 것으로 생각이 됩니다.

그 외 서버 에러같은 것이 발생했을 경우 모달이나 텍스트를 보여주고 싶으신 거라면, 릴레이랑은 무관하게 커스텀 ErrorBoundary를 하나더 감싸면 될것 같아요

아하 큰 도움 되었습니다. 감사합니다!

움,,,, 네임스페이스를 붙여야겠는데용

<https://www.the-guild.dev/graphql/mesh/docs/transforms/prefix>

저는 Schema Stitching에 namespace를 붙여서 쓰곤해요!

의견 감사드립니다! :) 살펴보겠습니다 :pray: 

최적화 하는 방법들이 있고 그 때는 보통 리졸버 4번째 인자로 들어가는 GraphQLInfo 객체의 실행맥락을 씁니다.

근데 GraphQL은 유연성을 최선으로 채택하고 평균적으로 괜찮은 성능(dataloader)를 택한 것에 가까워요. 시점이 되면 특정 리졸버 패스에 대해서 최적화할 수 있지만 이 경우 유연성이 어느정도 희생됩니다. 그래서 상당히 안정화된 경로에 대해서만 추가 최적화를 진행하시는게 좋아요

&gt; 같은 쿼리에서 subtasks에 대한 요청이 없을 때에도 DB에서는 여전히 subtasks 에 대한 조인이 발생합니다.
이건 데이터로더를 안쓰셔서 그런거 같아용

보통은 depth 마다 쿼리가 나갑니다

그렇지 않는 전략도 있는데 SQL-to-Compile 이라고 아예 쿼리와 연관된 SQL 문을 컴파일해서 쓰는 경우도 있어요

<https://join-monster.readthedocs.io/en/latest/>

<@UN4AJARCN> 데이터로더부터 알아봐야겠군요! 친절한 답변 정말 감사합니다!:pray:

```type User {
   name: String!
}

type Item {
   name: String!
}

query temp {
   user {
      item { // null
        name
      }
   }
}```
위와 같은 상황이시라면 resolveReference 처리하셨는지 확인해보시면 좋을 것 같아요~

프로파일링 우선 해보시길 권장드립니다

프로파일링 우선 해보시길 권장드립니다.

리턴해야하는 (type 수 * 필드 수) 만큼 type validation 을 하기 때문에 오버헤드가 클 수 있습니다. 페이지네이션으로 (type 수 * 필드 수)  를 최대한 줄여보세요. 관련된거로 검색해보면 type validation 오버헤드를 피하려고 graphql 스키마를 아예 JSON 으로 퉁쳐버리는 트릭도 소개하곤 하는데 당연히 좋은 방법은 아니라 생각해용

어떤 서버 구현체를 사용하시는지 모르겠지만 서버가 지원한다면 @defer 디렉티브를 사용하는 방법도 있습니다 <https://www.apollographql.com/docs/react/data/defer/>

오 defer 도 있군요.
현재 apollo studio 로 요청 꽤 되는 트래픽(150 reqs/s)에서 사용중이긴 한데, 퍼포먼스 이슈는 아직 크게 없어서요. 30-50ms 유지

data loader 잘 쓰시고 하셨으면 사실 큰 이슈는 없이 잘 사용하고 있어서 위에 분들 의견처럼 프로파일링 해보시는게 가장 빠르게 찾으실 수 있을거 같아요

대개 느려지는건 db, network 아닐까 싶어요-

어차피 스키마는 알고 있는거 아닌가요? 그냥 assertion 하면 안되나용

스키마를 알고 있긴한데, 런타임에서 ID 스칼라 타입이 빈문자열도 받을 수 있도록 되어 있어서 이부분을 좀 처리 하려구요.

type assertion 말씀하시는 건가요 ~ ?

네 그냥 처리됐다고 넘어가면 되는거 아닌가 해서요 타입이던

여쭤볼게 있습니다..
Apollo federation v2 파일 업로드 구현 예제가 있을까요??

graphql 과 관련이 없긴 한데요.
ECS + Codedeploy(blue/green) 으로 서비스하시는 분들 오늘 codedeploy 배포에 문제 없으셨나요? green 으로 routing 후 wait 하는 step에서 약 5분정도 지나면 green 이 health check fail 되며 rollback 되어버리는 문제가 있어서 aws support case 열었더니 aws 자체 문제이고 fix 중이라는 답변을 받아서요.