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

GraphQL Korea

흥미롭긴한데... 어떤 유즈케이스가 있나요?

Use case 라기 보단 apollo-codegen 에서 넘어와서 어색한 느낌이 듭니다. 아폴로에선 사용하는 쿼리에 대해서만 생성했었거든요. 굳이 모든 타입을 생성하는 이유를 모르겠는? 느낌이에요. 그리고 번들 사이즈가 걱정되긴 하는데 tree shaking 이 알아서 잘 되려나요..

스키마가 먼저냐 쿼리가 먼저냐 하면 스키마가 먼저이기 때문에

생각하시는거랑 반대로 역으로 사용중인 쿼리를 분석해서 사용중인 타입을 추론하는 동작이 있다면 그게 아주 비싸고 굳이 할 필요없는 작업이긴 합니다

그리고 graphql-codegen 은 애초에 런타임 코드는 생성하지 않습니다 (래퍼 제외)

&gt; 그게 아주 비싸고 굳이 할 필요없는 작업이긴 합니다
그렇군요.. 스키마가 먼저니까..

&gt; 그리고 graphql-codegen 은 애초에 런타임 코드는 생성하지 않습니다 (래퍼 제외)
런타임 코드 말고 예를 들어 타입 생성했을 때 2~3천줄 내외로 `generated/graphql.tsx` 타입 파일이 생성되는데 이걸 어플리케이션 코드에서 사용하는 부분에선 상관없겠죠?

네 뭐 어차피 타입정의에 불과하니... 몇 십만줄이 나와도 상관없긴 합니다

Graphal codegen 에서 apollo 를 이용한 hook도 만들 수 있어요 ㅎㅎ 저희 내부 스키마가 크다 보니 몇만 줄이 나오는데 vs code가 점점 느려지더라구요. 근데 해답은 아직 찾지 못했습니다 ㅜㅜ

네 파일 커져서 느려지긴 하는데 프리셋으로 쪼갤 수 있습니다.

<https://graphql-code-generator.com/docs/presets/near-operation-file>

이걸 쓰시거나.. 아니면 이쪽 구현 참고하셔서 프리셋을 만들면 되는데

gatsby-plugin-typegen 도 다다음 버전은 이런식으로 쪼갤 계획을 하고 있어요

in-source 로 하는것도 장단점이 뚜렷해서, 어떤 사이즈 까지는 그냥 한 파일로 쓰는게 좋고.. 에디터에서 느려지는게 체감이 될 정도면 나눠야죠

오 생각해보니 어차피 fragment랑 query에서 나오는 타입만 쓸거니 그렇게 하면 퍼포먼스가 나아지겠네요

<https://graphql-korea.slack.com/archives/CN13FD736/p1614828064047900?thread_ts=1614820990.045100&amp;cid=CN13FD736>
저도 해당 프리셋 잘 사용하고 있습니당. :slightly_smiling_face:

앗 그게 사이즈가 클때 generated graphql.tsx 를 안열어도 다른 파일에서 에디팅중일때도 영향이 있나요? 그건 아니겠죠?

에디팅엔 영향이 없지만 타입스크립트 쓰실 테니까요... 통짜 파일인이상 incremental 하게 처리가 안되기 때문에 타입 정보를 다시 구축하는 과정에서 language service 응답이 지연될 수 있습니다.

호오 꿀팁을 알아가네요,, 어쩐지 codegen 하고 자동완성이 반영되는데 너무 오래걸리더라는

<https://graphql-code-generator.com/docs/presets/near-operation-file|near-operation-file> 아 요게 namedOperation 까지 나눠버리는군요...흙

맞는 것 같은데 refetchQueries 에서 캐시를 사용하지 않는지에 대한 부분이 문서에 있나요? 요게 불확실하네요 저도

업데이트를 위한 옵션이니 항상 network 를 타야 될 것 같긴한데 말이죠

캐시 안쓰는 거 맞는 것 같네요

<https://www.apollographql.com/blog/when-to-use-refetch-queries-in-apollo-client/> 넴 저도 찾아보고 왔는데 캐시 안쓰네여

&gt; `refetchQueries` 를 통해서 다시 실행하고자 하는 쿼리들 나열
이건 목록을 다시 불러오는건가요?

&gt; 캐시 사용하는데 데이터가 여러개이거나 삭제/생성인 경우엔 아폴로가 자동으로 업데이트 불가하니 `update` 프로퍼티를 사용해서 수동으로 데이터 필터링 후 캐시 업데이트
relay에는 appendEdge 같은 API들이 있는데, Apollo에는 없겠죠..? ㅠㅠ

<https://relay.dev/docs/en/mutations#updater-configs>

넹 그냥 캐시 컨트롤 주고 모디파이하는 ㅋㅋ

relay 의 updater 만 있다고 보면 되겠네용

저도 프로덕션 프로젝트에서 이렇게 쓰고있습니다. 장점으로는 DB 구조와 graphql 타입이 비슷한 경우 필드를 두 번 정의하지 않아도 되어서 좋긴 하지만 단점으로는 nullable 여부, 타입 여부에 대해서 DB 단, node 단, graphql 단 세 곳을 손으로 일치시켜야해서 (=== 컴파일러나 IDE 가 잡아주지 못해서) 실수할 가능성이 높습니다.

데코레이터 띡띡 달아주면 DB, graphql 다 완성되어서 익숙해지니까 개발속도가 빠르고 편하긴 한데, 다시 짜라고 하면 다른 방식으로 할 거 같습니다.

좋지 않은 방법이냐고 물어보시면 nestjs graphql docs 에 공식으로 설명하고 있는 방식이니 나쁜 방법은 아닐거라 생각합니다.

아하 그렇군요 답변 갑사합니다!! :pray:

머신을 어떤 단위로 쓰시느냐에 따라 조금씩 다를듯한데요

몇몇 로직은 use* hook 그대로 쓰고싶을 수 있는데 그럼 그냥 이벤트를 독립적으로 쏴야죠

아폴로 클라이언트 인스턴스를 넘겨주는건 이상한거같고요

```const [mutation] = useMutation(...);

const [state, send] = useMachine(machine, {
  services: {
    mutation,
  },
});```
이렇게 주입합니다.

지금도 `service` 주입을 사용하긴 하는데요, `useLazyQuery` 로 넘겨주려고 하면 타입 에러가 나는데 `variables` 는 따로 넘겨줘야 하는 걸까요?

타입에러나는 코드가 어떤거지요?

쿼리는... 서비스로 안쓰는걸 추천드려요 (마땅히 쓸 이유가 없고 관심사 분리가 애매해짐)

타입에러는 `useMachine` 에서 서비스로 레이지 쿼리(매개변수 포함된)를 넘길 때 발생하는데

...? 타입에러가 나면 잡으면 되죠

쿼리를 서비스로 넘기는 이유는 페이지네이션을 컴포넌트 상태로 가져갈 경우 컴포넌트와 상태로직이 결합하는 문제 때문에 로직을 분리하려고 했습니다.

&gt; 페이지네이션을 컴포넌트 상태로 가져갈 경우 컴포넌트와 상태로직이 결합하는 문제 때문에 로직을 분리
잘 이해를 못했어요 ㅠㅠ

제가 잘 설명을 못해서 죄송한데 ㅠㅠ 캐시가 없는 페이지네이션을 하려면 컴포넌트 상태(`useState`) 로 관리하게 되면 컴포넌트 내부에 `fetchMore` 를 하고 페이지네이션 상태를 업데이트하는 코드가 들어가는데 컴포넌트와 로직을 분리하면 좋으니까 이걸 분리하려고 해여 타입에러는 지금 보고 잇습니당

예를 들면 다음과 같은 코드입니다..

```const ExampleComponent = () =&gt; {
  const loadMore = () =&gt; {
   ...endCursor 와 hasNextPage 를 체       크하고 컴포넌트의 페이지네이션 데이터를 업데이트 하는 로직
} // loadMore 를 분리하고 싶음
}```

캐시에 대한 부분을 쿼리에 양도한 이상 무조건 분리하는게 좋은지는 생각해볼 여지가 있고요, fetchMore랑 page 상태 정도 보관하실거같은데 (context가 필요하다면...? 애초에 필요가 없을수도 있음)

• 쿼리가 서비스의 제어를 받음
• 서비스가 쿼리를 이벤트로 받음
동기화를 둘 중에 하나로 갑니다

어렵게 안하셔도 "서비스가 쿼리를 이벤트로 받음" 이걸로 충분히 느슨하게 동기화가 되는데

그쳐 인피니트 스크롤이 동작하면서 `pageInfo` 가 업데이트 되고 그거 기반으로 재쿼리해서 페이지네이션 상태 업데이트 하는 로직입니당

pageInfo 를 메시지로 넣으시면 최종적으로는 동기화되는걸 기대할 수 있습니다

```React.useEffect(() =&gt; {
  send('PAGE_UPDATED', { pageInfo });
}, [send, pageInfo]);```

이거만 있어도 머신 맥락을 컴포넌트랑 동기화할 수 있어요

그리고 머신 컨텍스트에 페이지네이션 상태값을 저장하는 거군여

뭐 로직을 태우던 이펙트를 태우던 그건 자유롭겠죠

&gt; 무슨 일이 일어났는지 알려주면, 다음에 무엇을 해야하는지 통보해줍니다

제어를 조금 느슨하게 풀어보세요

둘이 의존성이 너무 강결합되면 안좋습니다

컴포넌트-머신의 결합 말씀하시는 건가여?

음 그러면 `fetchMore` 만 서비스로 넘긴다면 처음에 가져오는 데이터는 그냥 `useQuery` 에 있는 걸 쓰나여 아니면 컨텍스트에 다시 넘겨줘야 하나요? 여기가 뭔가 이상했어여

필요하면 그것도 이벤트로 보내던가 하시죠

suspense 가 있으면 더 깔끔한데 안쓰실테니까

데이터를 받아서 그걸 다시 머신 컨텍스트로 보내는게 뭔가 중복 같았어여…

"머신 컨텍스트로 보낸다" 는 아닙니다

머신이 로딩/성공/실패 상태를 가져야하는데 `useQuery` 의 결과값에 따라 이걸 다시 이벤트로 머신한테 주는게 뭔가 이상한다고 해야 하나

컨텍스트에 뭘 쓰는지는 결국 동작 디테일에 불과하고

컴포넌트는 그걸 알필요가 없어요

그건 로직에 따라 다른데 뭘 원하시는지에 따라

```useEffect(() =&gt; {
  if (loading) {
    send(LOADING)
  }
}, [loading]);```
그럼 이런 코드는 valid 한가여?

어쨋든 핵심은 이벤트-사이드이펙트

사이드 이펙트 제어가 머신에서 하는게 더 유리하기 때문에

그런 부분들을 위임한다고 보시면 될듯

중복이라고 생각했는데 사이드 이펙트 위임이라는 측면에서 보면 맞는것 같긴 하네요

if (loading) 분기는 지우셔도 됩니다

디테일은 신경 안쓸수록 머신 가치가 높아지겠죠

어차피 transition schema 에 따라 deterministic 하게 제어될 것이기 때문에

컴포넌트에서 역할을 온전히 넘겨주면 분기문같은거도 대부분 필요없습니다

그리고 동기화는 apollo cache 로 부터 전파 받아서 자동으로 동기화가 될테구요

이벤트를 쏘고, 세부사항은 잊어버리면 됩니다

데이터를 주고받는게 아니에요

그럼 제가 이해한 바는

1. 첫 쿼리는 로딩/성공/실패에 따라 머신에 이벤트로 쏴줌
2. 이후 `fetchMore` 는 `service` 로 사용된다음 해당 서비스가 invoke 되면서 알아서 상태 전환
여기서 컴포넌트는 머신에 대해 알 필요 없고 이벤트만 쏴주면 됨 (컴포넌트-로직 분리의 핵심)

이렇게 되는데 맞게 이해한 걸까여?

아폴로 캐시는 안 쓰니까 여기서 캐시 동기화는 신경 안서도 될것 같아여

&gt; 로딩/성공/실패에 따라
여전히 디테일이네요

아폴로 캐시는... 안쓴다는게 어떤의미인지

useQuery 를 아예 안쓴다는 의미인가요

일단 그거랑도 상관이 없는걸로 알고있는데

필요하면 재요청이 알아서 날라갈테니 신경 안써도 되는건 동일합니다

근데 로딩/실패/성공이 여전히 디테일이라는 말씀이 이해가 안돼요 ㅠㅠ

왜 디테일이죠 저게 각각 다른 상태아닌가여?

쿼리는 캐시 정책이랑 무관하게 원래 imperative하게 쓰는 물건이 아니에요

아폴로 문서는 거의 다 읽었어여…

그 상태를 구분하는건 머신이 할일이죠

머신이 그걸 구분하려면 현재 아폴로의 fetching 상태가 어때야 하는지 알아야 하지 않나요?

머신이 알아서 로딩/실패/성공을 구분할 수는 없지 않나여? 클라 인스턴스도 안받고 요청은 컴포넌트에서 하는데?

```React.useEffect(() =&gt; send('LOADING_CHANGE', loading), [loading]);React.useEffect(() =&gt; send('DATA_CHANGE', data), [data]);React.useEffect(() =&gt; send('ERROR_CHANGE', error), [error]);```
이것만 있어도 머신에 주어진 맥락은 충분하고

어 제가 말한게 저건데 저걸 디테일이라고 말씀하신 줄 알았네요

아니 `React.useEffect(() =&gt; send('RECIVED_RESULT', result), [result]);` 만 있어도 됨

물론 아폴로 타입정의가 좀 구려서 쪼개면 좋긴 하겠습니다만

아 그럼 머신이 result 받아서 알아서 상태 분기요?

그리고 서비스는 mutation, fetchMore 같은 사이드이펙트성만 씁니다

그럼 전체적으로 아폴로 요청 -&gt; 이펙트로 머신에 이벤트 전송 -&gt; 머신이 알아서 상태 분기, 쿼리는 imperative 말고 declarative 하게 사용 이거죠?

쿼리는 신경쓸 필요가 없어요 호출하면 알아서 캐시관리자(이 경우는 아폴로)에 의해 변경 전파가 일어나기 떄문에

감사합니다. 근데 아폴로 문서 불친절한 부분이 좀 있더라구여 자세히 써주면 좋았을 텐데

사실 쿼리 요청도 직접 제어하는것 보단 컴포넌트 단위로 다루는게 적절하다고 생각하는데

컴포넌트 단위 = colocated fragment 인가요?

그럼 컴포넌트 단위의 쿼리는 뭔가여?

쿼리를 밖에서 하는게 아니라 필요한 컴포넌트에서 하고 (요청단위를 묶으려면 프래그먼트를 쓸 수 있겠죠) 제어는 부모 컴포넌트가 담당하는 식이죠

(외부에 있는 독립적인 서비스가 아닌)

로딩 제어는 UI 맥락에 의존적이거든요

```Type '{ user: { accessToken: string; refreshToken: string; id: number; email: string; password: string; name: string; createdAt: Date; updatedAt: Date; }; errors: never[]; }' is not assignable to type 'Omit&lt;LoginResponse, "errors"&gt;'.
    The types of 'user.id' are incompatible between these types.
            Type 'number' is not assignable to type 'string'.```

Node id 타입 이름으로 붙이는 그것을 하려고 삽질하다가 질문이 반쪽으로 쪼개졌군요.. ㅋㅋㅋㅋ

아하 그거는 Node 모델 id 리졸버에서하고, Graphql-tools/schema에 인터페이스 리졸버쓰는 옵션이 있던걸로 압니다 ㅎㅎ

그 핸들러 용도가 그냥 프롬프트 띄우는 용도라 네트워크 요청을 안하길 권장하기도 하고, 크롬 80부터 지원하지 않게 될 예정이라 안쓰시는게 좋지 않을까요? 

<https://www.chromestatus.com/feature/4664843055398912|https://www.chromestatus.com/feature/4664843055398912>

reactive variable 잘 생성해서 설정 하셨나요?

v3에 새로 생긴 리액티브바 말씀이시죵?? 그것과 별개로 기존 v2에서 local state 쿼리하는 것 쓰고 있었는데 그게 v3에서 안먹네요..지금 기냥 귀찮아서 react variables 로 싹 바꾸고 있어요 :disappointed_relieved:

네 방식이 아주 바뀐거에요 reactive vars 로

대신 컴포넌트에서 쓰는 쿼리는 바뀌지 않았습니다

스토어 다루는 방식만 바뀐거로 알아요

이걸 또 reactive vars 를 직접 쓰는걸로 생각하실 수도 있을거같아서, `@client` 는 그대로 쓰셔도 되고 local resolvers 가 대체된거에요

예제 참고해보세요

<https://github.com/apollographql/ac3-state-management-examples/blob/master/apollo-local-state/src/cache.tsx>

넴 요건 좀 마음에 드는게 기존에는 graphql 이랑 엮여있어서 쓸데없이 __typename 넣어주고 그랬었는데 아예 분리되어서 좋은거같아요

오 v3에서는 캐쉬도 얼려버렸군요

기존에 `client.writeData()` 로 set 하고
```export const GET_LOCAL_STATE = gql`
  query {
    isAuthenticated @client
    user @client {
      id
    }
  }
`;```

위 쿼리로 조회하는 식으로 사용중이었는데 writeData 로 넣을때나 초기값 세팅할때 `__typename` 을 항상 적어줘야 됬었거든요 아무래도 graphql response 랑 같이 캐시에 들어가니

근데 뭐 이제 리액티브바를 쓰니 다 과거의 산물이 됐습니다

로직이라고 표현하신게 정확히 어떤걸지 모르겠습니다. 수도코드라도 적어주시면 더 좋을 것 같아요. 일단 추측성 답변을 드리자면 fragment는 순수하게 UI 에서 그 데이터를 의존하는 모든곳마다 배치합니다. Composition 자체도 의존의 한 종류겠구요

만약에 상위 객체에서 분기가 필요하면 해당 상위 레벨에서 필드를 한번 더 적는 식으로 하는거같아요 ㅎㅎ

```fragment CardArticle_article on Article {
  user {
    isUserBlocked
    ...CardArticleProfile_user
  }
}

const Component = () =&gt; {
  if (article.user.isBlocked) {
    // 유저가 차단되었다면 카드 자체를 숨기기
    return null
  }
}```
```fragment CardArticleProfile_user on User {
  nickname
  image {
    url
  }
  isUserBlocked
}```
이런 느낌을 질문하신거 맞을지 모르겠네요 ㅎㅎ

맞습니다!! 분기하는 로직은 저런식으로 하는군요!?!

가공 로직이라고 표현한것은 다음과 같이 표현할 수 있을것 같아요.
```const Card = () =&gt; {
 	// a, b를 가지고 c를 만드는 가공 메서드 &lt;--- 이 로직을 분리하고 싶었어요.
	return (&lt;h1&gt;{c}&lt;/h1&gt;)
}```
뭔가 순수 UI를 그리는 컴포넌트에는 다 가공된?만들어진 데이터를 넘기고싶었어요. 그 데이터를 만드는 로직은 분리하고 싶었습니다!

그럴때 fragment를 어디에 정의하면 좋을지 고민이 됬습니다:sweat_smile:

사실 로직을 신경쓰지 않는게 진짜 목적입니다 ㅋㅋㅋ;

오!? 그렇군요..!ㅋㅋ 감사합니다

혹시 하나 더 귱금한게 있는데 

fragment를 각각의 컴포넌트에서 선언하여 사용하면 위에서 fragment를 모아서 쿼리하는 로직( 또는 container component) 와의 의존성이 너무 강해지지 않나요??!!

해당 Fragment를 직접 import해서 사용하시나요??

&gt; fragment를 모아서 쿼리하는 로직( 또는 container component) 와의 의존성
이건 원래 GraphQL 이랑 상관 없이 존재해요! 컴포넌트를 컴포지션 하는게 곧 컴포넌트 의존성이죠
핵심은 컴포넌트와 데이터 의존성을 함께 배치하고 컴포지션이 항상 같은 위계로 일어나게 하는 점 입니다.
그럼 결과적으로 데이터 의존성은 별도의 처리로직이나 의존성 구조를 가지는 대신 뷰 컴포지션 구조를 따라 자연스럽게 일어나게 돼요

&gt; 해당 Fragment를 직접 import해서 사용하시나요??
네네.. 지금은 따로 분리해서 관리하고 사용했네요ㅜㅋ

apollo 랑 어떤 연관이 있나요? 미들웨어는 제하고 보셔도 될것같은데요

예를들어서 res.cookie 와 같은 코드를 쓰기 위해서 response 객체에 접근해야되는데 리졸버에서 넘겨받는 방법?을 잘 모르겠어요

Ben awad 이분이 예전에 올린 코드가 있는데 <https://github.com/benawad/node-ts-graphql-boilerplate/blob/5a7452107ba2b42d07c3464d8813969160ec81f4/src/index.ts#L44-L48>

Apollo server2 에선 사라진 api 같아서요

apollo-server-express인 경우에는 context에 req, res를 주입할수있어요.

오 혹시 관련링크 알려주실 수 있을까요?..

```new ApolloServer({
  context({req, res}) {
    return {
      req,
      res,
      //...
    }
  }
})```

오 간단하네요!! 감사합니다 __) :thumbsup:

음...? 링크까지 필요한가요 ㅎㅎ ApolloServer 생성할때 context

업데이트 하는 해당 엔티티의 id와 함께 업데이트한 값을 받아옵니다~

여러 값들을 받아올 경우에는 해당 값들을 다 같이 받아야 하나요? 예를 들어
```updateUser(id: 1, data: {
  email: "asdfasdf",
  phoneNumber: "1234"
}) {
  id
  email
  phoneNumber
}```

BREAKING CHANGES 같은 경우는 따로 체크 (스키마 체크)를 하시는게 좋아요 ㅎㅎ Apollo Studio에 해당 기능이 있으니 확인해보세요!

넵 체크 같은경우는 graphql-inspector 로 서버단에서 PR 시에 체크가 되도록 해놓았는데요( 요런 체크 말씀하시는게 맞는?지 모르겠네요) 제가 말씀드린 부분은 불필요한 breaking changes 를 아예 방지? 하는 느낌으로 input을 사용하는 방식이 어떤가 해서요,,

아니면 그냥 바뀔때마다 클라이언트에서 체크해서 같이 바꾸는게 맞는걸까요

애초에 스키마 만드는 시점에서 충돌과 확장 여부를 잘 고려하는게 좋고요. 타입검사 플로우가 전체적으로 있으면 좋죠

1. End-to-End type safety
2. Schema tracking

1번은 서버코드랑 생성된 코드 클라이언트 코드 싹 묶어서 타입스크립트 같은 정적 타입 도구 내에서 호환성을 보장하는거고 (Code-first)

2번은 별도의 스키마 레지스트리를 두고 변경을 추적해서 모든 프로젝트가 이걸 따라가는 방식 (Schema-first)

애초에 깨지지 않을 스키마를 만들고, 깨지면 그냥 새필드에서 다루고 graceful 하게 마이그레이션해라 가 일반적인 권장사항입니다.

쿼리나 뮤테이션 같은 경우에는

저는 무조건 도큐먼트를 따로 씁니다

```query GetPerson($id: ID!, $email: String) {
  person(input: {
    id: $id,
    email: $email,
  }) {
    ...Person
  }
}```
이런식으로 클라이언트가 문서관리를 하기 때문에 field arguments가 구체적으로 어떤 구성이냐는 사실 아무래도 상관없습니다

이렇게 따로 operation document 를 관리하면 스키마 추적만으로 변경 유효성을 검사하기가 훨씬 쉬워요

스키마 레벨에서는 인풋타입을 "항상" 쓰는게 좋고요

<https://graphql-rules.com/rules/mutation-input-arg>

와 감사합니다 ㅠㅠ 퇴근하고 찬찬히 읽어볼꼐요

개념 자체는 Platform agnostic 합니다. 구현을 제공하는건 본적 없네요

안드로이드 개발자 분한테 설명드리려고 하는데 뷰와 프래그먼트가 같이 위치하는건가요? 리액트에선 컴포넌트와 프래그먼트잖아요? 안드에선 VM에서 뷰로 데이터를 가공해서 내려준다고 하는데 어떻게 할수 있을지 궁금합니다!

안드로이드도 선택한 아키텍처에 따라서 좀 달라서... 맥락을 좀 더 알아야 할 것 같은데요

Colocation 자체는 GraphQL 이랑 연관짓지 않고도 설명할수 있긴한데

MVVM이라고 합니다! 이게 아키텍쳐가 맞는진 모르겠지만...

Colocation + Declarative pattern 두개로 나눠서 설명할 수 있을 것 같아요.

Declarative pattern은 "무엇"과 "어떻게"를 분리해서 사고하고 UI에선 "무엇"을 표현할지 선언하는데만 집중한다고 볼 수 있는데

여기서 "무엇"에 해당하는 것들을 기술로 구분하지 않고 관심사 위주로 응집도를 높이기 위해 하는 것들이 Colocation 이죠

웹으로 따지면 JSX (UI 선언)에, CSS-in-JS (스타일 선언)에, GraphQL Fragment (데이터의존성 선언) 등을 함께 배치하는 일인데

안드로이드에서 얘기하는 MV* 아키텍처들은 모두 레이어드 아키텍처라서 조금 주제가 다를거같아요. 멘탈모델 쉬프트가 필요해요

컴포넌트 중심적인 사고 자체는 Jetpack compose 가 몰고오는거같은데

그쪽에 스타일이나 데이터패칭 같은 concerns 가 통합이 되는지 모르겠네요

jetpack compose 라는게 안드에서 컴포넌트 중심 사고를 하게 도와주는건가요?

그럼 그냥 "Jetpack compose 같은거에요" 라고 얘기하면 맞지 않을까요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

ㅋㅋㅋ 아 근데 알파버전이네요 ㅠ

Jetpack compose 는 안드로이드에서 다양한 성공사례들 모아다가 만든 새로운 툴킷인데요. 저보다 안드로이드 개발자분한테 역으로 설명들으시는게 나을듯

관련 얘기하다보면 어느순간 일치하는 부분이 생길거에요

그러면 멘탈모델을 바꾸지 않는한 해당 개념 구현은 불가능한걸까요?

공용으로 많이 쓰는거라면 input object type에 directive도 좋은 방법인거같아요 ㅎㅎ 저는 제품 개발 당시에는 잘 몰라서 그냥 구현했던거같네요 ㅠ

<https://www.graphql-tools.com/docs/schema-directives/>

커스텀 스칼라를 보통 쓰고, 커스텀 스칼라랑 편의용 스키마 디렉티브를 쓰는 경우도 있어요

일반 field는 호출 될 때마다 그냥 middleware처럼 쓸 수 있는데 클라이언트에서 input으로 받는 부분은 그만큼 간단하지는 않은 모양이네요 ㅠㅠ 답변 감사드립니다!

바벨 쪽에서 잡아주셔야되지 않을까요??

webpack -&gt; babel-loader -&gt; options 또는 babelrc

바벨이 graphql 템플릿 함수를 변환하지 못 하고 있는것은 확실해 보이는데.. 공식 문서 가이드대로 설정해준 듯 한데..

음 .ts 파일은 babel을 안거치는거같은데 맞나요?

1. babel-loader -&gt; ts-loader
2. ts-loader -&gt; babel-loader
혹시 두 로더의 순서가 영향을 미칠까요?

ts, tsx를 babel-loader로 꼽으시구요

babelrc에서 preset-typescript를 다시면 될거같아요.

<https://babeljs.io/docs/en/babel-preset-typescript>

네 맞습니다! 한번 시도해보겠습니다. :blush:

아직 react 17 반영이 안된건가 React를 못 찾네요

```["@babel/preset-react", {
      "runtime": "automatic"
    }]```
그래서 다음과 같이 해결했습니다! 도움 주셔서 감사합니다 ㅎㅎ

저희 회사엔 스키마 디자인을 가이드하는 그룹이 따로 있어요. 그 그룹에서 best practice도 관리하고 새로운 스키마를 디자인할 때 컨설팅도 하고 있어요.

와우, 별도 디자인 그룹이 따로 있는건 엄청 부럽네요 ㅎㅎ 전사적으로 GraphQL 에 대한 강한 확신이 있나봐요 :thumbsup:

해당 그룹에서는 아래처럼 가이드가 이뤄지는 상황인거죠?
1. best practice 기반 셀프 디자인
2. 모호한 부분에 대한 추가적인 컨설팅 요청

네 맞습니다. 디자인만 담당하는 엔지니어들이 따로 있는 건 아니고 초창기부터 사내 GraphQL ecosystem에 참여했었던 엔지니어들이 참여하고 있어요. 디자인하는 사람과 implement하는 사람이 다르면 best practice가 현실을 반영하지 못할 것 같아 그런 구조는 좋지 않을 것 같아요.

네, 말씀하신 부분에는 완전히 동의합니다. 설계만 별도로 이뤄지는 경우, 의도하지 않더라도 현실을 반영하지 못하는 경우가 생길 수 밖에 없으니까요~

혹시 예전에 GraphQL DevOps 도 별도 조직에서 이뤄진다고 말씀해주시지 않으셨나요? 예전에 schema tooling 관련 질문에서 대답해주셨던 기억이 있어서 여쭤봅니다 ㅎㅎ

DevOps라고 하시면 툴링 얘기신가요? UI 쪽은 UI 엔지니어들끼리 알음알음하고 있지만 ㅠㅠ 서버쪽은 플랫폼 팀에서 지원해주고 있어요 (프레임워크, 모니터링 등)

서버쪽 모니터링, Schema Check 등 얘기였어요, 다른 분이었나봐요, 혼란을 드렸네요 ㅜㅜㅎㅎ

그런데 서버쪽은 스키마 디자인 컨설팅 / 도구 지원까지 있다면, 환경이 정말 잘 구축되어있네요 :thumbsup:

다른 분들도 어떻게 하고 계신지 궁금하네요~ 대부분은 별도 지원 없이 팀 내에서 작은 규모로 이뤄지고 있을 것 같아서요 ㅎㅎ

&gt; 전체적인 관점에서 룰
요건 어떤 의미실까요?

&gt;  요건 어떤 의미실까요?
Do &amp; Don't 형태로 정리할 수 있는 내용입니다~
예를 들면 pagination 스키마는 아래 세가지 형태 중 한가지만 사용해야 합니다
```1. page, size
2. limit, offset
3. first, after```
pagination meta 정보는 선택한 형태에 따라 아래 위치에 있어야 합니다
```1. page, size or limit, offset
type EntityPagination {
  items: [Entity],
  totalCount: Int!
}

2. first, after
type EntityConnection {
  edges: [EntityEdge]!
  # totalCount 는 pageInfo 안에 위치합니다
  pageInfo: EntityPageInfo
}```


아아... 컨벤션이군요 ㅎㅎ 저희는 Production Ready GraphQL의 Schema cheatsheet 를 일단은 공통으로 쓰고있어요. 사내에 아직 컨벤션 문서는 없습니다 ㅎㅎ

과도기 적으로 적용한 스키마가 있어서, 기존 스키마에는 totalCount 의 이름이나 위치가 여러군데 퍼져있거든요 ㅎㅎ 그래서 이런거를 통일하는 룰을 정했는데, 팀내 공유는 잘 안되더라구요 ㅜㅜㅎㅎ

Production Ready GraphQL 은 한번 구매해서 확인해볼께요~ 감사합니다

스키마 기반으로 커뮤니케이션하는 문화를 만들어나가는게 참 좋은데 ㅠㅠ 결국에는 커뮤니케이션도... 개발하는 방식과 툴에 맞춰서 따라가게 되는거 같습니다.

PRG에 Schema Design Cheatsheet가 딱 원하시는 모양일거같네요 ㅋㅋ

네 그렇더라구요. 스키마 기반 커뮤니케이션을 해보다보니 가장 어려운게 마인드 셋을 바꾸는 거더라구요. 기존에에 "일단 한번 API 대충 만들어보고 적용해가면서 바꿔보죠" 라는 생각을 가지신 분이 있었는데, 커뮤니케이션 해보다가 포기했었습니다 ㅜㅜㅋㅋ