BNB Lesson

2019년 8월 13일

주최자 : 김민상

참가자 : 김종범, 맹세열, 최우석

0. 서론

진행방식

• 오늘은 정말로 강의 형식으로 진행할 예정

• 지금부터 시작하여 끝날 때까지, 모자라면 내일 계속

  • 이전 미팅 때 잠깐씩 빠르게 설명하고 넘어가는 방식이 아님
  • 매 파트마다 질문 시간 / 실습 시간을 아주 길게 갖을 것
  • 따라서 뭘 물어볼지, 뭘 체크할지 계속 고민하면서 프리하게 진행

숙지사항

• 이 문서는 당연히 모두에게 공유할 거지만, 각자 노트 펴고 각자의 방식으로 필기하기
  • 따라서 모든 내용을 담으려고 하지 말고, 본인들이 그동안 들어는 왔지만 깊이 찾아보지 않았던 것들을 찾아서 체크할 것
  • 그 체크한 내용에 따라서 질문 내용을 찾아볼 것
• 이 강의에서 제시하는 모든 내용에 대해 아래와 같은 고민을 하나씩 다 해 보기
  • 왜 이걸 써야 하는지?
  • 이걸 어디에 쓸 건지?
  • 쓰지 않았을 때와 비교해 뭐가 좋은지?
  • 내가 이해한 개념이 제시된 것과 맞는지?

1. Javascript (ES8)

ES?

• 우리가 쓰던건 ES5, 앞으로 쓸 건 ES8 + Typescript
• Typescript 는 이따 보고 우선 ES8 부터.

ES8 - ES5 = ?

• forEach, map, filter, reduce, some, every

  • arrow function
  • var, let, const
  • class
  • module import/export
  • Promise
  • Decorator
  • async await

2. Node.js

왜 Node.js?

• 장점
  • 개발자들의 활성도 가장 높음
    • 거의 모든 진보한 기술들의 구현체가 다 있음
    • 거의 모든 개발 서포트 툴이 다 있음
  • Isomorphic
  • 스타트업들의 de facto standard
• 단점
  • 뭐가 있을까? 생각나는대로 찾아보자.
    • non-blocking 이라서 귀찮은거?
    • 속도?
    • 잘 죽는다? (single thread니까)
    • 동적 언어라서?
    • 콜백 지옥?
    • 점점 더 설정 지옥?

그냥 지금 생각나는 구현체 각자 찾아보기

• 본인이 이전에 만들고 싶었던 거나, 관심 있었던 것.
• 혹은 PHP / Python 등에서 혹시 있나? 하며 찾아봤던 것.

Isomorphic

• 어떤 효과를 얻을 수 있을까?
  • SSR이 되는 유일한 언어
  • 서버/클라이언트가 공용 코드를 가지는 데에서 오는 이점?
  • 우리 내부적으로, 공통으로 사용할만한 라이브러리를 만들 수 있을까?

2019년에 알아야 할 상식

• npm 말고도 yarn 이라는 패키지 매니저가 있음
  • npm 이 워낙 느려서 yarn 이 미친듯 치고 올랐으나 npm 도 절치부심하여 현재는 다 따라잡은 상태
• package.json 은 아주 철저하게 관리해야 함
  • dependency / dev-dependency 구분도 확실히
  • 사용하는 패키지가 아주아주 많으므로 이 관리를 대충하면 망할 수 있음
• 번들러는 Webpack 으로 천하통일되는 분위기
  • 심지어 Angular 도 쓰기 시작함
  • grunt, gulp, yeoman 을 아직 쓰는 곳도 많으나, webpack 하나로 통합하여 사용하는 것이 추세
• 그외 궁금한 것?

기본적인 사용법

• npm init
• npm install
• npm uninstall
• node-cli
• npm run

3. Typescript

왜 정적타입인가?

• 일반적으로 정적타입은 대규모 개발에 동적타입은 소규모 개발에 어울린다고 알려짐
  • 대규모/소규모는 어떻게 나눌까?
  • 개인적으로, 한 코드를 다루는 구성원이 컨벤션을 모두 완벽히 따르기가 어려울 때-가 소규모 를 벗어났다고 생각.
• 강력한 도구의 지원
  • 맛들이면 벗어나기 싫어짐
• 생산성 향상
  • 많은 버그를 '미리' 발견할 수 있음
  • 단위테스트 해야 할 분량이 크게 줄어듦
• 설정이 귀찮은데...
  • 뭘 써도 2019년엔 어차피 Webpack 돌려야 함. 기왕 돌릴 거 같이 돌리자.

그럼 왜 Typescript 인가?

• Flow 라는 대안
  • 깊이 본 적은 없음
• ES7 의 상위호환?
  • ES버전이 몇인지 신경 쓸 필요없이 걍 씀
• Angular 쓸 거잖아?
  • 끗.

쓰기 위해 알아야 할 것들

• 일단 문서
  • Typescript-Handbook 한글 문서
• Class, Interface
• Generic
• Enumeration
• 다른건 문서 꾸준히 읽으며 필요할 때마다 찾아보기

설정에서 알아야 할 것들

• tsconfig.json 문서
  • 이 내용을 다 알 필요는 없겠지만 이것들이 대충 뭐인지 정도는 알고 있어야 함
  • 특히 paths 설정은 필수
• tsc, tsc -watch, ts-node
  • 뭔지 정도는 알고 있어야 함

4. Nest.js

왜 Nest.js 인가?

• 모두가 다 쓰는 그냥 express.js 는?
  • 이거까진 만들어보자 Express Hello World 예제
  • 이건 그냥 Node.js 의 내장 http 라이브러리 같은 느낌
• 그럼 Nest.js 는 뭐가 다르지?
  • 많이 다름, First Steps만 달려보자 Nest.js First Steps
  • "우린 니가 뭘 하고 싶든 다 할 수 있게 준비해뒀지"
    • 하지만 바퀴를 재발명하진 않겠어. 우린 그냥 모듈 래퍼라고.
• express 도 nest 도 내가 뭘 써야 할지 강요하지 않음
  • 하지만 뭘 써야 하는 경우, express 는 가이드가 전혀 없고, nest 는 가이드가 있음
  • nest 의 가이드 는 2019년에 해당 분야에서 가장 활발히 사용되는 기술을 Angular-way 한 방법으로 모듈화 해 놓은 것이 포인트.

Controllers / Providers / Modules

• Controllers
  • Decorator를 통해 조금 가독성 좋게 만들어놓은 app.get / post / put / delete
  • 사실 우린 별로 쓸 일이 없지.
• Providers
  • Angular 의 Service 와 비슷한 개념 (angluarjs 의 서비스와 비교해도 그렇게 많이 다르지는 않다)
  • 한마디로, Injection 을 하기 위해 존재하는 코드 묶음.
  • Resolver도 이 자리에 들어간다. (GraphQL)
• Modules
  • CommonJS 의 모듈보다는 Angular NgModule 을 닮은 놈
  • 4가지를 기술한다.
    • imports : 가져올 놈
    • exports : 내보낼 놈
    • providers : 내 프로바이더
    • controllers : 내 컨트롤러
  • Dynamic Module
    • 모든 모듈이 정적으로 그냥 선언되어 정의되면 그만일까?
      • 개중에는 분명 설정 파일이 필요한 케이스가 있음. (사실 더 많음)
      • 그럴 때 모듈 선언 자체를 동적으로 할 수 있다!
    • 이럴 때 사용하는게 forRoot
• Middleware 와 그 비슷한 따까리들
  • Exception Filters
    • Request/Response 처리 도중 Exception 이 throw 되었을 때 메세지 필터링
    • 막 튀어나온 Exception 을 클라이언트가 보기 편하게 정리하는 역할
  • Pipe
    • Request 가 던져준 쌩 데이터를 우리의 필요에 맞게 가공(Transform) 하거나 검증(Validation) 하는 처리
    • 문서에서는 Joi 말고 class-validator 부분만 볼 것 (우린 이것만 씀)
    • 사실 별로 쓸 일은 없는게 GraphQL 단에서 다 거름
  • Guards
    • Authentication 처리 목적을 위한 전용 middleware 라고 보면 됨
    • canActivate 메소드를 override 하여 해당 메소드에 승인 가능/불가능 여부를 판단하여 리턴하는 구조
    • @SetMetadata 데코레이터를 통해 로그인한 유저의 role 을 구분 처리하는 것도 가능
  • Interceptors
    • AOP (Aspect Oriented Programming)
      • 개발자 교양 삼아 알아두면 좋은 것 (참고 포스트)
      • 서로 다른 일을 하는 오만가지 것들 중 절차상 비슷한 일을 하는걸 묶어서 동시에 처리하는 개념
    • RxJs 방식을 통해 Request/Response 앞뒤로 다양한 작업이 가능
    • 현재 쓸 곳은 딱히 없음
• Custom Decorators
  • Nest.js 에서 상당히 중요한 개념 (정확히는 ES7 에서 나온 개념) 인 Decorator 지시자 를 커스텀하게 구현하는 방식
  • Decorator directive 를 간단하게 보면, class 에도 property 에도 걸어놓을 수 있는 '함수'
  • 현재는 @CurrentApp, @CurrentUser 두 곳에서만 사용중

Techniques & Recipes

• Authentication
  • 필수 파트, 여기서 제안하는 방식으로 passport-jwt 적용
• Database
  • 필수 파트, 여기서 제안하는 방식으로 typeorm 적용 (TypeORM 파트에서 설명)
• File upload
  • 필수 파트, 여기서 제안하는 방식으로 multer 적용
• Validation
  • 필수 파트, 여기서 제안하는 방식으로 class-validator 적용
• Logger
  • f9 log 대체, 적용 예정 (자체 로거 / winston 사용)
• Configuration
  • config/entp 대체, 적용 예정 (dotenv 사용)
• Compression
  • 적용 예정 (compression 사용)
• HTTP module
  • F9Http 대체, 적용 예정 (axios 사용)
• HMR
  • 이슈가 있어 잠시 홀드, 추후 적용 필요할 듯
• GraphQL
  • GraphQL 파트에서 설명

CLI

• f9-cli 개발 예정이라 nest-cli 자체를 바로 사용하지 않을 예정이지만, f9-cli 개발을 위해 사용법은 알아둘 필요가 있음

현재 구현된 사항 중 알아둘 부분

• Global path prefix 를 wildcard 로 사용하여 @CurrentApp 구현
  • 이 처리는 initCurrentApp middleware 를 통해 처리함
• @CurrentUser 처리시 Controller 와 Resolver 가 각각 대응하는 방식이 다른데, 이를 통합하여 처리하도록 구현
  • 이 처리는 PublicAuthGuard guard 에서 하고 있음
• 디렉토리 구조 / 파일명
  • 디렉토리 구조와 파일명은 별도의 파일에 기술할 예정 (복잡함;)
  • 파일명은 기본적으로 모두 name.something.ts 구조
    • module, options, controller, resolver, decorator, filter, middleware, guard, interceptor, entity, args, result, dto 등
• 데이터 마이그레이션 스크립트 (from closedshops)
  • Webpack 의 entry 설정으로 scripts/migration/index.ts 에 기술
  • F9Migration Class 를 구현하여 Adapter Pattern 으로 정의함
• 클라이언트 코드 트랜스포터 (to Angular)
  • Webpack 의 entry 설정으로 scripts/gentypes/index.ts 에 기술
  • 현재 몇가지 추가 대응해야 할 이슈가 있음
• 모델별로 만들어야 하는 클래스들은 모두 f9 prefix 로 시작하는 상위 클래스를 상속받게 구현
  • F9BaseResolver
  • F9BaseDto
  • F9BaseListArgs
  • F9BaseMutationResult
  • F9BaseEntity
    • 여기에 가장 내용이 많은데 TypeORM 파트에서 설명

5. TypeORM

왜 ORM 인가?

• 우리의 데이터는 구조화되어 있고, 앞으로 이 구조화 된 데이터를 정적 타입 으로 기술하여 type-safe 하게 사용할 예정
• 또한 GraphQL 을 사용하면 어느 정도 정형화 된 스키마가 코드 상에 존재하는 것이 강제됨
• ORM 도입을 꺼렸던 여러 이유들이 있지만, 모두 대응 가능하다고 판단
  • N+1 Problem
  • 복잡한 JOIN 으로 만들어진 쿼리
  • Cursor-based Pagination

왜 TypeORM 인가?

• Node.js 기반의 ORM 은 종류가 많은데 가장 대표적인 모듈은 Sequelize
  • 기능은 가장 많고, 용례도 가장 많아서 가장 우선순위 도입 고려대상이었으나,
    • Typescript 의 Type-based 를 전혀 활용하지 못함
    • Decorator 패턴 그런거 모름
  • 그래서 FAIL
• 최근 주목을 받고 있는 Prisma 와 Prisma 2 - PhotonJS
  • Prisma 는 docker 가 기본임. 일단 여기서 탈락.
  • Prisma2 는 아주 설계가 잘 되어 있다는 느낌을 받았고 docker 도 빠져 있는데, 아직 너무 PREVIEW 단계.
  • 실제로 적용해보니 티져 상에서 제공하는 멋진 기능들 외에 꼭 필요한 기능들이 죄다 빠져있음.
• 그래서, TypeORM
  • 필요로 하는 거의 모든 기능을 지원하고,
  • 대응이 안되는 케이스는 QueryBuilder 를 제공하여 raw 방식으로 처리 가능
  • Typescript + Decorator 패턴을 예쁘게 지원
  • Nest.js 문서상에 두번이나 등장할 정도로 매칭 좋음

Entity / Relations

• 그냥 문서를 살짝 읽어보는 것만으로 이해에 어려움이 없음
  • 일반적인 ORM 정의서가 아니라 그냥 일반적인 클래스 정의서를 쓰듯이 씀 (@Decorator 를 통해 가능)
• 세부적으로 알아야 할 사항,
  • 특별한 컬럼들
    • @PrimaryGeneratedColumn
    • @CreateDateColumn, @UpdateDateColumn
  • 컬럼 타입 지정
    • MySQL 에서 실제로 지정될 타입 지정
      • Primitive 인 경우 그냥 지정하면 됨
      • Enum 인 경우 처리 방식
    • 매개변수
      • length
      • default
      • nullable
      • unique, index 는 따로 Decorator 를 통해 지정하는 방식으로 통일
  • Relations
    • @OneToOne
      • 어느 쪽에 참조 필드를 놓을지가 중요
    • @ManyToOne, @OneToMany
      • 둘은 한쌍으로 움직이는데, 헷갈리지 않도록 주의
    • @ManyToMany
      • Join Table 에 추가 필드가 필요한 경우 이 지시자 대신 @ManyToOne 을 양쪽으로 걸어 씀

Query

• 총 5가지 방식이 있음

  • Entity Manager
  • Repository
  • Active Record
    • 이 방식을 기본으로 사용
  • Query Builder
    • 어쩔 수 없이 상당히 많이 사용됨
  • Raw Query
    • 최대한 안 써보자!
    • 마이그레이션 코드엔 쓰고 있음

• Active Record and findOptions

  • QueryBuilder 를 사용하지 않을 때 (일반적인 쿼리일 때) 사용하는 find 의 options
  • 매우 중요해서 이 문서에 있는 모든 옵션들에 대해 알고 있어야 함

• Query Builder

  • findOptions 가 제공하지 않는 형태의 모든 쿼리는 이 방식으로 사용
  • 특히 GraphQL 과 결합되는 createList (f9-base-entity.ts) 가 이 방식이 아니면 안 됨
  • CodeIgniter 의 Query Builder 와는 맥락만 같고 사용하는 방식이 완전히 달라 제대로 쓰려면 많은 삽질이 필요ㅠ

• Create / Update / Delete 쿼리 사용

  • Active Record 만으로 충분함 (아직까지는)

6. GraphQL

왜 GraphQL 인가?

• GraphQL 은 뭐지?
  • 그냥 이거 읽는게 빠를듯
• RESTful? 하지도 않았지만... (ㅋㅋ)
  • GraphQL 도입 전, 우리는 RESTful 했나?
    • 아님, 우린 그냥 독자규격 JSON-RPC
  • 우리가 REST를 꺼려했던 부분은?
    • 우리 정도의 복잡도에도 GET/POST/PUT/PATCH/DELETE 5개의 동사로 표현 가능한 범위에 한계가 있었음
    • 요새는 Postman 같은 툴이 좋아져서 테스트가 그나마 좋아졌지만, 예전엔 GET/POST 만을 사용하는게 훨씬 유리했음
• GraphQL 은 REST 를 대체할 수 있는 완벽한 대안
  • 모든 구조화 된 데이터를 type-safe 하게 관리함 (또 그래야 함)
  • 클라이언트에서 필요한 데이터만 딱 잘라 요청할 수 있음 (경제적 효과)
  • REST 에서 불만이었던 '동사'의 제한이 없음
  • 필요한 여러 요청을 한번에 보낼 수 있음 (프론트엔드에서의 효과)
    • 컴포넌트 베이스의 프론트엔드에서 전혀 예상 못한 효과
    • 필요한 데이터 때문에 다른 컴포넌트와 강하게 coupling 될 필요가 사라짐
    • 캐시 덕분에 단일 저장소(Single source of truth), 단방향 데이터 흐름(Uni-directional data flow) 이런거 다 불필요

GraphQL 구현체는?

• Apollo
  • Nest.js 는 Apollo 를 지원함 (GraphQLModule (@nestjs/graphql) 구현 자체가 Apollo Server 기반, 정확히는 type-graphql + apollo-server)
  • Recipe 도 깨알같이 자세함
  • Apollo 는 Angular 를 지원함 (Apollo Client - Angular Docs)
• Flutter 에서는 하나뿐인 구현체 확인 필요
  • 잘 되어 있기를ㅠ

알아야 할 GraphQL 용어

• Query
  • 우리가 아는 그것
  • 데이터 변조 없이 데이터 내놔- 하는 요청
• Mutation
  • Query 외의 거의 모든 것 (데이터를 변조함)
• Subscription
  • 단순히 데이터를 쿼리하고, 변조하는 것이 아니라 지속적으로 데이터를 내려주는 경우 (e.g 채팅)
• Type
  • 일종의 클래스 개념
  • 데이터의 구조와 타입(여기서의 타입은 동적-정적 할 때 그 타입)을 정의
• Input
  • 일종의 DTO 개념
  • Mutation 처리시 전달받는 데이터 객체의 스키마로서 정의
• Enum
  • Typescript 의 Enum 과 같은 개념이지만, GraphQL 쪽에 별도로 등록해주어야 함
• Resolver
  • GraphQL Endpoint 로 Query/Mutation 요청이 들어왔을 때 이를 처리하는 핸들러 역할을 하는 코드

서버 구현

• Schema First? / Code First?
  • Nest.js GraphQL Quick Start
  • Schema First
    • 타입 관련 스키마(SDL)를 먼저 생성하고 resolver 를 구현하는 방식
  • Code First
    • 타입 관련 스키마를 별도로 생성하지 않고, 바로 Entity 에 Decorator 로 때려넣는 방식
    • 이걸 해주는 게 바로 type-graphql
    • 이 방식으로!
• Type 생성
  • 그냥 엔티티에 아래 데코레이터들을 넣으면 끝.
  • 데코레이터
    • @ObjectType (Type)
    • @InputType (Input)
    • @ArgsType (스키마 아님)
    • @Field (Field of Type/Input)
• Resolver
  • 그냥 이 문서 Nest.js GraphQL Resolvers
• Resolver - TypeORM
  • 위에서 GraphQL 의 이점이 '필요한 필드만 요청할 수 있다'고 했는데, 그 요청을 받아다가 '필요한 필드만 응답'만 하는건 GraphQL 이 해줌
  • 다만 DB에서 가져올 때의 처리는 직접 해야함
    • 그걸 해주는 코드를 직접 구현함 F9BaseEntity 안에 있는 createList 함수
    • createList 함수는 resolver 에서 전달받은 @Info 데이터를 파싱하는데 resolveGqlInfo 함수 사용 (별도 구현, resolve-gql-info.ts)

클라이언트 구현

• 위에서 링크한 Angular 에서의 Apollo 구현체 사용 (Apollo Client - Angular Docs)
  • 이 문서에 특별히 Angular 에만 있는 파트가 바로 Query, Mutation, Subscription services
  • DI 가능한 서비스로써 GraphQL 쿼리를 사용할 수 있음.
  • 이 방식으로 모델 단위 모듈에서 export 하고 필요한 쪽에 import 하면 다 갖다 쓸 수 있음
• 아름다운 In-memory Cache 를 제공
  • 그래서 심지어 그 캐시 저장소에 로컬 데이터를 입력할 수도 있음 (Local state management)
  • 꺼내오는건 GraphQL-way, 똑같음
• 순서 상관없이 아무렇게나 필요한거 막 요청해도 통합 처리
  • 실수로라도 같은 데이터를 두번 다시 받는 일은 없음
• 이로써 Redux도 ScopedModel 도 없는 평화로운 프론트엔드! 는 아래 Angular 파트에서 계속

7. Angular

왜 Angular 인가?

• 다른 대안은?

  • React
  • Vue
  • angularjs

• Angular 만의 장점이라면?

  • Typescript
    • small-sized 에서 mid-sized 로 나아가는 우리 개발팀의 플랫폼 전환 목적에 Typescript 는 꼭 필요한 요소인데, Angular 외의 나머지 것들은 Typescript 적용에 따로 공수가 듦
  • 가장 잘 설계된 Template Syntax
    • 스트링/변수 바인딩 구분
    • Event binding
    • Attribute binding
    • Class binding
    • Style binding
  • 가장 잘 설계된 Native Component Interaction
    • @Input, @Output 지시자를 구분하여 별도로 관리하는 부분
    • 이걸 Template Syntax 에 가장 부드럽게 잘 녹아들게 표현
  • 우리는, 한때, angularjs
    • 이전에 만들어놓은걸 약간만 변형해서 그대로 쓸 수 있음
      • Attribute Directive
      • Pipes
    • Template Syntax 문법도 가장 유사함 (당연한거지만ㅋㅋ)
    • Native 하게 제공하는 two-way binding (ngModel)
    • 기존과 같이 HTML/SCSS 코드를 별도의 파일로 사용 (JSX 대신에)
      • 하지만 기존처럼 완전히 다른 위치에 저장되는게 아니라 컴포넌트와 함께 사용 가능.
  • Nest.js 와 닮았다.
    • 닭이 먼저냐 달걀이 먼저냐ㅋㅋ
  • Native 하게 지원하는 SSR
    • React 는 next.js, Vue 는 nuxt.js 를 씀

  디렉토리 / 파일 구조

  • 이 문서 참조

  angular.json

  • Angular 는 하나의 코드베이스 안에 여러개의 project 를 관리할 수 있음 (별도로 ng serve, ng build 하는 구조)
  • 따라서 설정 파일 역시 개별 project 마다 필요한데, 이 정보가 angular.json 에 담겨 있음
  • 알아야 할 부분
    • asset : 에셋 (주로 이미지)
    • styles : import 해야 할 SCSS 파일 별도 지정
    • polyfills : 구 버전의 브라우져 대응하는 코드 파일
    • aot : AOT-compile 여부 설정 (AOT Compiler)

  Routing

  • 기본적인 라우팅 설정은 크게 어렵지 않음 (문서)
  • 모듈 단위 Lazy Loading 이 가능함
    • 당분간 큰 필요 없으면 사용하지 않을 예정
  • 기존 레드데이즈의 URL 경로 fallback 처리 필요

  RxJs/Observables

  • Observables 는 Angular 에서 매우 중요한 개념이자, 매우 자주 사용되는 개념

    • 동작하는 방식과 사용하는 방식에 대해 계속해서 스터디가 필요할 듯 (나도ㅠ)

  • 기본적으로는 Promise 의 대체재라고 보면 되는데, 훨씬 더 잘 정리된 개념으로 보임 (다른 테크닉과 비교)

    • Observable 은 선언적입니다. Subscribe 하기 전까지는 연산이 시작되지 않아요. 반면 Promise 는 생성 즉시 실행 됩니다. 이 차이는 "당신이 결과를 필요로 할 때" 사용 가능한 레시피처럼 활용되기에 유용합니다.

    • Observable 은 여러 값들을 제공할 수 있습니다. 반면 Promise 는 하나밖에 제공할 수 없죠. 계속해서 복수의 값들을 받아야 할 때 Observable 이 잘 활용될 수 있습니다.

    • Observable 은 chaining 과 subscription 을 구분합니다. Promise 에는 오직 .then 뿐이죠. 그래서 Observable 은 복잡한 데이터 변환 레시피를 만드는데 유용합니다. 작업을 바로 수행하지 않은 상태에서요.

    • Observable 은 에러 처리를 subscribe() 에게 맡깁니다. Promise 는 에러를 자식 Promise 에게 넘기죠. 따라서 보다 중앙화 되고 예측가능한 에러 처리를 가능하게 합니다.

  • Async Pipe

    • 셋업된 Observable 을 반드시 코드 단에서 subscribe() 할 필요 없이 거기서 나올 데이터를 바로 뷰에 바인딩하는 것이 가능함. 그걸 가능하게 해주는 것이 Async Pipe, 아래와 같이 사용 가능.

      <div class="product" *ngFor="let product of products | async">
        {{ product.title }}
      </div>

  상태 관리

  • GraphQL replaces Redux
    • 우리는 Redux 나 Scoped Model 같은 별도의 레이어/저장소 없이 컴포넌트 단위에서 직접적으로 데이터를 호출하여 사용하게 됨
      • GraphQL 의 In-memory Cache 가 우리의 단일 저장소(Single source of truth) 인 셈
      • 개별 컴포넌트가 필요한 정보는 모두 해당 컴포넌트가 직접 호출
      • 순전히 데이터의 필요에 의해 다른 컴포넌트와 coupling 되지 않음
    • 이를 Flux Architecture 의 개념을 빗대어 설명하면,
      • Reducer : 클라이언트가 안함, 서버의 Resolver가 함 (클라이언트에게 딱 맞는 데이터 제공)
      • Dispatch : GraphQL 의 Query/Mutation (심지어 문서도 만들어줌)
      • Action : GraphQL Schema
      • Store : Apollo GraphQL Client 의 In-memory Cache
    • Query 는 아예 신경 쓸 필요가 없고, Mutation 시에는 캐시 갱신에만 신경쓰면 됨
      • writeQuery
  • AJAX 콜 말고 다른 데이터의 상태는?
    • The Angular way 로 충분함.
    • 2~3 뎁스인 경우 계속해서 @Output 을 올려주는 방식으로 처리하고, 이보다 뎁스가 높은 경우 Local Cache 를 사용하는 방식을 고려할 수 있음
      • 현 시점에서 그래야 할 부분은 없음

  이전 코드를 Migration 할 때 고려사항

  • 문서 참조