
## 프로젝트 기간

- 2018.05.29 ~ 2018.06.06

## 원격 저장소

- [github](https://github.com/sc372/simple-blog-app-react-node)

## 요구사항

- 댓글 기능이 있는 간단한 블로그 웹 애플리케이션
- 회원 가입
- 회원 정보 수정
- 블로그 게시물 CRUD
- 블로그 게시물 댓글에 대한 CRUD
- 블로그 게시물 댓글의 댓글에 대한 CRUD

## 개발 일정

- 1 day : (front) page, layout ui 작성, router 적용
- 2 day : (front) ui에 필요한 component 작성(1)
- 3 day : (front) ui에 필요한 component 작성(2)
- 4 day : (front) redux 적용, model 설계 및 작성
- 5 day : (back) 프로젝트 초기화, 회원가입 / 탈퇴 / 로그인 로직 작성
- 6 day : (back) 블로그 CRUD, 블로그 댓글 CRUD
- 7 day : (back) 페이지 별로 요청 데이터 응답해주기

## 프론트엔드

### 기술 스택

#### 핵심 모듈

- [react.js (v.16.8.6)](https://reactjs.org/)
- [CRA (v.3.0.1)](https://github.com/facebook/create-react-app) : 커뮤니티 공식 react app starter
- [react-app-rewired (v.2.1.3)]() : CRA 에서 webpack eject 하지 않고 사용하는 설정 도구
- [customize-cra (v.0.2.12)](https://github.com/arackaf/customize-cra) :
  react-app-rewired 와 함께 webpack 대신 사용하는 설정 도구
- [react-router (v.4.4.0.beta)](https://github.com/ReactTraining/react-router) : 라우팅 도구
- [redux (v.4.0.1)](https://github.com/reduxjs/redux) : 상태관리 라이브러리
- [redux-sagas (v.1.0.2)](https://github.com/redux-saga/redux-saga) : 사이드 이펙트 코드를 효과적으로 작성할 수 있는 도구
- [sass](https://sass-lang.com/) : 구조적으로 css 사용 가능
- [ramda.js](https://ramdajs.com/) : collection 핸들링을 돕는 함수형 라이브러리
- [moment (v.2.24.0)](https://momentjs.com/) : 시간 관련 포맷 도구
- [axios (v.0.19.0)](https://github.com/axios/axios) : http 통신을 위한 도구

#### 정적 분석

- [typescript (v.3.4.5)](https://www.typescriptlang.org/)
- [eslint with typescript (v.5.16.0)](https://eslint.org/) : 문법 검사 도구(js + ts)
- [prettier (v.1.17.1)](https://prettier.io/) : 코드 포매터

#### 컴포넌트 라이브러리

- [antd](https://ant.design/) : ui component
- [react-cropper (v.1.2.0)](https://github.com/roadmanfong/react-cropper) : 이미지 사이즈 조절
- [react-infinite-scroll-component (v.4.5.2)](https://github.com/ankeetmaini/react-infinite-scroll-component) :
  무한 스크롤
- [react-quill (v.1.3.3)](https://github.com/zenoamaro/react-quill) : 텍스트 에디터
- [react-responsive (v.6.1.2)](https://github.com/contra/react-responsive) : css 없이 screen size 핸들링 도구

### 프로젝트 설계도

```markdown
├── build : build 된 파일 모음
├── node_modules : npm 모듈 모음
├── public : 정적 리소스 모음
├── src : 정적 리소스 모음
│  ├── api : api 통신을 위한 파일들
│  ├── components : ui component 파일들
│  ├── models : model 파일들
│  ├── pages : page 파일들
│  ├── redux : react-redux 파일들(sagas 포함)
│  ├── styles : styles 파일들
│  ├── test : test 파일들
│  ├── utils : 유틸리티 파일들
│  ├── App.tsx : 라우트, helmet 정의
│  ├── index.tsx : app 시작 지점
│  ├── PrivateGuard.tsx : route guard 핸들러
│  ├── react-app-env.d.ts : CRA 를 통해 만들어진 환경변수 정의 하는 파일로 추측됨(미사용)
│  ├── Root.tsx : redux store wrapping
│  └── serviceWorker.ts : 브라우저 외부에서 다양한 기능들을 활용할 수 있도록 돕는 기능
├── typings : type 정의
├── .env : 환경 변수 정의
├── .eslintrc.js : eslint 설정
├── .gitignore : git 제외 설정
├── .prettierrc : prettierrc 설정
├── config-overrides.js : react-app-rewired 설정
├── package.json : npm 정보
├── README.md : read me
└── tsconfig.json : 타입스크립트 complie 설정
```

### 주요 특징 및 회고

- 정적분석도구(typescript, eslint, prettier) 의 강력한 정적 분석으로 실수를 줄일 수 있었다.

- [pure component](https://medium.com/@async3619/when-to-use-component-or-purecomponent-b810897a19a2) 를
  거의 전부 구현(antd 의 의존성으로 modal에서의 폼 제외) 하였다. pure component 특징인 얕은 비교와 렌더링 을 최소화 할 수 있는
  장점을 최대로 활용하기 위해서 였다. 과정 중에 렌더링과 비동기 로직과의 핸들링에 어려움이 있었다.
  [react hooks](https://velog.io/@velopert/react-hooks) 를 활용 하여 대안을 찾아 나갔다.

- redux model 설계시 객체 깊이가 깊은 모델을 설계 하지 않아야 reducer 로직 구현 및 객체 복사에 대한 비용을 줄일 수 있다.
  로직이 복잡해짐에 따라 다시 설계를 하지 않으려면 처음 설계때 부터 모델 설계시 도메인을 잘 분리하고
  크기가 크지 않게 설계 해야 로직 구현이나 비용이 적은 프로그램을 만들 수 있는 것 같다.

- ui, domain 모델을 분리하여 각 필요에 맞게 활용하였는데 설계시 좀 장황한 느낌은 있으나
  로직 구현 및 데이터를 활용할 때에는 깔끔하고 오류를 줄일 수 있어서 좋았다.

- React.lazy 함수를 통해서 컴포넌트 지연평가를 적용하여 컴포넌트 를 원하는 시점에 로드 할 수 있도록 해서
  비동기 통신과 컴포넌트의 논리적 구성에 대한 대응방법을 알 수 있었다.(route gaurd 에 적용)

- any 타입을 사용하지 않을 수 있도록 타입 정의를 꼼꼼하게 하는 것은 중요하나 시간이 많이 걸리는 작업이라서 적절한 타협을 했다.

## 백엔드

### 기술 스택

- OOP (object oriented programming)
- [Mango framework](https://github.com/MrARC/Mango)

#### 핵심 모듈

- [node.js (v.10.1.5.3)]()
- [express.js (4.16.4)](https://expressjs.com/ko) : nodejs micro 웹 프레임워크
- [pg (v.7.10.0)](https://node-postgres.com/) : postgresql 라이브러리
- [typeorm (v.0.2.9)](https://typeorm.io/) : typescript 지원 orm
- [jsonwebtoken (v.8.4.0)](https://github.com/auth0/node-jsonwebtoken) : json web token 라이브러리
- [typeDI (v.0.8.0)](https://github.com/typestack/typedi) :
  [의존성 주입(DI)](https://ko.wikipedia.org/wiki/%EC%9D%98%EC%A1%B4%EC%84%B1_%EC%A3%BC%EC%9E%85) 라이브러리
- [routing-controller (v.0.7.7)](https://github.com/typestack/routing-controllers) :
  express.js 에서 활용 가능한 controller(http, routing) 라이브러리
- [winston (v.3.1.0)](https://github.com/winstonjs/winston) : logger 라이브러리
- [ramda.js](https://ramdajs.com/) : collection을 핸들링을 돕는 함수형 라이브러리
- [moment (v.2.24.0)](https://momentjs.com/) : 시간 관련 포맷 도구
- [axios (v.0.19.0)](https://github.com/axios/axios) : http 통신을 위한 도구

#### 정적 분석

- [typescript (v.3.4.5)](https://www.typescriptlang.org/)
- [tslint (v.5.12.0)](https://palantir.github.io/tslint/) : 문법 검사 도구
- [prettier (v.1.17.1)](https://prettier.io/) : 코드 포매터

### 프로젝트 설계도

```markdown
├── dist : build 된 파일 모음
├── node_modules : npm 모듈 모음
├── public : 정적 리소스 모음
├── src
│  ├── api.v1 : api ver.1
│  │  ├── auth : auth (jwt)
│  │  ├── blog : blog CRUD
│  │  ├── blog-comment : blog-comment CRUD
│  │  ├── blog-comment-comment : blog-comment-comment CRUD
│  │  ├── common : 공통 사용 객체
│  │  └── user : user CRUD
│  ├── database
│  │  └── database.ts : database 세팅 및 연결 기능
│  ├── handlers
│  │  ├── api_error.handler.ts : api error 핸들링 객체
│  │  └── api_response.handler.ts : api 응답 핸들링 객체
│  ├── helpers : page 파일들
│  │  ├── authorization_check... : auth 체크 객체
│  │  └── current_user_check... : jwt decoding 을 통해 사용자 확인 객체
│  ├── logger :
│  │  └── logger.service.ts : winston logger 객체
│  ├── middleware
│  │  ├── error.middleware.ts : error 미들 웨어
│  │  ├── http_logging.middleware.ts: http logging 미들웨어
│  │  └── not_found.middleware.ts : 찾을 없는 요청에 대한 처리 미들웨어
│  ├── migration : database migration
│  ├── utils
│  │  └── json.utils.ts : json wrapper util 객체
│  ├── app.ts : application init 객체
│  └── www.ts : 서버 동작에 대한 객체
├── tests
├── .env : 환경 변수 정의
├── .tslint.json : tslint 설정
├── .gitignore : git 제외 설정
├── .prettierrc : prettierrc 설정
├── ecosystem.config.js : [pm2](https://massivcode.com/5) 를 활용한 배포 동작 세팅
├── ormconfig.json : typeorm 설정
├── nodemon.json : dev 모드에서 watch를 위한 [nodemon](https://nodemon.io/) 설정
├── package.json : npm 정보
└── tsconfig.json : 타입스크립트 complie 설정
```

### 주요 특징 및 회고

- [Mango framework](https://github.com/MrARC/Mango) 를 활용하여 작업하였는데 java의
  spring framework 장점인 DI 기반으로 디자인이 되어 있어서 node.js 환경에서 spring 과 비슷한 작업이 가능하였다

- typeorm을 사용하여 DB 모델을 설계하고 객체를 만들어서 비교적 안정적으로 서버 코드 관리를 할 수 있었다.

- typescript 를 통해 nodejs 에서 oop 프로그래밍을 하는 것은 javascript 를 주로 사용해오던
  입장에서 아직 익숙하지 않는 지점은 많지만 oop 개념에 대한 학습과 java를 동시에 학습하는 것 같은 효과가 있다.

- image 파일은 base64 포맷으로 문자열로 컬럼에 저장하였는데, 장점으로는 일반 문자열 처럼
  데이터 핸들링이 간편하고 정적 리소스를 따로 관리하지 않아도 되다. 단점으로는 용량이 37% 정도 늘어나는 단점이 있다.

- 정적분석도구(typescript, tslint, prettier 의 강력한 정적 분석으로 실수를 줄일 수 있었다.

- any 타입을 사용하지 않을 수 있도록 타입 정의를 꼼꼼하게 하는 것은 중요하나 시간이 많이 걸리는 작업이라서 적절한 타협을 했다.



## 프로젝트 기간

- 2018.01 ~

## 요구사항

- 업체 관리 솔루션 으로 발전해 가는 것이 목적임
- 사용자 입장에서 접근성 좋아야 함
- 티켓관리, 회원, 직원 관리, 비지니스 서포팅 등 기능이 필요함
- 정확한 데이터 처리가 필요함
- 폼입력에 대한 확실한 유효성 검사가 필요함
- 푸시 기능 (채팅, 티켓 구매/티켓 취소/예약 요청/환불처리)
- 파트너 사용자의 행동 추적을 위한 데이터베이스 확보 해야함

## 주요 논의 사항

### 업체 관리 솔루션

업체에서 요구되는 회원 관리, 직원 관리, 제품 관리 등 자원 관리가 필요한데 그 부분에 대한 솔루션으로서의 기능을
충족시켜 줄 수 있는 프로그램이어야 한다.

### 코르도바

관리 프로그램은 사용자가 빠르고 쉽게 접근 할 수 있는 형태가 필요하다고 생각해서 업체 데스크탑으로는 웹 접근, 개개인은
모바일에서 빠르게 접근할 수 있는 형태가 적절하다고 생각해서
하이브리드 웹앱을 만들 수 있는 코르도바를 활용하는 것으로 판단했다.

### 퀘이사 vs 아이오닉

코르도바를 활용한 프레임워크 중에 ionic 이 가장 유명하고 커뮤니티가 크다. 하지만 비글램 플랫폼의 대부분이 react 를 사용하고 있고
angular 가 학습 부담이 크다. 하지만 react 생태계에는 코르도바를 활용한 적절한 프레임워크가 없다.
그래서 비교적 학습에 대한 부담이 적은 vue 를 활용한 quasar 를 선택하게 되었다.
하지만 qusar 는 커뮤니티가 작고 코르도바 지원이 풍부하지 않아서 개발 기간중에 많은 어려움을 겪게 되었다.
그리고 버전이 0.x 버전으로 안정화 되어 있지 않은 부분이 있다.
만약 이후 새롭게 프로그램을 만든다면 angular 를 학습하고 ionic 을 활용하는 것이 더 낫다고 생각하는 팀원이 있다.
(지금은 react 를 활용한 ionic 이 개발되었다. 하지만 아직 베타 라서 안정성에 의문이다.)

### 유효성 검사 & 폼 입력

관리 프로그램의 특징인 폼(form) 입력이 많은데 정확한 데이터의 정확성이 필수적으로 요구되기 때문에
유효성 검사를 꼼꼼히 할 수 있는 기능이 되어 있어야 한다.

### 모델 설계

데이터 트랜젝션이 빈번히 이루어지는 특징이 있고 데이터의 무결성이 검증 되는 것이 주요하다고 판단이 되어서
UI / domain 모델을 나누고 데이터 의 불변성을 유지하기 위한 노력이 필요하다고 판단한다.(vuex 를 이용한 state management)

### 비지니스 서포트

파트너 사용자 입장에서의 필요한 기능을 제공하여 더욱 앱에 몰입 할 수 있도록 돕고
실제로 비지니스에 유효하도록 데이터 분석을 통해서 정보를 제공해 줄 수 있는 플랫폼으로 발전 시키는 부분이 필요하다.

## 프로젝트 설계도

하이브리드 앱 제작을 위한 quasar framework의 기본 구성을 지켰다.

```markdown
works-app
├── .quasar : quasar 설정 파일
├── src
│ ├── pages : 페이지
│ │ ├── access
│ │ │ ├── SignInPage.vue
│ │ │ ├── ...
│ ├── components : stateless 순수 컴포넌트
│ │ ├── CheckboxComponent.vue
│ │ │ ├── ...
│ ├── containers : stateful 컴포넌트
│ │ ├── laboratory
│ │ │ ├── LaboratoryContainer.vue
│ │ │ ├── ...
│ ├── layouts : 레이아웃
│ │ ├── partial
│ │ │ ├── Header.tsx
│ │ │ ├── ...
│ │ ├── Blank.layout.tsx
│ │ ├── ...
│ ├── plugins : 앱 초기화시 등록될 플러그인들
│ │ ├── axios.js
│ │ ├── lodash.js
│ │ ├── ...
│ ├── store : vuex 관련 파일
│ │ ├── helper
│ │ │ └── model-helper.js
│ │ ├── layout-model.js
│ │ ├── ...
│ │ └── index.ts
│ ├── router : 라우터
│ │ ├── index.js
│ │ └── routes.js
│ ├── statics : 스태틱 파일
│ └── App.vue : vue 최초 진입 파일
├── config : dev/test/production에 따른 env 정보
├── dist : 웹으로 빌드시 결과 html/js/css 파일
├── .babelrc : es 최신버전 사용을 위한 바벨 적용시
├── quasar.conf.js : quasar 설정 파일
├── postcssrc.js : postcss config 파일
├── package.json : npm 정보
├── tsconfig.json : 타입스크립트 설정
└── tslint.json : 타입스크립트 린트 설정
```

- `src/store/layout-model.js`
  - 모델 파일은 state / getters / mutations / actions 로 구성
  - `namespaced: true` 값을 통해, 중복된 값이 없도록 한다.
  - helper 를 통해 공통적으로 필요한 변수 및 함수를 추가한다.
  - state : 변수와 http 통신에 필요한 상태값, 성공여부 등이 들어간다.
  - getter : UI에 렌더링에 필요한 state 변수의 경우는 getter 를 통해 사용한다.
  - mutation : state 변경시 mutation 을 통해서만 할 수 있다.
  - actions : state 를 변경하기 위해, http 통신을 사용하는 경우 action 을 호출하고 action 내에서 mutation 을 호출한다.

```javascript
// layout-model.js
import {
  stateHelper,
  mutationHelper,
  getterHelper,
} from './helper/model-helper'

const state = {
  ...stateHelper,
  isDrawerOpen: false,
}

const getters = {
  ...getterHelper,
  getIsDrawerOpen: (state) => state.isDrawerOpen,
}

const mutations = {
  ...mutationHelper,
  SET_IS_DRAWER_OPEN: (state, payload) => (state.isDrawerOpen = payload),
}

const actions = {}

export const layout = {
  state,
  getters,
  mutations,
  actions,
  namespaced: true,
}
```

## 주요 기능

_비글램 업체용 works App 시연영상_

[![시연영상](https://i.postimg.cc/Pr4nmy5B/image.png)](https://youtu.be/ynQbqWL6l-g 'bGlam works app')

- 로그인

  - JWT 토큰 인증방식으로 로그인 기능 구현

- 상점관리/서비스/사업관리

  - 태그, 이미지, 운영시간, 태그, 주소 등 다양한 값 CRUD 및 validation

- 직원가입 및 관리

  - 사업자 가입
  - 직원 가입 : 회사코드를 입력하여 사업장에 직원으로 가입
  - 사업장에 소속된 직원 권한 정보 관리

- 예약관리
  - 예약 준비/완료/예약취소 기능
  - 예약 정보 수정

<img src="https://i.postimg.cc/g2ZyCSL7/image.png" width="200" />

- 스케줄 관리
  - vue fullcalendar 를 통해 제작
  - 예약 내용 확인
  - 예약 등록 및 수정 : 드래그 앤 드롭을 통해 예약 등록

<img src="https://i.postimg.cc/tRNMfTG6/image.png" width="500" />

## 향후 발전 방향

- 타입스크립트를 일부만 적용범위를 확장하여 정적 분석을 통해서 오류 최소화
- 기능이 추가될 수록 논리적인 데이터 모델링에 대한 검토는 필수
- Oauth2.0 을 적용하여 유저 가입이 용이하도록 개선
- 채팅 기능을 추가하여 일반 사용자 <-> 업체 사용자간 소통 개선
- 데이터 분석을 심층화 하여 비지니스 윈윈 전략을 위한 프로그램으로 발전



## 프로젝트 기간

- 2019.01 ~

## 요구사항

- 모바일 앱의 주요 기능 구현
- 모바일 프로그램의 한계인 SEO 를 보완하기 위해서 web 애플리케이션이 필요함
- 일반 사용자에게 마케팅이 가능하도록 public 한 정보를 쉽고 빠르게 제공
- 잠재적 파트너 의 접근성(입점 신청)이 필요
- 비교적 관심도가 낮은 사용자의 행동을 분석하고 데이터화 하여 플랫폼의 전략에 필요한 자료로 활용 되는 것이 목적

## 프로젝트 설계도

SSR 을 위한 react 의 next.js 프로젝트로서, next.js의 기본 구조를 따르되 그 외 구조는
`mobile-b2c`과 유사하게 작성되었다.

```markdown
web-b2c
├── .circleci : circle ci 설정 파일
├── pages
│  ├── common : 고객/업주 공통 페이지
│  │ ├── Chat.common.page.tsx
│  │ ├── Chat.common.style.css
│  │ ├── ...
│  ├── b2c : 고객 전용 페이지(common과 동일구조)
│  ├── \_app.tsx : 웹 최초 초기화시 실행
│  ├── \_document.tsx : 서버사이드에서 렌더 되는 header/meta 정보
│  ├── index.tsx : 메인페이지
│  └── index.style.css
├── src
│  ├── components : stateless 컴포넌트
│  │ ├── ChatList.component.tsx
│  │ ├── ChatList.style.css
│  │ ├── ...
│  ├── containers : stateful 컴포넌트
│  │ ├── b2b
│  │ │  ├── chat
│  │ │  │  ├── ChatList.b2b.container.tsx
│  │ │  │  ├── ChatList.b2b.style.css
│  │ │  │  ├── ...
│  │ │  ├──...
│  │ ├── b2c : (b2b와 동일구조)
│  │ ├── common : (b2b와 동일구조)
│  ├── layouts : 레이아웃
│  │  ├── partial
│  │  │  ├── Header.tsx
│  │  │  ├── ...
│  │  ├── Blank.layout.tsx
│  │  ├── ...
│  ├── server
│  │ ├── index.js : next 서버 초기화
│  │ └── next-routes.js : 라우터 정의
│  ├── store : rematch를 이용한 앱 state 저장소
│  │  ├── models : state 모델 정의
│  │  │  ├── b2c
│  │  │  │  ├── domain : 서버에서 받은 원본 domain 데이터
│  │  │  │  │  ├── access-b2c-domain-model.ts
│  │  │  │  │  ├── ...
│  │  │  │  ├── ui : domain 데이터를 가공한 ui용 데이터
│  │  │  │  │  ├── chat-lit-b2c-ui-model.ts
│  │  │  │  │  ├── ...
│  │  │  ├── b2b : (b2c와 동일구조)
│  │  │  ├── common : (b2c와 동일구조)
│  │  │  ├── helper : model 셋팅시 helper 함수 모음
│  │  │  │  ├── res-helper.ts : 서버 통신 후 response 셋팅 헬퍼
│  │  │  │  ├── ...
│  │  ├── types.tx : 모델에서 사용하는 공통 interface 모음
│  │  └── index.ts : rematch 초기화
│  ├── utils : 공통 유틸 함수 모음
│  │ ├── image-util.ts
│  │ ├── ...
├── env : dev/test/production에 따른 env 정보
├── static : static 파일
├── .babelrc : es 최신버전 사용을 위한 바벨 적용시
├── next.config.js : next 설정 파일
├── postcss.config.js : postcss config 파일
├── package.json : npm 정보
├── tsconfig.json : 타입스크립트 설정
└── tslint.json : 타입스크립트 린트 설정
```

- `pages/_app.tsx`

  - 최초 실행시, 1회 실행되는 next.js 파일
  - 페이지들은 \_app.tsx 의 자식으로 렌더된다.
  - state 저장소인`rematch` , `Google Analytics`, `라우터 변화 이벤트`,
    `유저정보 초기화` 등이 이루어진다.

- `pages/_document.tsx`

  - 서버사이드에서만 렌더링된다.
  - `static css/js` 파일들이 import 된다

- `src/server`

  - index.js : express 서버가 초기화 되며, 클라이언트 호출 url에 따라
    `nexts routes`를 사용할 수도 있고, 원하는 서버 비즈니스 로직을 실행시킬 수도 있다.
  - next-routes.js : 브라우저 url path와 실제 페이지를 매핑시킨다.

  ```typescript
  class ApplandingCommonPage extends React.Component<ITermProps> {
    // getInitialProps는 서버사이드에서만 호출된다.
    static async getInitialProps ({query}) {
      // next routes를 통해
      // query Param으로 넘긴 것을 getInitialProps를 통해 받을 수 있다.
      return {
        shopId: parseInt(query.shopId, 10),
        serviceId: parseInt(query.serviceId, 10),
        serviceOptionId: parseInt(query.serviceOptionId, 10)
      }
    }
    ...
  }
  ```

- `src/components`

  - `b2c/b2b/common` 을 구분하지 않고, 재사용 가능한 순수 컴포넌트 들이 위치한다.

- `src/containers`
  - `b2b/b2c/common` 으로 구분된다.
  - `rematch` 를 통해 state 값이 컴포넌트에 매핑되는 형식의 컴포넌트 들이 위치한다.

## 시연영상

[![bGlam B2C web](https://img.youtube.com/vi/wVIrlDs1w_8/0.jpg)](http://www.youtube.com/watch?v=wVIrlDs1w_8 'bGlam B2C web')



## 프로젝트 기간

- 2018.09 ~

## 요구사항

- 단일 코드 베이스로 모바일 어플리케이션 제작 및 유지 보수 해야 함
- 성능 이슈를 최소화 해야 함
- 빠른 개발 / 배포 이루어져야 하며, 비지니스 전략에 대응이 기민해야 함
- 사용자 행동 추적을 위한 데이터 베이스를 확보 해야 함
- open API 및 상용 SDK 활용이 용이 해야함
- 단일 앱으로 사용자 구분 하여 로그인 (업주/고객)
- 단일 앱으로 채팅기능 구분 (업주/고객)
- 푸시 기능 (채팅, 티켓 구매/티켓 취소/예약 요청/환불처리)
- 결제시 처리 해야 할 내용: 포인트 적용/쿠폰입력/결제 모듈/예약
- 검색: 통합검색/필터적용/무한스크롤링
- 예약관리: 예약 알림 시스템(push, sms, mail) / 예약취소 / 확정 / 변경

## 기술스택

- react native

  - 개발언어가 javascript 이고 하나의 코드 베이스로 android / ios 개발이 가능하다.
  - live reload 를 통해서 빌드하지 않아도 코드 수정시 즉시 view를 확인할 수 있어서 개발 생산성이 높다.
  - 브릿지를 통해서 네이티브 코드로 변환해주는 시스템으로 webview 를 이용한 하이브리드 앱(cordova) 보다 성능이 좋다.
  - react.js 베이스로 웹 개발시 코드 재사용에 용이하다
  - 최신버전(0.59) 이 1.x 되지 않아서 불안정하지만 비교적 커뮤니티도 큰 편이고 점차 많이 사용되고 있는 흐름이다.

- typescript(tslint)

  - 정적 분석을 통해서 코드 품질을 향상 시키기 위해 사용하였다.

- redux(rematch)

  - 앱 내부에서 데이터를 중앙에서 관리하기 위한 라이브러리 이다.
  - rematch 를 활용한 이유는 기존의 redux 관련 도구(sagas, thunk) 들은
    action, reducer, effect 를 별도로 작성하는 방식인데 rematch 는 하나의 model 객체 안에
    해당 기능들을 모두 담아서 관리하는 방식이라 비교적 코드 관리가 용이할 것이라는 판단으로 사용하게 되었다.
  - typescript 지원이 매끄럽지 않은 부분이 있다. ex) mapDispatch 부분에서 타입 찾지 못한다.

- react navigation

  - tabbar, sidebar, stack 등 페이지 전환에 필요한 기능을 위해 사용한다.

- firebase sdk

  - 메세지 푸쉬 시스템 적용을 위해서 사용하였다.
  - google analytics 적용을 위해서 사용하였다.

- code push

  - 웹하고 달리 모바일은 배포 관리가 비교적 번거롭고 android / ios 규정에 맞춰야 하며
    두 플랫폼을 동일하게 릴리즈 시점 정하기 까다로운 부분이 많다. 이에 보완 하기 위해 사용 되었다.
  - code push 는 javascript 코드 및 정적 리소스 들을 빠르게 배포할 수 있는 라이브러리이다.
  - MS 에서 유지보수를 담당하는 프로젝트기 때문에 비교적 신뢰 할 수 있다.
  - 경험상 네이티브 수준의 코드들은 적용되지 않는 한계가 있다.

- styled component
  - css 코드를 javascript 로 래핑하여 사용할 수 있고, 동적으로 스타일을 적용할 수 있는 장점이 있다.
  - react native style 작성보다는 css 작성이 더 익숙하고 유지보수가 용이 하기 때문에 적용하였다.

## 프로젝트 설계도

하나의 앱에서 고객/업체 기능을 수용해야하기 때문에 `b2c/b2b`로 네임스페이스를 구분하여 작업하였다.

```markdown
b2c-app
├── .circleci : circle ci 설정 파일
├── android : 안드로이드 네이티브 코드
├── ios : IOS 네이티브 코드
├── src
│  ├── b2c : 고객용 앱
│  │ ├── components : stateless 컴포넌트
│  │ │  ├── ShopComponent.b2c.tsx
│  │ │  ├── ...
│  │ ├── containers : stateful 컴포넌트
│  │ │  ├── main
│  │ │  │  ├── MainCategoryContainer.b2c.tsx
│  │ │  │  ├── MainCategoryStyle.b2c.tsx
│  │ │  │  ├── ...
│  │ │  ...
│  │ ├── layouts
│  │ │  ├── partial
│  │ │  │  ├── Header.b2c.tsx
│  │ │  │  ├── ...
│  │ │  ├── BlankLayout.b2c.tsx
│  │ │  ├── ...
│  │ ├── navigators
│  │ │  ├── SwitchNavigator.b2c.tsx
│  │ │  ├── IntroStackNavigator.b2c.tsx
│  │ │  ├── MainBottomTabNavigator.b2c.tsx
│  │ │  ├── ...
│  │ ├── pages
│  │ │  ├── sign-up
│  │ │  │  ├── SignUpTermFormPage.b2c.tsx
│  │ │  │  ├── SignUpTermFormStyle.b2c.tsx
│  │ │  │  ├── SignUpUserInfoFormPage.b2c.tsx
│  │ │  │  ├── ...
│  │ │  ├── ...
│  ├── b2b : 업체용 앱
│  │ ├── ... : (b2c와 동일구조)
│  ├── store : rematch를 이용한 앱 state 저장소
│  │  ├── models : state 모델 정의
│  │  │  ├── b2c
│  │  │  │  ├── domain : 서버에서 받은 원본 domain 데이터
│  │  │  │  │  ├── access-b2c-domain-model.ts
│  │  │  │  │  ├── ...
│  │  │  │  ├── ui : domain 데이터를 가공한 ui용 데이터
│  │  │  │  │  ├── chat-lit-b2c-ui-model.ts
│  │  │  │  │  ├── ...
│  │  │  ├── b2b
│  │  │  │  ├── ... : (b2c와 동일구조)
│  │  │  ├── common
│  │  │  │  ├── ... : (b2c와 동일구조)
│  │  │  ├── helper : model 셋팅시 helper 함수 모음
│  │  │  │  ├── res-helper.ts : 서버 통신 후 response 셋팅 헬퍼
│  │  │  │  ├── ...
│  │  ├── types.tx : 모델에서 사용하는 공통 interface 모음
│  │  └── index.ts : rematch 초기화
│  ├── utils : 공통 유틸 함수 모음
│  │ ├── image-util.ts
│  │ ├── ...
│  └── index.tsx : react native 최초 진입 코드
├── env : dev/test/production에 따른 env 정보
├── static : static 파일
├── .babelrc : es 최신버전 사용을 위한 바벨 적용시
├── package.json : npm 정보
├── tsconfig.json : 타입스크립트 설정
├── tslint.json : 타입스크립트 린트 설정
└── index.js : react native 초기화
```

- `src/components`

  - `props` 를 통해 컴포넌트 내에서 state가 바뀌지 않는 순서 컴포넌트들이 위치한다.

- `src/containers`
  - `rematch` 를 통해 state값이 컴포넌트에 매핑되는 형식의 컴포넌트 들이 위치한다.

```typescript
// 매핑시킬 State를 선언한다.
const mapState = (state: IRematchState) => ({
  $searchConditionUiStates: {
    serviceCategoryTypes: state.$searchConditionUi.serviceCategoryTypes,
  },
})

// 매핑시킬 state 조작 dispatch를 선언한다.
const mapDispatch = (dispatch: IRematchDispatch) => ({
  $serviceCategoryTypesEffects: {
    selectServiceCategoryTypes: () =>
      dispatch.$serviceCategoryTypes.selectServiceCategoryTypes(),
  },
})

// state와 state를 조작하는 dispatch 함수들이 MainCategory 컴포넌트에 매핑된다.
export const MainCategoryCommonContainer = connect(
  mapState,
  mapDispatch
)(MainCategoryCommon)
```

- `src/navigators`

  - `SwitchNavigator` 를 통해, `Stack Navigator` `Bottom Tab Navigator` 등
    다양한 성질의 네비게이터를 전환해가며 컨트롤시키는 구조이다.

- `src/models`

  - state / reducers / effects 로 구성된다.
    - `state` 는 앱의 변수 값들이 저장된다.
    - `reducers` 는 state 값을 변화시키는 함수로 구성된다.
    - `effetcts` 는 비동기 호출(http)이 필요한 함수들이 선언된다.

  ```typescript
  // src/models/common/domain/account-b2c-domain-model.ts
  export const $isAuthToken = createModel({
    state: isAuthTokenState as IIsAuthTokenState,
    reducers: {
      setState: (state, payload) => ({ ...state, ...payload }),
      setInitialState: (state, payload = isAuthTokenState) => payload,
    } as IIsAuthTokenReducers,
    // 비동기 호출(http)이 필요한 경우 effects를 활용한다.
    effects: {
      async getIsAuthToken() {
        // isLoading 값을 두어, 로딩바를 컨트롤 한다.
        this.setState({ res: { isLoading: true } })
        const res = await axios.post('/common/access/auth-token/is-auth-token')

        if (res.status === 200) {
          this.setState({
            isAuthToken: res.data.isAuthToken,
            // successRes라는 helper 함수를 통해, 균일한 response값을 만든다.
            res: successRes(res),
          })
          // 성공여부 및 http status 값을 리턴한다.
          return successReturn()
        } else {
          this.setState({
            isAuthToken: res.data.isAuthToken,
            res: failRes(res),
          })
          return failReturn(res)
        }
      },
    } as IIsAuthTokenEffects,
  })
  ```

## 주요 논의 사항

### 리액트 네이티브

react native 를 사용하면서 이 플랫폼을 계속 사용하는 것이 좋을까 하는 고민이 되었다.
처음 기대했던 것은 javascript 를 활용해서 앱을 개발할 수 있는 장점이 있지만 코어 기능을 개발 해나가면서
결국 android / ios 코드를 분석하고 작성할 수 있어야 좀 더 확실하게 다룰 수 있겠다는 생각을 하게 되었다.
버전도 1.x 대로 업그레이드가 언제 될지 알수 없고, 생태계를 탄탄하게 지켜주었던 airbnb 팀도
react native 에서 손을 떼게 된 것도 있다.
npm 모듈 생태계는 수많은 유용한 모듈이 존재하는 장점이 있는 반면에 파편화 되어 있어서 서로 호환성을
원활히 유지 되도록 개발자가 많은 조율이 필요하다. react native 는 파편화 + 네이티브 환경 까지 더해져서
빌드 오류를 만나는 경험이 많은 편이다.
'이렇게 개발할거면 네이티브 공부하는게 낫겠다' 하는 생각이 자주 들었다.
그만큼 문제 해결을 위해 모듈들은 더욱 깊게 공부하게 되는 것은 장점인 것 같다.

### 비동기 처리

프론트엔드 영역에서 성능을 크게 좌우 하는것은 비동기 처리에 대한 기민함이다.
리액트 커뮤니티에서 권장하는 대로 dom 이 생성된 이후에 비동기 처리를 하는 방향으로 로직을 작성했다.

### 모델 설계

데이터가 다양해지고 복잡해짐에 따라 모델 설계를 효과적으로 할 필요가 생긴다.
비글램 서비스는 채팅, 결제, 검색등 데이터의 복잡도가 꽤 높은 편이라 처음부터 잘 설계할 필요가 있었다.
UI, domain 데이터 타입을 분리하고 각각의 역할에 맞도록 활용되도록 설계 한다.
깊은 복사가 자주 이뤄지면 성능이 저하되는 경우가 있어서 되도록이면 object 레벨을 낮은 상태로 유지하도록 한다.

### 화면 전환

화면 전환 설계에 대한 부분은 tab navigator 와 stack navigator 를 활용하여
메인 화면에서는 tab, 화면의 deps 가 깊어지는 경우에는 stack navigator 를 활용하였다

### 채팅

채팅은 실시간 비동기 통신이 이루어지고 있어서 앱의 상태에 많은 영향을 미친다. side effect 를 최소화하는
코드를 작성하도록 한다. 그리고 테스트의 양이 많고 범위가 넓기 때문에 꼼꼼히 테스트를 기반으로 하는 작업이
필수 였으나 시간문제 때문에 테스트 중심으로 작업을 하지 못한 점이 아쉽다.

## 주요 기능

_비글램 b2c App 시연영상_

[![시연영상](https://i.postimg.cc/Prmr01r4/image.png)](http://www.youtube.com/watch?v=M_faTTDGKUI 'bGlam b2c app')

- 일반/카카오 로그인
  - JWT 토큰 인증방식으로 로그인 기능 구현
  - 포커스 아웃시, validation 되도록 작업

<img src='https://i.postimg.cc/PxMXq93x/login.png' width="200" border='0' alt='login'/>

- 검색페이지
  - elasticsearch 를 통한 통합검색
  - infinite scrolling/lazy loading
  - 가격/필터 검색 기능
  - 서비스별/업체별/지도 검색 기능

<img src="https://i.postimg.cc/0NxhNQLY/search.png" width="200" />

- 채팅
  - chatkit 을 활용한 채팅 리스트/내역
  - 새 채팅 도착 알림
  - 온/오프라인 여부, 채팅입력중 여부, 읽음 여부 체크 기능
  - 채팅 내 관심상품/구매한 상품 리스팅
  - 채팅 내 서비스 예약기능

<img src="https://i.postimg.cc/C15PZfJq/chat.png" width="200" />

- 결제과정

  - iamport 모듈 통한 결제 연동
  - 티켓 개수 변경
  - 쿠폰입력, 포인트 사용 기능

  <img src="https://i.postimg.cc/VvbKgQxs/pay-1.png" width="200" />

- 구매내역
  - 사용가능/사용완료/환불요청/환불 완료 탭
  - 업체 및 고객센터 채팅 문의

<img src="https://i.postimg.cc/sgyRMwWG/paymented.png" width="200" />

- 업체 티켓 관리
  - 구매내역/사용예정/사용완료/정산내역 탭
  - 예약하기
  - 고객과 채팅 기능
  - 완료 처리

<img src="https://i.postimg.cc/8zHgMMdK/works-ticket.png" width="200" />

## 향후 발전 방향

- 테스트 코드를 작성하여 런타임 오류 최소화
- 로그인 하지 않아도 앱 내부를 탐색할 수 있도록 개선
- 중복되는 데이터가 있는데 모델 구조 개선을 통해서 모델 구조를 단순하게 만들기
- redux-persist 를 활용하여 보안 문제가 없는 데이터는 로컬 스토리지에 캐시 할 수 있도록 하기
- Oauth2.0 표준에 적합하도록 카톡 로그인 개선
- 시간 문제상 채팅 SDK 함수들의 비효율적인 코드 생산에 대한 개선
- 사용자 행동 분석, 빅 데이터 분석을 통해서 개인맞춤 페이지 추가
- 일반사용자 <-> 업체사용자간 소통이 더 밀접해질 수 있도록 채팅 시스템 개선
- 사용자 커뮤니티 활성화를 위해서 리뷰 및 QnA등 시스템 마련



## 프로젝트 기간

- 2018.02 ~

## 개요

여러개의 nodejs(express) 서버에서 공통적으로 사용하는 코드들이 많아짐에 따라서
별도로 분리하여 관리해 나가기 위해 구성한 패키지

## 주요 특징

공통적으로 이용해야 하는 목적으로 순수한 함수형으로 코드 작성
(순수 함수 유지 => 동일한 인자로 함수 호출시 동일한 리턴 값 보장)

## 핵심 기능

- error middleware : boom 라이브러리를 통해서, 에러 코드에 따른 에러 처리
  - 요청 에러 400번대와, 서버에러 500번대의 경우 에러 테이블에 저장하여 에러 분석에 사용하였다.

```javascript
switch (err.typeof) {
      // 4xx Errors
      case Err.badRequest:
        // 400 Bad Request
        break;
      case Err.unauthorized:
        // 401 Unauthorized
        break;
      case Err.paymentRequired:
        // 402 Payment Required
        break;
      ...
}
```

![img](https://i.postimg.cc/G2XkM1W0/image.png)

- notification : mail, push(mobile), sms 등 처리에 대한 템플릿과 로직을 구성
  - 실시간 예약 여부 확인을 위해, 업체용 앱과 고객과의 notification 을 다음과 같이 설계하였다.

![img](https://i.postimg.cc/L6xdFyPm/image.png)

- libs : 전반적으로 활용될 작은 util 함수들 모음(format 변환, 토큰 생성 등)
- services : orm(bookshelf.js)을 통한 데이터 베이스 트랜젝션(CRUD) 수행을 위한 공통 함수들 모음
- zinrelo : zinrelo 포인트 시스템 서비스를 이용하기 위한 api 요청 함수들 모음
- file : file(static resourc) 들을 변환하고 저장하기위한 함수들 모음

  - multipart형식으로 데이터를 받아, AWS S3에 저장하는 방식으로 구현하였다.
  - 이미지의 경우, 썸네일/웹/앱용으로 여러장 저장해야하기 때문에 imagemagic 라이브러리를 사용하여,
    resize 후 최적의 압축률을 실험해서 저장하였다.
  - 이미지 압축률 개선 후 29% 만큼의 성능 개선이 있었다 (Google Audit Performance)

- global_method: 전역에서 사용할 변수들을 세팅하는 함수
- i18n : 국제화 작업을 위한 함수들 모음(미구현)
- refund : 결제 취소 처리에 대한 함수(iamport 활용)

## 적절한 공통화

1. 도입 : common 모듈의 시작

바뀌는 코드들은 많은데, 프로젝트마다 다 나누어져 있어서 동일한 작업을 매번 반복해주어야 했고,
이 과정에서 누락되는 실수들이 자주 발견되었다. 그래서 `common` 모듈의 필요성이 대두되었다.
각 프로젝트에서는 common 모듈을 소프트링크를 통해 공유해서 사용하였다.

2. 초반 : ORM에 필요한 database model / services 파일들의 공유

초반의 common은, ORM에 필요한 database model 들과, services들이 모두 들어가 있었다.
그래서 ORM을 사용하는 모든 백엔드에서 해당 코드들을 공유하였다.
그러나 앱서비스를 시작함과 동시에 배포시점이 달라졌고, 코드 하나를 수정하면
다른 모든 프로젝트에도 영향이 가기 시작하면서 안정성 문제가 대두되었다.

3. 중반 : git Submodule의 사용

model들과 services들은 변동이 크지 않은 데이터베이스에 의존하는 내용들이고
따라서 공통화 시키되 프로젝트마다 다른버전의 common 파일을 가질 수 있도록
`git submodule`을 사용해보고자 하였다. 그러나 git submodule에 대한 학습이 필요했으며,
여러버전의 common 모듈이 생겨남으로써, 빌드 배포 프로세스가 지나치게 복잡해진다는 의견이 있었다.

4. 현재 : ORM에 필요한 database model / services 파일들의 제거

개발이 후반부가 되면서 테이블이 빈번하게 수정될일이 줄어들었고,
submodule 때문에 빌드 배포 프로세스가 복잡하게 되는 것 보다,
models과 services를 프로젝트마다 별도로 갖고 있는 것이 더 이득이 되지 않겠냐는 의견이 나왔다.
그래서 현재와 같이 database 영역이 제거 되고, 유틸함수/미들웨어들만을 공유하는 구조가 되었다.

## 향후 발전 방향

- 함수형 기법을 적극 활용하여 순수하고 안전한 코드 작성
- 테스트 프레임워크를 적용하여 테스트 주도적으로 코드 작성
- 에러 리포팅 기능 자동화



## 프로젝트 기간

- version 2.0 : 2018.01 ~

## 요구사항

- 적은 인적 자원으로 많은 기술적 요구와 효율을 충족 시켜야 함
- 애자일 방법으로 빠른 개발/배포가 이루어져야하며, 급격하게 변화하는 비지니스 전략에 대응이 기민해야함
- 새로운 직원을 고용할 경우 빠르게 학습이 가능 해야 함
- 사용자 행동에 대한 되도록 많은 데이터의 축적을 필요로 함
- open API 및 상용 SDK 활용이 용이해야 함
- 결제및 개인 정보등 데이터 무결성 및 안정성이 확보되어야 함
- 웹 기술을 기반으로 하는 HTTP 프로토콜에 대해서 탁월히 대응해야 함
- 에러에 대한 역 추적이 가능해야 함
- aws 클라우드와의 궁합이 좋아야함
- 회원 가입, 로그인 및 인증 시스템에 대한 최소한의 보안은 지켜져야 함
- 카카오 로그인 가능해야 함
- API 문서가 필요함
- 빠른 검색기능이 필요함
- 사용자 포인트 기능
- 채팅 기능

## 기술 스택

- Node.js Express

  - 백엔드, 프론트엔드 작업이 가능하기 때문에 javascript를 활용한 nodejs 를 선택하였고,
    nodejs 환경에서 웹 환경 및 HTTP 프로토콜 에 적절히 대응, 안정성이 증명된 express 웹 프레임워크 활용하기로 하였다.

- REST API 지향

  - 리소스 설계에 적절한 REST API 활용한다.

- JWT Token

  - stateless 인증 방식으로, 서버 부담이 상대적으로 적고 구현 및 웹/앱에서 모두 사용이 가능하며,
    express에서 jwt 미들웨어의 지원도 강력하기 때문에 jwt token 인증방식을 선택하였다.

- swagger

  - 매번 API 문서를 수정해야하는 번거로움을 방지 하기 위해, swagger를 통해 api문서를 자동으로
    작성되도록 하였으며, swagger 페이지에서 api를 테스트해 볼 수도 있다.

- RDBMS : Postgresql

  - 실시간 예약과 결제 데이터가 있기 때문에 데이터의 일관성이 보장되는 RDBMS를 사용하기로 하였다.
  - MySQL에 비해 SQL 표준을 잘 따르고 완전한 오픈소스이며, 다국어 지원 기능을 위한 JSON type을
    활용할 수 있는 장점이 있어 선택하였다.

- Elasticsearch

  - 상품을 통합 검색하며 향후 실시간 예약 가능 여부에 대해서도 요구사항이 있을 수 있기 때문에
    별도 검색 엔진을 두는 것이 좋다고 판단하였다.

- ORM : knex.js & bookshelf.js

  - 초기 ORM에 대한 학습 비용이 있지만, 패턴을 익히면 별도 쿼리를 짜지 않아도 빠르게
    비즈니스 로직 개발이 가능하다고 판단하였다.
  - 성능에 대한 이슈가 있는 부분에 대해서만, 별도 쿼리를 작성하였다.
  - knex & bookshelf js : 간단하면서도 knex를 통해
    구체적인 쿼리 빌딩이 가능하다는 의견이 있어 선택하였다.

- Lucidchart(다이어그램 협업툴)

  - 데이터베이스 수정시에 Lucidchart에 변경사항을 반영하여, 실시간으로 수정내용을 알 수 있게 한다.

- Circle CI

  - 빌드/배포 자동화를 통해, 즉각적으로 수정 내용을 테스트/확인할 수 있도록 하였다.

- zinrelo(포인트관리 시스템)

  - 포인트 시스템에 대한 노하우를 얻고 실제 결제에 대한 위험부담이 있어서 외부라이브러리인
    zinrelo를 활용하였다.

- chatkit(채팅 라이브러리)
  - 웹소켓통신 서버에 대한 안정성 및 확장성, 채팅 데이터 관리의 용이성, 유틸들이 있어
    chakit 라이브러리를 활용하였다.

## 프로젝트 설계도

scv2.0의 프로젝트에서 담당 로직은 다음과 같다.

- 비글램 앱/웹의 백엔드(server side) 기능
- 데이터베이스 초기화/마이그레이션
- 스케줄링(배치)

```markdown
scv2.0
├── .circleci : circle ci 설정 파일
├── common : 공통 미들웨어/모듈 위치
├── database : 데이터베이스 초기화, 마이그레이션, 초기 데이터 파일 위치
│  ├── init-tables : DB 테이블 초기화
│  ├── migrations : DB 테이블 수정 내용
│  └── seeds : 초기 데이터 seed 파일
├── models : ORM 사용을 위한 데이터베이스 모델
│  ├── tb-bglam-users.js
│  ├── tb-shops.js
│  ├── ...
├── routes : 라우터 위치
│  ├── app-b2b : 앱 업체용 라우터
│  │ ├── business
│  │ │  ├── business-app-b2b-route.js
│  │ │  ├── ...
│  ├── app-b2c : 앱 고객용 라우터
│  ├── common : 앱/웹 공통으로 사용될 수 있는 라우터
│  │ ├── access
│  │ │  ├── access-common-route.js
│  │ │  ├── ...
│  ├── swagger : API 문서화를 위한 swagger 라우터
│  ├── web-b2c : 웹 고객용 라우터
│  ├── web-common : 웹 고객/업체 공통으로 사용될 수 있는 라우터
├── scheduler
│  ├── elasticsearch-scheduler.js
│  └── zinrelo-scheduler.js
├── services
│ ├── users-services.js
│ ├── shops-services.js
│ ├── ...
├── config.js : dev/test/production에 따른 계정/설정 정보
├── package.json : npm 정보
├── swagger.js : swagger 초기화
└── app.js : express app 초기화
```

### 라우터

#### 라우터 설계원칙

- RESTful API 설계 원칙 준수
- ES8 async/await 를 활용하여 비동기 처리 작성
- errorHandler 미들웨어를 작성하여, 에러 공통 관리
- response에 리턴은 명시적으로 작성하여 명확하게 한다.

```javascript
const router = require('express').Router()

// DB와의 통신을 담당할 service를 require한다.
const businessService = rootRequire('services/business-service')

// 라우터 로직에 errorHandler를 래핑시켜, try/catch 없이도, 에러 핸들링이 가능하도록 하였다.
router.get('/:businessId/shops', errorHandler(async (req, res, next) => {
  if (_.isEmpty(req.params.businessId))
    throw Err.badRequest('로그인을 다시 해주시기 바랍니다.')

  // await를 활용하여 비동기 처리
  const business = await businessService.selectBusiness({
                     id: req.params.businessId }, ['$vwShopOnlines'])

  res.json({
    result: true,
    // 명시적으로 return type을 지정해준다.
    business: {
      businessId: business.id,
      shops: _.map(business.$vwShopOnlines, v => ({
        shopId: v.shopId,
        shopName: v.name,
        ...
      }))
    }
  })
}))

module.exports = router
```

#### 서비스

ORM을 활용하여 DB에 질의를 한다. es6의 Destructuring을 활용하여,
여러 `related`(join table)들을 해올 수 있게 구성하였다.

```javascript
exports.selectBusiness = async (param = {}, [...relate] = []) => {
  const business = await $m.Business.forge()
    .query((qb) => {
      if (param && param.id) {
        qb.where('id', param.id)
      }
    })
    .fetch({ withRelated: [...relate] })
  return business ? business.toJSON() : null
}
```

#### 모델

```javascript
// tb-business.js
$m.Business = $bs.Model.extend({
  tableName: 'tb_business',
  hasTimeStamp: ['created_at', 'updated_at'],

  // 해당 테이블과 연관된 테이블의 관계를 정의하고, 함께 질의해올 수 있도록 한다.
  $vwShopOnlines() {
    return this.hasMany($m.VwShopOnline, 'business_id')
  },
})
```

## 핵심 모듈

### 오픈소스

- express : nodejs 환경에서 가장 많이 사용되는 web framework
- express-jwt : user access 보안을 위한 jwt 라이브러리
- body-parser : 클라이언트의 POST 요청에서의 body 추출을 위한 라이브러리
- cookie-parser : 클라이언트로부터 요청된 쿠키를 추출하기 위한 라이브러리
- compression : response 내용을 압축하여 성능을 향상 시키기 위한 도라이브러리구
- axios : http 요청을 위한 라이브러리
- multiparty : 파일 업로드를 위한 라이브러리
- lodash / partial-js : 데이터를 조작하기 위한 함수형 라이브러리
- moment : 시간에 대한 포맷을 변환하기 위한 라이브러리
- node-schedule : 주기적인 데이터 처리를 하기 위한 라이브러리
- swagger : API 문서를 웹페이지로 만들어주는 라이브러리
- node-mailer : 메일을 보내기 위한 라이브러리
- morgan : dev 환경에서의 logging 을 위한 라이브러리

### 외부 SDK

- aws elasticsearch : 빠른 검색을 위한 aws 서비스

## 데이터베이스 설계원칙

- 테이블에 "타입"을 두기 보다는 구체적인 새로운 테이블을 만든다.

  - 타입값을 두는 것이, 테이블 수를 줄이는 장점이 있지만, 개발자의 실수 가능성과
    테이블명이 모호해지는 단점이 있다고 판단하여, 새로운 테이블을 만드는 방식으로 설계하였다.

- view 테이블을 활용하여, 테이블 수가 많아져도 질의에 불편함이 없도록 한다.
- Default 값과 Not Null 값을 두어, 값이 잘못 입력되는 것을
  데이터베이스 제약조건 레이어에서 차단한다.

## 백엔드 구성에 대한 고민

### 공통화 및 추상화

공통화를 통해, 코드를 더욱 짧고 간결하게 하며 동일한 수정을 막는 장점이 있었지만
요구사항이 빈번하게 수정될 경우 오히려 다른 코드까지 영향을 주는 경우가 생겼다.
이런 지점에서 어떻게 코드를 작성해나가면 좋을지에 대한 고민을 했다.

#### 함수형 프로그래밍

최대한 함수 단위를 세밀하게 쪼개서 프로그래밍 함으로써, 중복되는 코드 작성을 막으면서도
의존성으로 인한 사이드 이펙트를 최소화한다. 또산 주석 없이도 더 간결한 코드 이해가 가능해진다.

#### 공통화는 가능하면 나중에

중복되는 코드가 생길때 바로 공통화를 해나가기 보다는 어느 정도 시간적 여유를 두고
공통화시켜도 되겠다는 판단이 되는 시점에서 작업하는 것이 요구사항 변경에 따른 불필요한 작업을 최소화
시킬 수 있을 거라는 판단이 들었다.

#### 라우터 구조

라우터에서의 함수형 프로그래밍을 잘 활용하기 위해서, "라우터" 폴더에
'helper 함수'를 두는 것이 좋다고 논의하였다. 예를 들어 일반 로그인과/카카오 로그인이 있다면,
**라우터 경로는 따로 두되, 공통으로 사용되는 부분을 helper 함수로** 분리 하는 것이다.

```markdown
access-kakao-route.js
access-normal-route.js
access-helper.js
```

### 마이크로 서비스 아키텍쳐

고객용 앱/웹, 업체용 앱/웹, 관리자용웹 과 같이 서비스가 커지고,
웹과 앱의 배포 방식 또한 다르다 보니 모놀리틱 아키텍쳐 방식에는 한계가 있음이 느껴졌다.
코드가 중복되는 지점이 있더라도, 하나의 백엔드 서버였던 것을 분리하며 일차적으로 서버를 분리하며,
향후에는 더욱 기능들을 모듈화하여 마이크로 서비스 아키텍쳐를 지향해야할 필요성을 절실히 느꼈다.

### 타입 시스템

요구사항 변경이 빈번하여 코드 수정이 많기 때문에, request와 response의 데이터 타입을
명시화해두지 않으면 작업은 빠르게 되겠지만 안정성이 심각하게 무너졌다.
또한 직접 호출해보지 않으면 어떤 데이터들이 오가는지 파악하기도 어려웠다.
그래서 타입을 명시화해주기로 하였으며, 향후 typescript 적용을 고민해보았다.

## 향후 발전 방향

- typescript 적용을 통해서 type safe 한 코드 작성
- 함수형 프로그래밍을 통해서 읽기 쉽고 짧은 코드 작성
- devops 를 위한 docker 적용 및 ci / cd 최적화
- 전체적으로 마이크로 서비스를 위한 백엔드 아키텍트 설계
- 데이터 분석을 위한 데이터 축적에 최적화 할 수 있도록 설계
- api 부하 테스트를 통해서 성능 저하가 발생하는 지점 중심으로 성능 개선
- 비동기 처리를 적극 활용하여 성능 개선
- 정적 리소스(이미지 등)는 별도로 서버를 구성
- redis(in memory) 적용으로 데이터 캐싱을 통해 성능 개선(혹은 LRU Cache 적용)
- auth 서버를 별로로 구성하여 private data 에 접근할시 안전하게 접근 가능하도록 guard 적용
- oauth 활용한 경우(kakao, google 등) oauth 인증 원칙에 맞춰서 설계 및 적용


sangza

스마트로 선불 충전(White label) 시스템 구축

통합 온/오프라인 간편결제(CJ One Pay) 구축

Alliex 베트남 결제 중계 시스템 구축

JTNET VAN CMS 시스템 구축

롯데마트 마튜브 V-COMMERCE 구축

bGlam 스파/마사지 O2O 플랫폼 구축 및 운영

sangza