2017년 12월 30일 토요일

GDG 정리

GDG fest 17/11/19 in Seoul UNI


Why Typescript with Clean Architecture

  • 발표자 장유진
  • banksalad 상품 -> 금융 솔루션이라 프로젝트의 사이즈가 커짐-> 관리가 어려움
    1. 제품관점

      제품의 궁극적인 모습을 상상해보면?
      같은 주제도 여러 관점에서 다룬다.
      * Microservice Acrhitecture :: 각 기능별로 서버를 구현


클라이언트는 다양한 기능이 모이는곳이라 중요함
2. 협업관점
같은 주제도 다르게 생각한다.
관점을 통일하지 않으면 문제가 생긴다.
3. 개발 환경 관점
JS의 근본적인 문제 오류 검출이 힘들다
* 해결방안 typesafe 언어 지식기반으로 만든다.
* 지식 중심의 명확한 아키택쳐
DDD(Domain Driven Design)
도메인 전문가와 엔지니어가 모델을 만들어서 아키택쳐를 만든다.
* 빠른 개발 속도

> 변경이 적은 코드

프론트엔드 프레임 워크 낱낱히 파해치기


react, Django 로 만드는 progressive web app

  • PWA 웹의 장점과 앱의 장점을 더한 개념
  • 어느 브라우저를 선택하든 상관없이 점진적 기능 개선을 통해 모든 사용자에게 제공
  • 반응형
  • 따로 앱을 만들지 않아도 앱아이콘 푸쉬 가능
  • 업데이트를 하지 않고 항상 최신화
  • service worker
  • mainjs 요청하면 서비스 워커가 가로 챈다-> 캐시를 확인하여 캐시가 있는지 확인 한다.->(네트워크 연결X )캐시에 있으면 화면 랜더링
  • 업데이트는 랜더링 다음에 한다.
  • 서비스 워커는 cra에 저장 되어있음
  • 파일명 해쉬도 cra가 해준다.
  • 브라우저 캐시 vs 서비스 워커
  • 브라우저 캐시는 일정 기간 마다 없어지는 경우가 있음 그리고 크기가 제한적(모든 사이트를 저장하기 때문에)

Redux 정리

REDUX


Redux의 특성

1. Single Source of Truth

어플리케이션의 state를 위해 단 한개의 store를 사용합니다.
Flux에서는 여러개의 store를 사용합니다.

2. State is Read-Only

어플리케이션에서는 store의 state를 직접 변경할 수 없습니다.
state를 변경하기 위해선 무조건 action이 dispatch 되어야합니다.

3. Changes are made with pure Function

action 객체를 처리하는 함수를 reducer라고 합니다.
reducer는 정보를 받아서 상태를 어떻게 업데이트 할 지 정의합니다.

reducer는 ‘순수함수’로 작성되어야합니다.

즉 네트워크 및 DB 접근 X, 인수 변경 X
같은 인수로 실행된 함수는 언제나 같은 결과를 반환
순수하지 않은 API 사용불가

>

구성요소

  • Action Creator

    어플리케이션 상태를 바꾸고 싶다면 항상 액션을 보내야 한다(무조건).
    무슨 메시지를 보낼지 알려주면 액션 생성자는 나머지 시스템이 이해할 수 있는 포맷으로 바꿔준다
    Flux와는 다르게 Redux의 액션 생성자는 디스패쳐(dispatcher)로 액션을 보내지는 않는다. 대신, 포맷을 바꾼 뒤 액션을 돌려준다.

  • Store

모든 상태 변화는 스토어에 의해서 이루어져야 하고 스토어로 직접 요청하는 대신 액션 파이프라인을 따라가야 한다.
Flux에서는 다수의 스토어를 가질 수 있지만 Redux에서는 한개의 Store만 가질 수 있다.
Redux의 스토어는 상태 트리(state tree) 전체를 유지하는 책임을 진다.
액션이 들어왔을 때 어떤 상태변화가 필요한지에 대한 일은 위임한다.
Flux의 디스패쳐의 역활도 한다.

  • Reducer

스토어는 액션이 어떤 상태 변화를 만드는지 알 필요가 있을 때 리듀서에게 묻는다.
이것이 바로 Redux의 키 아이디어 중 하나이다. 상태 객체는 직접 변경되지 않는다. 대신, 각각의 상태 조각이 복사 후 변경되고 새로운 상태 객체 하나로 합쳐진다.
리듀서는 복사되고 업데이트된 상태 객체를 루트 리듀서에게 넘겨주고, 루트 리듀서는 이 객체를 스토어로 보낸다. 그리고 스토어는 이 객체를 새로운 애플리케이션 상태로 만든다.

  • View

똑똑한 컴포넌트와 멍청한 컴포넌트

Smart Dumb
액션처리를 책임진다. 우직한 컴포넌트는 액션에 직접 의존성을 가지지는 않는다
똑똑한 컴포넌트는 props를 통해서 멍청한 컴포넌트에 함수를 보낸다 멍청한 컴포넌트는 받은 함수를 콜백으로써 단순히 호출만 한다
CSS style XX CSS style OO
DOM XX DOM OO

* View Layer Binding

스토어를 뷰에 연결하기 위해서 Redux는 약간의 도움이 필요하다. 그 둘을 함께 묶어줄 무언가가 필요한데, 이걸 해주는 것이 바로 뷰 레이어 바인딩이다

  1. 공급 컴포넌트(provider component): 컴포넌트 트리를 감싸는 컴포넌트이다. connect()를 이용해 루트 컴포넌트 밑의 컴포넌트들이 스토어에 연결되기 쉽게 만들어준다.
  2. connect(): react-redux가 제공하는 함수이다. 컴포넌트가 애플리케이션 상태 업데이트를 받고 싶으면 connect()를 이용해서 컴포넌트를 감싸주면 된다. 그러면 connect()가 셀렉터(select)를 이용해서 필요한 모든 연결을 만들어준다.
  3. 셀렉터(selector): 직접 만들어야 하는 함수이다. 애플리케이션 상태 안의 어느 부분이 컴포넌트에 props로써 필요한 것인지 지정한다.

    • Root Component

모든 React 애플리케이션은 루트 컴포넌트를 가진다. 이것은 단지 컴포넌트 계층 구조에서 가장 위에 위치하는 컴포넌트일 뿐이다. 하지만 Redux에서는 루트 컴포넌트는 추가로 책임져야 할 것이 존재한다.
하지만 루트 컴포넌트는 애플리케이션을 초기화한 뒤로는 거의 하는 일이 없다. 화면을 갱신도 더는 신경 쓰지 않는다. 화면 갱신은 뷰 레이어 바인딩의 도움으로 아래의 컴포넌트들이 맡아서 처리한다.


SetUp

  1. Ready Store
  2. Prepare communication between store and component
  3. Ready Action Callback

DataFlow

  1. 뷰가 액션을 요청한다. 액션 생성자가 포맷을 변환한 뒤 돌려준다
  2. bindActionCreators()가 준비과정에서 사용되었으면 자동으로 액션이 보내진다. 그게 아니라면 뷰가 직접 액션을 보낸다
  3. 스토어가 액션을 받는다. 현재 애플리케이션 상태 트리와 액션을 루트 리듀서에게 보낸다.
  4. 루트 리듀서는 상태 트리를 조각으로 나눈 뒤 알맞은 서브 리듀서로 상태 조각들을 넘겨준다.
  5. 서브 리듀서는 받은 상태 조각을 복사한 뒤, 그 복사본을 변경한다. 루트 리듀서에게 변경된 복사본을 돌려준다.
  6. 모든 서브 리듀서가 변경 된 상태 조각들을 돌려주면, 루트 리듀서는 이 상태 조각들을 한데 모아 상태 트리로 만든 뒤 스토어로 돌려준다. 스토어는 새로운 상태 트리를 옛날 상태 트리와 바꾼다.
  7. 스토어는 뷰 레이어 바인딩에게 애플리케이션 상태가 변경되었다는 것을 알린다.
  8. 뷰 레이어 바인딩은 스토어에게 새로운 상태를 보내달라고 요청한다.
  9. 뷰 레이어 바인딩은 뷰에게 화면을 업데이트하도록 요청한다.

PlayNode 후기

PlayNode

17/11/09 르메디앙 호텔

GraphQL + Relay + Serverless


  • 발표자 박형식 @ 텀블벅
  • 필요한 리소스만을 요청하고 사용하는 API 만들기
  • 요즘은 컴포넌트 단위로 쪼개서 개발한다.
  • 너무 많은 컴포넌트를 통신상태가 좋지 않은 상태일떄 어떻게 할까?

쿼리스트링 -> 데이터가 많을때 문제가 생긴다.

  • 데이터의 형태가 매번 바뀔수 있다
  • soundcloud 는 BFF 형태로 문제해결
  • BFF -> 프론트 엔드 위주로 백엔드가 백업해준다.
  • 하지만 다양한 상황에 따른 각각의 BFF를 만들어야하는 문제가 발생
  • 그렇기 때문에 GraphQL사용
  • 형식은 요청은 value가 없는 JSON 응답은 value가 있는 JSON
  • 요청{me{name,sex}},응답{me{name:’kong’,sex:’man’}}
  • 이런식으로 인자가 있는 요청 가능{user(id=’1’){name,sex}}
  • POST/graphQL 보통 여기로 보내는게 규정
  • Type System ????????
  • type은 기본키 같은존재 쿼리가 어디서 부터 시작하는지 알려줌 (솔직히 잘모르겠음)
  • mutation은 read write delete update 를 할수있게 함
  • 너무 많은 데이터를 낭비하는 RESTAPI보다 graphQL이 더 좋을 수도 있다.
  • 비지니스 로직이 너무 커질경우, 네트워크 요청이 비쌀때, 요청이 많을때 필요
  • 네트워크 콜 최소화

Relay

  • 이미 내가 데이터가 있는지 확인 (캐싱이나 다른 걸로 받았는지 확인)하고 없으면 받는다
  • 이걸로 네트워크 콜을 최소화의 최소화한다.
  • 서버와 클라이언트 사이
  • 응답과 답장이 가능해야한다.
  • mutation할때 테그를 붙히는데 답장에도 태그가 붙어 체이싱이 되어야한다.

Serverless

  • 서버리스에서 가장 중요한것은 함수
  • 함수 == event
  • 서버리스는 패턴과 아키텍쳐
  • 서버 관리의 모든걸 클라우드에게 맡기자!
  • 이벤트가 있을때만 사용하기 때문에 비용적인 측면에서 GOOD
  • 이 서버들을 함수로 연결하자

정적 타이핑

  • 개발 파이프라인
  • 코드수정 -> 컴파일 -> 커밋->빌드 -> 배포
  • 탐지 가능한 버그
  • 정적 타이핑으로 테스트 한 경우 15%정도 버그를 줄였다.
  • 버그를 없애는 것이 아니라 버그를 미리 발견할 수 있게 한다.
  • 코드와 더 밀접히 연결된 문서화가 가능해집니다.
  • 리팩토링이 용이해집니다.
  • typescript(ms) vs flow(facebook)
  • EX) const abc(a:number){}
  • 제네릭도 지원
  • TS가 더 나은 결정이라고 생각한다.
  • 안전함과 편리함 사이 설득력 있는 트레이드오프
  • ts랑 flow랑 근본적인 철학의 차이가 있다.
  • flow가 훨씬더 꼼꼼하다. 그래서 너무 사소한 것도 에러를 뛰어 버린다.
  • 안전한 선택이 보일러플레이트가 됨
  • IDE == VSCODE
  • flow 보다 ts가 훨씬 커뮤니티가 크다
  • 도입
  • 점진적 타이핑을 해도 된다.

디버깅

  • 발표자 최준영
  • 효율적인 디버깅을 위해서 전후에 확인하자
  • 타입 어노테이션
  • 당신의 의도를 ide 에게 잘 전달할 수 있다.
  • payload
  • 여기도 ts
  • css in js
  • 완벽한건 아니다 JS!
  • 런타임에서 막아보자
  • 인스펙터 를 이용한 디버깅
  • !!!!!!
  • 중요 인스펙터 + 브레이크 포인트
  • !!!!!
  • 스텝인 -> 함수안으로 들어오는거 오버엔 아웃
  • 비동기 상황에서도 가능하다 -> 완벽하진 않음
  • pause in exception 이것도 키고 할것
  • VScode Inspector
  • 음…..
  • TTD 챠크라 -> 디버깅중 과거로 돌아갈수 있다.

클라우드 시대의 node가 좋은이유

  • 발표자 OKKY-허광남
  • 2016년 1월 7일에 AWS KOREA 이후로 기업들이 클라우드로 넘어옴
  • PaaS 종류 : PaaS-TA,Beanstalk,AppEngine,AppService,Heroku,WebApps
  • uptime 1분마다 응답속도의 그래프를 보여줌
  • kinana 시각화

Typescript Meetup

Typescript Korea MeetUp 2018 2018년 1월 18일 강남 마루180 19:00 ~ 21:10 Typescript 로 부터 얻은것과 잃은 것 발표자 손찬욱 (네이버) eg.js 개발중 Typescript 사용기 eg...