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

GraphQL Korea

ㅋㅋㅋ 반가워요~~~ GraphQL 죠습니다~~

이제 백엔드 프레임웍들 관건은 relay 스펙을 얼마나 잘 지원하느냐군요.. 일단 Hasura 탈락... ㅋㅋ;

아무래도 미국가는거 정도로 경비가 부담스럽진 않길래 같이 가실분 있으면 고민없이 질렀을텐데요

이런… persistence 역직렬화가 이슈군요. (이거 아키텍처 한계 아닌가)

반갑습니다~~~ GraphQL Code Generator 꼭 쓰세요~~

아래 툴을 말씀하시는 건가요? ^^

<https://graphql-code-generator.com/>

aggregator 뭐시기는 아니네요 3개

[GraphQL] Nexus.js vs. TypeGraphQL.pdf

어제 물어보길 잘했네요. 정말 좋은 자료입니다.

듣고싶네요 ㅎㅎ 모임 신청 열릴때 알려주세요~~

도움이 되셨다니 제가 더 감사합니다~~ ㅋㅋㅋ GraphQL도 관심가져주세요~~

회사에서 작게 쓰고 있는데, 더 관심 갖겠습니다, 시간봐서 소모임도 참석할 수 있음 하겠습니다!:grinning:

좋아요~~ 이번 GraphQL 모임 2월 4일에 열리는데 그때 놀러오세요~

작년부터 GraphQL 모임 너무너무 참가하고 싶었는데 일정이 잘 안맞아서 한번도 못가봤네요!ㅠㅠ 도쿄에서 넘어가야해서 좀처럼 일정맞추기가 쉽지 않네요… :thinking_face: 다음번에는 스케줄 맞춰서 꼭 참여하고싶네요~!ㅎㅎㅎ

앗 ㅠㅠ 서버리스 모임 발표하시는거보고 꽤 오래 한국에 계시는줄 알았어요 ㅠ ㅋㅋㅋ 알겠습니다 ㅎㅎ

ㅋㅋㅋㅋㅋ 어떤점에서 그런가요?

이번에 처음으로 Relay Server Specification을 제대로 맞춰서 서버를 간단하게 짜봤는데요 ㅋㅋ Global Object Identification 위해서

```interface Node {
  id: ID!
}```
구현하는데, 여윽시 타입을 딱딱 알아서 맞춰주네요. TypeGraphQL에서는 어떻게 될지 좀 궁금합니다 ㅋㅋ

<https://nexus.js.org/docs/plugin-connection>

플러그인 지원도 있네요

```objectType({
  name: 'User',
  definition(t) {
    t.implements('Node')
  },
})

objectType({
  name: 'Post',
  definition(t) {
    t.implements('Node')
  },
})

interfaceType({
  name: 'Node',
  definition(t) {
    t.id('id', {
      resolve(parent) {
        // parent: User | Post
      },
    })
  },
})```

그 얘기했던 케이스는 실제로 다형성 타입을 제공하고 싶은게 아니라 그냥 필드 로직을 공유하고 싶을 때 였어요

넵 ㅋㅋㅋ 어떤 뜻이신지 이해했어요

user(id: “id”) 랑 post.author 리졸버가 있는데

이 둘은 root context 에 따라서 타입이 약간씩 바뀌지만

내부로직이나 쿼리 빌더는 많은 부분 공유하도록 작성할 수 있거든요

그럼 그냥 서브 타입 처리하는 리졸버 구현 하나만 작성하고 같이 쓸 수 있겠죠. 테스트 케이스는 달라지진 않겠지만 짜잘한 구현 중복을 줄여주는 경우가 많아서

이게 된다면 확실하게 약을 팔고 다닐 의향이 있습니다

흠... 저는 웬만하면 Resolver 함수를 떼내서 테스트를 하진 않는거 같아요. 뭔가 엄청나게 공통으로 쓰여진다면, 응집력있게 함수로 빼서 Unit Test를 할텐데. 스펙도 계속 바뀌고, 제가 하는 프로젝트가 여러명이 Contribution하는거다보니 함수로 빼다보면 타고타고해서 처음 프로젝트 clone하신분이 이해를 못하시더라구요 ㅋㅋㅋ 그래서 로직에 Duplication이 생기더라도 웬만하면 함수로 안묶습니다.

DataLoader에 들어가는 Batch 함수나 context로 authorize하는 부분이나 몇가지 모델에서 테스트만 하는거같아요

~물론 제가 초보라 ㅋㅋㅋ 테스트를 잘 못해서 그런것도 있습니다~

그치만 혜성님이 어떤걸 하려는지는 100% 이해합니다 ㅋㅋ

뭐 저도 duplication 하는 쪽이 맞는 방향이라고 생각하긴 합니다. 이건 뭐 엣지케이스죠

그냥 “허용이 안되는” 거 자체가

요리조리 메타프로그래밍 하기는 좀 어렵겠구나 라는 인상을 줬어서

네 반갑습니다.. 잘 부탁드려요~

질문 있으시면 꼭 <#CN13FD736|> 채널에 올려주세요 ㅎㅎ

앗 ㅋㅋㅋㅋ 그 이야기는 아니였습니다 ㅋㅋ 혹시 질문 있으시면 커뮤니티를 위해서 꼭 공유해달라는 의미였어요!

네.. 이해했습니다.  친절히 알려주셔서 감사드립니다~~ ^^

사실상 모든 레이어에서 그래프 기반으로 디자인 할 수 있을 것 같은

갯츠비 플러그인 깎는 중인데 길드에서 메일 왔어요 ㅋㅋ <https://github.com/cometkim/gatsby-plugin-typegen>

ㅋㅋㅋㅋㅋㅋ 아하 code generator군요 ㅋㅋㅋ 여윽시 멋지십니다

apollo client 바인딩이 있는건가요?

바인딩이 어떤 뜻인지 알 수 있을까요?

음 그냥 apollo-flutter 라이브러리 같은게 있는가 여쭤봤어요

사전적 의미는 : <https://en.wikipedia.org/wiki/Language_binding>

네. graphql_flutter가 있습니다. apollo client의 개념을 가져와서 만든 건데, client state management하고 link 기능이 제대로 안 되는게 아쉽네요. ㅠㅠ

엄청 기본적인 것들만 구현되어 있구뇽.. 뭐 graphql 은 client 구현하는게 쉽지 않으니

아 구현은 다 graphql 패키지에 있구나

link 인터페이스는 이미 있는 것 같고요

<https://github.com/zino-app/graphql-flutter/tree/master/packages/graphql/lib/src/link>

<https://github.com/zino-app/graphql-flutter/blob/d17b57b52d3cb985a8c8d7025a242bbcddecabfb/examples/starwars/lib/client_provider.dart#L23-L42>

여기 보니까 클라이언트 쓰는 법은 거의 똑같은 것 같으니

옛날 거 apollo-link-state 구현 참고하셔서 저 링크 인터페이스 구현하고 끼워주면 되겠네요

근데 link-state 가 할일이 좀 많아서 만들어주면 엄청 좋아할겁ㄴ디ㅏ

링크 아폴로 클라이언트랑 인터페이스 완전히 똑같은 것 같은데 …

얼떨결에 원래 휴가에 코로나 휴가를 받아서 길게 쉬다가 오랜만에 출근해보니 재택이라고하여…

엇 바환님 안녕하세요 여기 계셨군요

다른게 아니라 사이드플젝으로 이거나 GraphQL 로 말아볼까 싶어서요 ㅋㅋㅋ

검토했었는데 오픈뱅킹 얻어내는 조건이 너무 빡세서 포기했습니다. (많은 서류작업 및 심사 요건 등)

음… 테스트는 간단하게 해볼 수 있는 모양이던데 막상 실사용 심사는 까다롭나 보군요

네 실사 하려면 디비 암호화, 어드민툴, 어드민툴 로깅, 서버실 보안출입 등을 오픈뱅킹에서 원하는 요건대로 해야하고 주기적으로 심사받아야합니다. 그리고 클라우드환경에 대한 요건이 제대로 나와있지 않아 AWS 쓸 때에 어려움이 있을거같습니다. 그래서 작은 스타트업 규모에서 못할 일이라 생각하고 포기했습니다.

감사합니다. 아주 유용한 정보입니다. 설마 싶었지만… 이건 깔끔하게 접는걸로

그래프가 커지니까 확실히 도움 되네요... 머리 속 맥락을 그대로 끄집어 내는 느낌

하지만 스테이터스는 좋다고 떠있음…

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 저희 회사에서 유튜브 하는거에요 ㅋㅋ

인트로 어마어마하던데 악마의 편집 당하신건가요 아니면 ㅋㅋㅋㅋ...

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 악마의 편집점을 제가 준겁니다 ㅋㅋㅋㅋ

내부적으로 만들어서 쓰는 도구라는데... 굉장히 탐나는 군요. Relay DevTools 완전 쓰레기인데 이거로 바꿔주면 안되나 ㅂㄷㅂㄷ;;;

<https://youtu.be/vG8WpLr6y_U>

진짜 강추드립니다

저도 늦게 봤지만 가장 쇼킹했던 발표중의 하나여썽요

오.. 감사합니다!!ㅎㅎ 봐야겠네요!ㅎㅎ

저는 분리하는거보다 애초에 짬뽕해놓는게 더 낫다고 생각하긴해요. 어차피 나중에는 다 짬뽕되는 느낌이여서 ㅋㅋ

&gt; 어차피 나중에는 다 짬뽕되는 느낌이여서 ㅋㅋ
하긴ㅋㅋㅋㅋㅋㅋ 이거 레알 인정이요ㅋㅋㅋㅋㅋㅋㅋ

저는 React로 넘어간게 Styled Components 역할이 큰거같아요. 깔끔하게 짬뽕해줍니다.

Aㅏ… 프론트도 스택이 이제는 너무 넓고 방대해져 따라가기가 진짜 버겁네요ㅠㅠㅋㅋㅋㅋㅋㅋ

css in js 관련 아이들은 진짜 좋은 것 같아요 :+1:

View 단은 어떤걸 써도 컨벤션 정하기 쉽지 않지 않나요?? ㅠㅠ 요구사항도 워낙 자주바뀌고…

&gt; JSX 기반으로 코딩 경험이 거의 전무하지만, 짐작하기에 획일화된 코딩 컨벤션을 만들기가 좀 어려울 것 같은데 보통 팀에서 작업할때 어떤식으로 컨벤션을 정하나요? (너무 질문이 하이레벨이라 죄송…)
JSX가 컨벤션 측면에서 도움을 주는 것 같진 않아요. 그냥 UI를 표현하는 언어로 다루고 있습니다.

이쪽은 디자인 시스템 커뮤니티가 잡아가고 있는 것 같고요

클래스 이름 짓는거 진짜 이제 못해먹겠어요

theming 이나 이런쪽 컨벤션은 표준화 단계로 들어가고 있고요

팀 마다 제품 마다 뷰 구성이나 이런건 너무 천차만별이고

특히 애니메이션 많이 들어가면 웹에서 얘기하는 시맨틱한 레이아웃이 의미를 잃는 경우도 많고 뭐….

말씀하신대로 뷰쪽은 테스팅도 어렵고 여러가지로 많이 어려운것 같은데, 질문의 배경에 그 어려운 부분(뷰)이랑 로직(스크립트)을 분리시켜놓는게 좋지 않냐라는 전제가 있었습니다. Angular 로 예를들면 아시다시피 component.ts 랑 component.scss, component.html 로 분리되어 있으니까요

시맨틱 DOM을 얘기하던걸 아예 Accessibility level 을 다른 계층으로 분리해서

관심사의 분리에 대한 접근방식이 완전 다른걸로 알고있어요

리액트는 좀더 실제 관심사를 주변으로 모으는 쪽입니다. 뭐든지 컴포넌트 기반으로 생각하고 관심사를 어떤 “기술“이냐로 나누지 않아요. 그래서 xxx in js 패턴이 계속 나오죠

<https://sibelius.github.io/react-colocation/#0>

<https://www.slideshare.net/UyeongJu/ss-77857699>

ㅋㅋㅋ 와 대박ㅋㅋㅋㅋ 혜성님 지혁님 감사합니다ㅠㅠ
관점자체가 아예 다른거였구나…..

저도 협업은 항상 궁금한 주제이긴해요 ㅠㅠ 다른팀은 어떻게하나..

와 저 슬라이드 내용 완전 알차네요!! 순식간에 대략적인 관점 포인트가 깨달아지는ㅋㅋㅋㅋ 슬라이드보니까 프론트쪽에서 statement management 가 중요하게 대두되던 시점에서 이미 예견된 흐름이었나 싶기도 하네요

RN도 Flutter 도 메인은 싱글 액티비티입니다.

다만 얘네는 좀 더 모듈러한 코딩을 강제하는게, 애초에 JS/Dart 로 작성되는 UI 파트를 위한 바인딩을 모듈단위로 작성해서 등록해야해요.

그 부분이 네이티브 개발자들한테는 장점이 될 수도 있고, 단점이 될 수도 있는데.

적어도 모바일 팀 따로 있는 스타트업들에는 잘 맞지 않는 구조라 다들 RN이나 Flutter 도입할 때 해맨다고 생각합니다.

여러 플랫폼을 한 번에 지원해야 하는 리소스 전략 관점에서는 그냥 웹뷰 쓰는게 낫죠.

혹시 React Navigation 테스트 해보셨나요?

개발자한테 물어보니까 공식 지원은 아니지만 이미 대부분 지원될거라고는 하던데 직접 PoC는 못해봐서..