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

GraphQL Korea

apollo client 쓰시면 apollo-link-log 같은거 끼우셔서 request log 찍어보세요

실제로 client 요청 두번 날라갔다면 variable 차이가 있을거같습니다

variable 차이라는 말씀은 mutation 의 variable 말씀하시는건가요?

아니면 mutation 호출이 명시적으로 두번 일어났거나… 어디서 왜 호출했는지 알아야 하니 클라에서 발생한건지를 클라이언트나 네트워크 로깅해서 확실히 알아야 할 것 같습니다

그냥 브라우저 네트워크 탭에서 확인해보신다거나

네 서버 미들웨어단에서 graphql 필드 이름과 args 를 로깅하는데 두 번 로깅된 내용은 모두 같습니다 ㅠ

그거 fetch 요청 크롬 디버거에 붙던가요 붙는거로 기억하는데

네 디버거 붙는데 이 따닥이 항상 발생하는게 아니라 2만번중에 3번 발생한거라 재현이 어렵네요 ㅠ

2만번중에 3번이라는게.. 스트레스 테스트 하듯이 해서 그 빈도로 재현이 계속 되는 상황인가요?

아니요! 프로덕션상황에서입니다

서비스 오픈 후 3일동안 2만번의 요청에서 3건이 발생했는데 결제와 연결되어있는거라 조금 민감해서요. 물론 DB 락을 걸어서 해결해야겠지만 왜 이런 현상이 일어나는지 궁금하네요

클라이언트 로그까지 다 남기신게 아니면 원인 정확하게 잡는건 어렵지 않을까용… ㅋㅋ;

errorPolicy에서 재시도 설정한거 딱히 없나요

errorPolicy 를 all 로 설정해놓은거 말고 제가 따로 커스터마이징 한건 없어요

axios 이슈 관련에 post 요청이 랜덤하게 2번 날아간다는 이슈가 몇 개 있는데 apollo 는 내부적으로 axios 를 쓰는것 같지도 않고…

네… 사실 고런 요청은 얼마든지 있을 수 있다고 생각해서 한 세션에서 중복요청 처리할 수 있도록 로직을 짜는게 맞다고 생각해요

일단 apollo 가 문제일것 같진 않네요.

아하 넵 감사합니다 조금 더 파봐야겠네요

그렇게 중첩하면 결과적으로는

{posts{author{posts{ 까지의 쿼리가 나가겠군요. GraphQL 이라고 특별히 문제생기진 않고, 예상하실 수 있는 일반적인 문제들은 있습니다.

<https://developer.github.com/v4/explorer/> 여기, 깃헙을 사용해 보며 감을 익히고 있는데요, 이 사이트의 스키마 전체를 보는 방법이 있나요?

SDL이 좋으신가요 visualized 된게 좋으신가요

SDL: <https://www.npmjs.com/package/@octokit/graphql-schema>

Visualization: <https://apis.guru/graphql-voyager/> 에서 Change schema -&gt; GitHub

원래 GraphQL API endpoint 있으면 introspection query 라는걸 날려주면 스키마 데이터 얻을 수 있어요

제가 붙여넣은 형식이 SDL 인가보네요. SDL이 좋습니다. 비쥬얼라이즈드된 것 보니까 눈돌아가긴 하네요. :slightly_smiling_face:
introspection query 의 결과는 SDL이 아니라 json 같던데 이걸 다시 SDL로 바꾸는 방법도 존재하나요?

네 graphql-js 라이브러리에서 introspection result 를 통해 GraphQL Schema를 빌드하시고 print 하시면 됩니다

참고하실 수 있는 코드:

<https://github.com/cometkim/gatsby-plugin-typegen/blob/master/src/workers/emit-schema.ts>

답변 감사합니다! 좀 더 익혀보겠습니다.

네, 익숙하지 않아서.. 합쳤습니다.

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

<https://graphql-rules.com/rules/mutation-business-operations>

조금 verbose 해도 CURD 보다 더 나아가 비즈니스 로직을 설명할 수 있는 뮤테이션 스키마를 갖는게 좋다고들 말합니다

<http://graphql-rules.com|graphql-rules.com>  너무 좋네요 정독중입니다 감사해요!!

API가 추가될때마다 머리가 복잡하긴해요 ㅠ GraphQL을 통해서 엔드포인트 단위에서 모델 단위로 멘탈 모델이 바뀌는데, 이 부분에 대한 공감대가 없으면, 서버 개발자는 엔드포인트 단위로 Change Log를 공유하고... 클라 개발자는 그 Change Log를 기반으로 무슨 모델에 뭐가 바뀌었는지를 찾아야해서요 ㅠㅠ

예:
• 서버 개발자: GET /users에 `nickname` 필드가 추가됐어요~
• 클라이언트 개발자: ??? User 모델에 `nickname`이 추가된건가?? 다른 엔드포인트의 User 타입은????

그래서 모델이 하나로 통일되어야하는데... 이 부분에서 서버 개발자분들은 디자인 기획을 보고 필요한것만 Subset을 내려주셔서 복잡해질때가 많을거같아요. 커뮤니케이션 방식을 바꾸어야하는거죠.

아 그렇겠군요. 답변 감사합니다!!

get 요청과 post 요청을 분리해서 처리할 수 있어보입니다!

아! 그렇군요. playground는 get이고 query ep 가 post 겠네요. 감사합니다.

이 세상에 바보같은 질문은 없어요 ㅎㅎ 질문 감사해요~~

렌더링에 관여하지 않는다면 `useApolloClient` 를 사용해서 `client.query` 를 쓸수도 있습니다.

type-safe한 framework을 사용하시면 좋을거같네요 ㅎㅎ

• graphql-tools + graphql-code-generator
• nexus.js
• type-graphql
살펴보시면 될거같아요.

type-graphql docs를 보니 추천해주신 세 framework 중 하나를 쓰지 않고, React.FC&lt;proptypes&gt;로 쓸 때처럼 간편하게(?) generic으로 해결하는 방법은 없나 보네요ㅜㅠㅠ

아마 graphql-tools나 nexus를 도입하게 되지 않을까 싶습니다 감사합니다:slightly_smiling_face::upside_down_face:

타입스크립트 이해도만 충분하시면 graphql-js 에 대한 타입 추론을 직접 작성하셔도 됩니다.

이미 타이핑이 있고 타입파라미터도 받을텐데.. 얼마나 잘 되있는지는 모르겠네요

프래그먼트를 사용하지 않으면 데이터가 잘 표시됩니다. 이러면 안되는데 :sweat:
한번 다시 체크해보면서 해봐야겠어요

헐 해결이 됐는데 왜 됐는지 모르겠네요 이런

id 가 필요 없는 객체에 `id: ID!` 필드를 정의했고, 그러다보니 non-nullable 인데 nullable 한 값이 들어가서 오류가 발생했습니다. 그래서 해당 필드를 제거하니 잘 나오네요

다만 상황이 다시 달라진게 이전과 같이 `null` 이 표시되지 않고 RelayNetworkError 를 throw 해주네요 훔

혹시 relay env 설정 뭐 특별한거 있나요

흠. 아니용 별도로 추가한건 없습니다 :thinking_face:

필드 타입은 `[Product!]!` 가 맞는거죠?

그럼 절대 null 로 가면 안되는거신데

네 맞씀다 스키마에도 `[Product!]!` 로 해두었어요 훔

재현되면 다시 보시죠 ㅋㅋㅋㅋ :thinking_face: :thinking_face:

```// schema.graphql
type Query {
	list: ListConnection!
}```
스키마에서 Query `list`가 `ListConnection!` 타입 이니,
resolver에서도
```		list: () =&gt; {
			return ListArr; // return List type
		}```
`ListConnection!` 타입에 맞춰서 return 하셔야 합니다.
```	pageInfo: PageInfo!
	edges: [ListEdge]```
뭐 가령..

```		list: () =&gt; {
           ...
			return { pageInfo, edges };
		}```


schema과 resolver의 리턴 타입이 다르면 안되는군요. 감사합니다!

그렇다면 `pageInfo` 를 resolver의 `Query.list()` 대신 `ListConnection.pageInfo()` 에서 직접 구현할 수 있는 방법이 있을까요?

음 아마도 의도하신바가 pagination인 듯 한데

```list: async (...) =&gt; {
   const pageInfo = await buildPaginate(...);
   const edges = await findEdges(...);

   return { pageInfo, edges };
}```
이런식으로 구현될 것 같은데 원하는 답이 맞으실런지 모르겠네요 ㅎ

아 Query 에서 pagination을 구현하셨네요

저는 schema 에서 Connection Interface를 만들어서 구현 했었는데 resolver에서 리턴 타입 맞추기가 까다롭더라구요 :disappointed:
동준님이 알려주신 방법을 보니 타입 맞추기에 훨씬 나아 보이네요~ 감사합니다 !!
```// schema.graphql

interface Connection {
  pageInfo: PageInfo!
  edges: [Edge]
}

type ListConnection implements Connection {
  pageInfo: PageInfo!
  edges: [ListEdge]
}
...

// resolver.ts

Const resolver = {
  Connection: {
    pageInfo: () =&gt; {}
  },
  ...
}```

:wink:  사실 저는 TypeScript를 사용하고 있어서요.

<https://typegoose.github.io/typegoose/docs|typegoose>, <https://github.com/graphql-compose/graphql-compose-mongoose|graphql-compose-mongoose> 를 사용하고 있습니다.
기본적인 find paginate 같은것들은 구현이 되어있어서 업무를 많이 줄여줍니다.

저도 타입스크립트 배우고 써보려고 하니  많이 어렵네요ㅠㅠ :sob: 꿀 팁 감사합니다! :smile: 그리고 코로나 조심하세요!! :mask:

pageInfo는 first, last, after, before같은 connection arguments에 의존적이라서 Connection 타입 리졸버에서 하기 힘들거같아요 ㅠ 저는 요렇게 유틸 함수 만들어서 사용하고 있어요. 괜찮으시면 써보시면 좋을거같네요 ㅎㅎ

<https://github.com/tonyfromundefined/graphql-connection-resolver>

오 참고하겠습니다!! 감사합니다. :slightly_smiling_face:

tsconfig compilerOptions.target 설정 어떻게 되시나요

“using `@Args` with `@InputType` or without `@ArgsType` ” 관련 이슈일까 싶은데 혹시 짐작가는 코드 있으신가요

참고: <https://github.com/MichalLytek/type-graphql/issues/12>

보통 저는 graphql 데코레이터 잘못 import 했거나 하지 않았을 때 나오더라구요.

변경, 추가하신 entity, resolver, loader 다 보면서 데코레이터 제대로 달려있나 확인해보세요

<@UNZ83BVGF> <@UN4AJARCN> Enum Type에서 registerEnumType을 안하고 Field에 선언한게 있어서 발생한 문제였네요. 감사합니다!

@nestjs/graphql이 type-graphql이랑 거의 API가 비슷하군요. 이러면 다른 프로젝트에서는 굳이 nest를 써야하나 싶은 생각도 드네요.

음… 이건 GraphQL 문제가 아닐가능성이 클거같아요 ㅎㅎ

typescript 구문이 너무 복잡해서 indentation은 애초에 autoFix 안하고 있습니다.

<https://relay.dev/docs/en/testing-relay-components>

<https://medium.com/@bangkit.ilhamz/testing-react-relay-component-30f03c026f4a>

<https://github.com/sibelius/relay-workshop/tree/master/solutions/11-testUseFragment>

relay env 는 글로벌 데코레이터로 해주면 될거고

msw 도 어떻게 어떻게 하면 될 것 같아서 알아보다가 영 아닌거같아서 ㅜㅜ

react, react-dom 버전 피닝 하셔야하고

`useTranslation` 같은 CM 은 아직 어려운 것 같아서 서스펜스만 사용해보려고 하고 있습니다 그래서 따로 버전 피닝은 안했구요

음 일단 fragment ref 를 어떻게 만들어 넘겨줄지 고민해봐야겠네요

container vs presentational component 를 나눠서 개발하시는게………..

굉장히 까다롭네욤.. 테스트 케이스 추가해보려는 시점부터 experimental 의 위험성을 몸소 체감하고 있는 것 같습니다 :sweat:

아뇨 experimental 의 문제는 아닌거같은데 ㅋㅋㅋㅋ

기능적인 것 보다 문서나 리소스 측면에서 그렇다고 생각했는데 아니였을까요

분명 뭔가 테스트 할 수 있을 것 같은데………. 말씀해주신대로 container 와 presenter 나누는 것은 좀만더,, 고민해보고 난 뒤에 채택하고 싶습니다 ㅠㅠ

릴레이 작동방식을 생각해보면요

fragment container 로 의존성 선언을 컴포넌트에 가깝게 배치하고 컴파일러가 분석해서 아티팩트를 만들어준다

이 아티팩트는 쿼리 렌더러를 기준으로 최적화 되어 있다

쿼리 렌더러 기준에서 볼 때는 composition 이 다 되어 있거든요

다른 테스트는 모르겠으나 적어도 스토리북이랑은 접근방식이 좀 충돌하죠

컴파일러랑 바벨 트랜스폼을 스토리북 쪽에도 세팅해주셔야 할 거고요

.storybook/main.js 여기서 웹팩 좀 뜯어 고치셔야 할거고

근데 기본적으로 릴레이 기본전략이 fragment 를 container 에 사용하는거니 container 를 스토리북에 안올리면 된다고 생각합니다

코드가 선언적으로 작성될 수록 기계적인 유닛테스트는 가치가 떨어지니 테스트는 통합 테스트 위주로 작성하시는게 나을거고

jest 도 뭐 설정할게 많을테니까요

요컨데 설정때문에 고생하기 싫으시면

cypress나 jest puppe 같은 real dom 환경 올리고 e2e로 커버하시는게 낫지 않나

말씀해주신거 듣기만해도 벌써 소름이 돋긴 하네요

cypress 도 msw 처럼 요청 인터셉트하는 인터페이스가 있을거에요

&gt; 코드가 선언적으로 작성될 수록 기계적인 유닛테스트는 가치가 떨어지니 테스트는 통합 테스트 위주로 작성하시는게 나을거고
이 부분에서 생각을 좀 더 하게 되는 것 같습니다 :pray:

확실히 기존에는 잘 요청해서 잘 가공하고 그걸 잘 써먹는지에 대한 단위 테스트가 필요했는데

API가 좀 맘에 안들 수 있는데 그럼 Jest environment 커스터마이징 하셔서 puppeteer 나 playwright 환경 만들어서 활ㅇ용할 수도 있고

container가 나눠질 때 컨테이너에 로직이 많이 들어가면 테스트 필요할 수는 있는데 보통은 외부 서비스나 훅으로 분리되거나 릴레이처럼 완전 managed 되기도 하니까

그니까 예를들어 react-redux 의 mapStateToProps -&gt; container 같은거 생각해보시면

셀렉터를 적절하게 prop 에 매핑해주는데서 역할이 끝나고 세부적인 부분은 각 셀렉터단에서 이미 테스트가 되어 있으니

mapStateToProps 는 타입 에러를 다 잡았다는 전제하에 테스트할게 거의 없죠

(데이터 컨테이너라는 레이어가 분리되었을 때)

실제로 돌려봐도 커버리지 차이도 거의 안날걸요?

아니 정확히는 안나게 만들어야 하죠 ㅋㅋ

아무튼 다시 릴레이로 돌아와서

useFragment 의존성은 역전되어 있어서 실제로 세부 동작은 composition 하는 쿼리 렌더러가 쥐고 있으니

네 뭐 컴포넌트에서 신경쓸 부분은 아닌거같고 그냥 모킹하면 될듯

experimental 얘기를 하셔서 혹시 equiv 이 없나..? 싶어서 찾아보는 중…

근데 없더라도 메뉴얼 모킹하는게 크게 어렵진 않ㅇ르거 같긴해요

감사합니다. 말씀해주신 내용들은 단위로 꼭 작성해야 할 경우에 해당되는게 맞을까요?

내부엔 테스트코드 다 있네요 (몇몇 인터널 패키지 의존성이 보이긴 하지만)

참고해보시면 단위 테스트도 할 수 있을 듯

<https://github.com/facebook/relay/blob/master/packages/relay-experimental/__tests__/useFragment-test.js>

근데 저라면 가능한 특정 레이어는 “테스트를 안해도 되도록” 만들려고 노력(발버둥) 해볼 것 같습니다.

저도 그쪽으로 생각이 들기 시작했습니다 ㅋㅋㅋ.. 뭔가..

그냥 e2e 잘만드는게 이터레이션 조금 느려도 활용가치는 높아서

아예 서버랑 합심해서 DB까지 묶어서 멱등하게 돌아가는 테스트 배드를 만들어버린다거나 ㅋㅋㅋ

&gt; 코드가 선언적으로 작성될 수록 기계적인 유닛테스트는 가치가 떨어지니 테스트는 통합 테스트 위주로 작성하시는게 나을거고
이거 오해가 있을 것 같아…

what/how가 잘 쪼개져있으면 what에 대해서 기계적으로 커버리지를 높이는건 별 의미가 없다는 의미였습니다. (마치 assert A is A 같은…) 애초에 100% 선언적인 코드는 스냅샷만 찍어도 커버리지 100%가 나와요. (브랜치가 하나일 때)

지금 사용하고 계신 쿼리 예시가 있으면 더 답변이 수월할 것 같습니다

넵, 이 정도 예시면 될까요ㅜㅜ

스키마가 추상화 단위가 잘 이해가 안되긴 하는데… 이건 잘 얘기하셔서 스키마를 더 의미있게 만드시는게 좋을 것 같습니다 예를들면
```interface PetInfo

type DogInfo implements PetInfo
type CatInfo implements PetInfo```
만 하셔도 쿼리는
```query Pets {
  pets(filter: { state: { ... } }) {
    id
    ...on DogInfo {
      # ...
    }
    ...on CatInfo {
      # ...
    }
  }
}```
이런식으로 더 깔끔하게 갈라질겁니다.

&gt; *Product‐centric*: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that.
&gt; 
&gt; *Client‐specified queries*: Through its type system, a GraphQL server publishes the capabilities that its clients are allowed to consume. It is the client that is responsible for specifying exactly how it will consume those published capabilities. These queries are specified at field‐level granularity. In the majority of client‐server applications written without GraphQL, the server determines the data returned in its various scripted endpoints. A GraphQL query, on the other hand, returns exactly what a client asks for and no more.
<https://spec.graphql.org/June2018/#sec-Overview>

이건 GraphQL 스펙에 명시되어있는 설계 원칙입니다.

&gt; 백엔드팀에게 개선요청했으나, graphql은 필요한 데이터만 뽑아쓰고, 필터링 할 수 있기때문에 프론트에서 가공하는게 맞다.
이런 사고방식은 전반적으로 케이스 스터디 등 학습과정을 통해 개선할 필요가 있을거에요

와 링크 감사합니다. 저도 스키마 추상화 단위가 가공하기 어려운점이라고는 생각했는데, 테이블 구조상 변경하기는 어렵다고 합니다. (불가능한 것인지 어려운것인지는 판단하지 못했습니다) 팀과 같이 공유해서 ‘잘’ 활용해보도록 하겠습니다!

그리고 사실 서버 개발 편의를 위해 DB모델을 날것으로 노출한다고 쳐도 aggregate이 좀 필요해질 뿐이지 저렇게 API 사용하는데 조건이 과도하게 붙는 경우는 적을 것 같은데….

클라이언트에서 쓰기 불편한 GraphQL API는 존재의의가 많이 희미하다는걸 양측이 인지하는게 좋은 것 같아요. GraphQL 도입 초기에 백엔드 개발자가 그걸 인지하기 쉬운 방법은 스스로 클라이언트 프로토타이핑을 하거나 데이터 쿼리 요구사항을 처리해가면서 개밥먹기 하는거 일 듯 합니다.

로직이 있다면 스키마에 잘 드러나는게 좋고, 애초에 별 로직이 없다면 첨부터 자동생성해주는 솔루션을 도입하는게 여러모로 편하실겁니다. (ex. Hasura, Graphile)

와우 어떤 부분을 모르는걸까 너무 고민했는데 답변 너무 감사합니다. 똑똑하게 조율해보겠습니다 :+1::slightly_smiling_face::+1:

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

요고 말씀하시는거죠??

아 뭐 스코프가 어느정도 있는 친구인가요?

말씀해주신 요구사항만 놓고 보면 맥락이 주변으로 갈 일은 아무래도 보통 없을거같긴 한데

음 fragment랑 colocation되어있는 컴포넌트를

props만 바꿔서 재사용할수있나요??

음 예를들면, 글 콘텐츠를 담는 컴포넌트가 있고, useFragment를 안에서 쓰는데요. 그 컴포넌트를 미리보기에서 쓰려면 어떻게하는게 좋을지? 에요 ㅋㅋ

제가 생각한건 그냥

```const data = useFragment(..., <http://props.post|props.post>);

// 가상의 폼 상태
const post = useForm({
  init: <http://data.post|data.post>,
});
const optimisticResponse = opt_response_from_input(post);
const updatePostMutation = useMutation(...);

const handleSubmit = () =&gt; {
  updatePostMutation.commit({
    variables: post,
    optimisticResponse,
  });
}

&lt;Form onSumit={handleSubmit}&gt;
  &lt;PostInput post={post} /&gt;
  &lt;Preview post={optimisticResponse} /&gt;
&lt;/Form&gt;```
뭐 간단한 CRUD라 치면 얼추 이런식일까요

일단 input 상태는 apollo 처럼 배치처리할 거 아닌 이상 굳이 relay store 랑 연관될 이유는 없을 것 같고, 커밋만 잘 신경써주면 되지 않나요?

Apollo 같은 경우는 뭐 `@exports` 디렉티브 같은거 쓰려고 일부로 스토어에 우겨넣는 경우가 종종 있긴 한데

&gt; 그 컴포넌트를 미리보기에서 쓰려면 어떻게하는게 좋을지?
이건 그냥 컴포넌트 잘 나누면 해결될 것 같아요. 그냥 상태없는 컴포넌트 하나 두고 props을 다른걸 주는식으로 간단하게 조합하시면...

제가 니즈가 있는건 아니고 동료 니즈라서 ㅋㅋㅋ 한번 해봐야겠네요 ㅋㅋ

CM features 나 Suspense 기능에 어느정도 의존하고 계신가요?

현재 react latest 에서도 되는 Suspense 외에는 CM feature 를 쓰고 있지 않습니당

<https://github.com/relay-tools/relay-hooks/issues/5>

stable vs experimental 이라는 label 에서 불안감을 느낄 수는 있지만 experimental 쪽이 "공식 지원"에 더 가깝습니다. relay hooks 는 커뮤니티에서 API 수준에서 따라가는거고 under the hood 동작이 같진 않아요

결과적으로 이중 마이그레이션 하시게 될 텐데....

CM과 호환되지 않는 레거시 API/라이브러리에 치명적으로 의존해서 어쩔 수 없는 경우 아니라면 저는 고려하지 않을 것 같습니다

오히려 미리 올려놓고 비호환 라이브러리를 거르는게 도움될 수도 있어요... 이건 다른 커뮤니티에서도 레거시 context api 치울 때 비슷한 일이 많이 있었죠

메타인지를 갖추는 것도 중요하다고 생각합니다만, 그렇다고 꼭 CM 기능들을 다 써야할 필요도 없습니다.

제 의견은 릴레이 최신 기능 빨리 확실하게 쓰고싶으시면 공식에서 머물러계시는게 더 좋습니다. 꼭 CM 관련 아니더라도 뭐 deleteFromRecord 라던가 릴리즈 될 때마다...

음 확실히 “experimental 이라는 label 에서 오는 불안감” 도 적잖게 있었던 것 같습니다. 곰곰히 생각해보니 추후에 “이중 마이그레이션“을 피하는게 더 나을 것 같네요. 감사합니다!

저는 experimental로 옮기려고 생각중이였는데요… 혹시 문제가 있는 부분이 많나요??

아뇨 릴레이의 기능을 훅으로 깔끔하게 쓸 수 있는 경험이 좋았습니다. 걱정했던 부분은 experimental 이라는 것과 제가 정확하게 알지 못하고 쓰는게 우려되어서 질문했었어요

다만 IE 지원해야 하는,,,, 프로젝트에서 오류가 발생하거나 not responding 이 발생해서 아폴로를 사용하게 되었습니다.

RelayEnvironmentProvider 내에서 뭔가 발생하는데 파악할 수 없었습니다. ㅠㅠ

엇 react@experimental 이 IE 지원 보장하던가요

개인적인 의견: DynamoDB... 힘듭니다 ㅠㅠㅠ RDBMS나 MongoDB로 직접 GraphQL 서버 구현하시는걸 추천해요

백엔드 언어는 어떤거 사용하시나요??

javascript로 aws의 lamda를 사용하고 있습니다.

그렇군요 역시 dynamoDB는 쉽지 않군요..
답변 감사합니다!!

저는 직접 Apollo Server + MongoDB로 서버 개발하고 있습니다 ㅎㅎ AppSync는 너무 AWS에 종속되는거같기도하고 DynamoDB가 힘들더라구요 ㅠ

관리형 Subscription이 좋긴한데, 개발 속도 측면에서 직접 뚝딱뚝딱 구현하는게 더 빠른거같아요 ㅋㅋ

답변 감사합니다. 덕분에 개발 방향성을 생각해 보게 되었습니다 ^^

그럼 지금은 limit + offset으로 하고계신가요??

아니면 Apollo에서 미는 심플한? Pagination으로 구현중이신가요? (정확한 이름이 기억이 안나네요 ㅠ)

훔. Relay 사용과 무관하게 커서 기반 페이지네이션의 이점을 누릴 수 있겠네요

아직은 구현 전 단계인데요~ 우선 이런 Pagination UI 를 지원해야해서 limit & offset 기반을 생각하다가 Relay compliant schema 로도 가능할까 싶어서 찾던 중에
누가 이 글을 알려주면서 가능하다고 하기에 알아보려던 참인데요
<https://artsy.github.io/blog/2020/01/21/graphql-relay-windowed-pagination/>
우선은 어떤 이점이 있을까 고민해본후에 진행하려던 참이었습니다

저 글은 effortless하다면서 굉장히 effort가 드네요;; ㅋㅋㅋ

일단 제일 걸렸던 점은 이 방식은 totalCount를 어떤 식으로든 줘야하는데 저희만의 구조를 따로 정의하느냐 아니면 relay 표준을 따르느냐(totalCount 같은건 다 어떻게 주라고 되있더라고요) 고민이 좀 되었어요

페이지 넘버 기반으로 뷰를 보여주셔야한다면 굳이 Connection 해야하나 싶기는하네요. 커서 기반이 성능은 더 좋은거로 알고있어요. 근데 아이템 갯수가 적다면 큰 이점은 없을거같아요

저희는 무한스크롤 + Relay라서 Connection으로 편하게 쓰고 있기는 해요 ㅎㅎ

그렇군요 저희가 추후에 혹시나 relay로 마이그레이션 하기 쉬울 수 있다는 것 빼곤 없겠군요

totalCount 만 어떻게 전달할 수 있다면 페이지 넘버 기반으로도 쓸 수 있으니 … 저였다면 어떻게 ~의견이 바뀔지 모르니~ 디자인이 개선될 지 모르니 그냥 커넥션으로 한다 (+ 알잘딱으로 totalCount 넣어준다) 로 할 것 같습니다

저희도 외부 공개 API 중에서 limit &amp; offset (정확히는 페이지 번호) 로 제공되는 API가 있는데요

그걸 Connection으로 래핑하는 함수를 만들어서 편하게 쓰고 있어요

두 분 다 의견 감사드립니다!! 다양한 의견을 들으니 좋네요 ㅎㅎ

데이터셋이 좀 커지면 커서기반이여야 디비가 스트레스를 덜받아용

<https://jojoldu.tistory.com/528|https://jojoldu.tistory.com/528>

Apollo Client 3 는 커서기반과 오프셋기반 페이지네이션 헬퍼를 둘 다 지원합니다

아 그리고 도입은 조금 힘들지만 한번해두면 클라이언트 사이드에서는 커서 기반일 때 캐시 관리가 데이터 추가/삭제에 대해서 자동화가 훨씬 수월합니다. 오프셋기반은 업데이터 함수가 좀 길어지는 경향이 있어요.

답변 감사드립니다 ^^
네 저도 커서기반의 성능이점을 어필하면서 회사분들과 상의를 했었는데 페이지 넘버 기반이 꼭 필요하다고 하셔서 어쩔 수 없이 이렇게 가게 되었네요
딴 얘기지만 Apollo Client 3 이 좀 불안정하다고 한달전까지 계속 얘기를 들었었는데(주로 Reactiflux 채널 평판이긴 합니다) 혹시 사용하고 계시다면 불편한 점은 없으신가요?
2.6 대비해서 기능추가도 딱히 없다고 들었었거든요

내부적인 구조 개선 위주로 많이 일어났고, 기능도 꽤 바뀌었죠 (Custom resolver -&gt; Reactive variables 이라던가, 캐시 폴리시 기반 캐시 제어 등)

아무래도 Apollo Client 2 자체가 버그 투성이고 유지보수도 잘 안됐는데 이제는 완전히 3기반으로 넘어간지라... 유지보수 생각하면 마이그레이션 빨리하는게 좋긴 할겁니다

번들사이즈도 크게 차이나구요

근데 저도 마이그레이션은 안해봤고 새프로젝트는 URQL 쓰는중 ㅋㅋ;

:sob::sob: 일단 마이그레이션은 시간날때 하긴 해야겠네요 urql 도 많이 쓰더라고요

혹시 혼자 개발하시나용? 팀 상황은 어떠한가요?

겪으신 문제, 풀어야하는 문제, 만드는 제품 종류, 팀 상황 등등에 따라 필요한 내용이 달라질 것 같아서... 가능하면 케이스를 조금만 더 구체적으로 소개해주시면 좋을것가탕요

그리고, GraphQL 이라기 보단 GraphQL과 잘 어울리는 ORM에 대한 질문이라고 생각되는데 의도하신게 맞을까요?

<@UN4AJARCN> 님 안녕하세요!
항상 좋은 아티클들 공유해주셔서 감사합니다. 덕분에 매일 많이 배워갑니다.
우선은 질문 주신거에 답변을 드려보겠습니다.

• 혹시 혼자 개발하시나용? 팀 상황은 어떠한가요?
기존에 셋업해두셨던 개발자분이 계셨는데 최근에 퇴사해서 지금은 혼자서 개발업무를 맡고 있습니다. 현재 디자이너와 개발자를 추가채용중에 있으며, 기획, 디자인 개발은 거의 혼자 하고 있다고 보시면 됩니다!
서비스는 총 3개가 있고, 1개는 prisma2 나머지 2개는 prisma1으로 개발이 되었으며, 처음 셋업 당시보다 사용자나 매출이 10배 이상 증가하면서부터 prisma1에서 여러가지 문제들이 발생했고, github issue라던가 문의 해보았는데 prisma1에 고질적인 문제라고 듣고, prisma2를 사용하라는 이야기만 들은 상태입니다.
신사업팀이다보니 빠른 검증 후 계속할지 아닐지가 중요하여 각 서비스마다 서버, DB 등 모두 각각 생성되어있으며, 마침 어느정도 검증이 되어 서비스3개에 대하여 통합하기로 협의가 되었고, 모든 구조를 제로베이스에서부터 다시 쌓아올리게 되었습니다. 그러면서 기존에 prisma1이 갖고 있던 문제도 이참에 해결하려고 하는데 가장 큰 문제는 리소스가 너무 없다보니 prisma2가 가장 나을 것 같다는 판단은 하였지만, 또 다른 이슈들이 있는가 싶어서 이렇게 질문을 드렸습니다!

• 겪으신 문제, 풀어야하는 문제, 만드는 제품 종류, 팀 상황 등등에 따라 필요한 내용이 달라질 것 같아서... 가능하면 케이스를 조금만 더 구체적으로 소개해주시면 좋을것가탕요
팀 상황은 위 내용으로 충분히 전달이 될 것 같다고 생각되어, 말씀주신 다른 부분에 대해서 적겠습니다.
만드는 제품은 3개 서비스 모두 이커머스 관련 개발을 진행하고 있으며, 상시몰과 폐쇄몰 기반으로 개발되어가고 있습니다.

prisma1을 사용하면서 겪었던 문제 중 대표적으로는 아래와 같은 사례들이 있는 것 같습니다.
1. schema 추가나 변경등으로 prisma deploy 시 반영이 되지 않아 새로운 이름으로 db를 생성하고, deploy한 후 기존 db를 dump해서 마이그레이션해야하는 문제
2. 정산이나 통계자료 처럼 쿼리가 복잡하고 데이터양이 많아지면 문제가 발생하며, 쿼리튜닝이나 서버 스케일업, 서버에서 메모리와 관련된 설정을 수정하더라도 계속해서 이러한 에러가 발생합니다. `java.util.concurrent.RejectedExecutionException: Task slick.basic.BasicBackend$DatabaseDef$$anon$3@34f239f rejected from slick.util.AsyncExecutor$$anon$1$$anon$2@7bf7de3f[Running, pool size = 9, active threads = 9, queued tasks = 1000, completed tasks = 1294690]`
위 내용에 대해서는 prisma1에서 문제를 해결하지 않고, 이러한 문제들을 해결한 부분이 prisma2에 진행되었다고 하여 prisma2를 이용하라고 했습니다.

• GraphQL 이라기 보단 GraphQL과 잘 어울리는 ORM에 대한 질문이라고 생각되는데 의도하신게 맞을까요?
넵 ORM과 같은 graphQL을 더 잘 사용하기 위한 구성에 대한 질문이 더 맞는 것 같습니다. 내용에 적어둔 것 처럼 prisma2를 바로 사용하기에는 아직 많은 정보가 없어서요.ㅠㅠ

일단 생각나는 의견으로는

• Prisma 1은 Scala Sangria 기반으로 되있었던지라 빠르게 기능 제공할 수 있었지만 반대로 구성 문제가 생기거나 혼자 못고치는 부분이 많았어요. Prisma 2는 이 부분 많이 개선하고 지금은 Prisma 1 기능도 거의 다 따라잡은걸로 보입니다.
• 문제가 됐던 마이그레이션은 스키마를 기반으로 하는 "선언적 마이그레이션" 전략인데 Prisma 2에서도 아직 개발중입니다. 일단 그냥 다른 여타 프레임워크들 하듯 별도의 마이그레이션 도구를 사용하도록 가이드 하고 있어요. (Prisma 클라이언트를 그대로 써도 되기 때문에 기능개발하듯이 수월하긴 할거에요)
• 거의 혼자 개발하시게된 상황만 놓고보면 서비스들 통합하는건 좋은 선택일 것 같아요.
• 다만 ORM의 경우 어느쪽이던 의견이나 문제점들이 있는 상황은 피할 수 없을 것 같아요. 저는 반대로 백엔드에 레거시 TypeORM 코드들 때문에 골치아픈 상황이 있는데, 이거 보면서 느낀점은 이 부분은 아키텍처 수준에서 정리하고 시작할 필요가 있다는 것입니다. 전통적인 접근방식으로요
• Prisma 던 TypeORM이던 Sequelize 던 서비스 인터페이스 정의 뒤로 가려서 추상화에 의존하도록 하고 의존성 주입 패턴을 적극 활용하는게 좋을 것 같습니다. TypeORM 에 싱글톤 인스턴스 그대로 import 해서 쓰거나 Prisma 클라이언트 그대로 컨텍스트에서 그대로 빼다 쓰기 편하긴 했는데 나중에 돌아보면 다 패착이였던 것 같아요.
• 정돈만 잘되면 이상적으로는 어떤 ORM을 의존하던지 GraphQL 서버 쪽은 상관없게 됩니다. 완벽한 ORM을 고르는 것 보단 완벽하지 않은 ORM 골라놓더라도 변경이 필요할 때 API나 비즈니스 코드에 영향이 없도록 하는게 중요한 것 같아요.
일단 저도 프론트엔드 위주로 개발하고 있고 ORM들을 헤비하게 써보질 않아서 답변드리기 좀 애매한데.. 다른 분들도 보시고 답변주시거나 실사용 후기를 던져주시면 좋을 것 같습니다.

Aggregations 기능도 몇달전인가 릴리즈된 걸 본 것 같은데 프로덕션 데이터 셋 따로 받아서 스트레스 테스트 구성해보시는 것도 좋을 것 같기도 하고요

좋은 답변 감사합니다. 아무래도 팀빌딩부터 기술스택까지 지금은 빠르게 진행이 필요로 했지만 이제는 어느정도 검증이 끝났고 속도는 조금 늦추더라도 안정적인 방향성을 검토해보려고 하다보니 혼자만의 생각보다는 다른 분들 의견이 많이 궁금했었습니다 ㅎㅎ

그리고 저도 프론트엔드가 메인이다보니 예전 MEAN스택이 대세였던 시절이후로는 거의 처음이라 경험적인 부분에서 많이 약하다는 것도 깨달았습니다 ㅎㅎ 

말씀주신 스트레스테스트도 좋은 방법인 것 같네요 한번 진행해봐야겠습니다

<https://www.slideshare.net/awskr/aws-community-day-2020-reactjs-ssr>

SSR 배포 전략 때문에 질문을 하고자 했는데, 마침 지혁님 여기 계셔서… ^^;

이 채널의 토픽을 보시면 ㅋㅋㅋ 어떤 질문이든 좋아용

아… 죄송합니다.. ㅋㅋ 발표 영상을 보니까 질문사항이 사라져버렸어요.. ㅋㅋ 좋은 자료 공유 감사드립니다 (_ _)

오오… 제가 발표를 잘한건가요?! ㅋㅋㅋ

ㅋㅋㅋ 꼼꼼하게 잘 알려주셔서 좋아요

SSR 바이블 느낌으로 깎은 발표에요 ㅋㅋ 도움얻으셨다니 뿌듯하네요