# Day 6

## 이번주 죽어도 할 것

1. 이슈 만들어 둔 것들
1) core SDK 구현
2) DB 설정 및 core SDK 관련 API 구현
3) error 조회
2. swagger 설정
3. ReadMe 추가
1) 이쁘고 멋있고 보기좋게
4. Wiki 수정
5. Backend API
6. NPM 배포 시도
7. 1-6까지하면 코드리뷰해달라고하자
8. 핵심 기술 뭐할지 생각하기 !
9. test coverage 관리하기

#### 핵심기술에 대해서

- 핵심 기술 : https://jiransnc.com/index.php/logcenter 의 밑 특장점과 같이 우리만의 특장점 하나를 정해서 그거 위주로 하자 .
## 오늘은 못 자도 할 것
1. Express에 Swagger 추가
2. server 에 사용하는곳 정보 받아오기
3. SDK 에서 메세지 보내기
4. mongodb 설정

- 추가할 API이 있다면 이슈 추가하기

## 내일(화요일)할 거
1. NPM 배포
2. 나머지 API 만들기
3. 나머지 테스트 코드 만들기

## 수요일할 거
1. test-coverage 측정하기
2. API, 테스트 코드 못만든거 있으면 만들기

---
## 🙋🏻‍♀️ 우리의 논의 ! 🙋🏻‍♂️
### 협업 방식에 대한 논의
> SDK와 서버 개발 작업을 어떻게 진행할 것인가!
>
1안) sdk 마무리 - 1명 , server - 3명

2안) sdk, server 2명 2명

3안) server sdk 모두 다 같이
- 석민: SDK 같은경우 라이브 쉐어로 아직 푸쉬를 안해서 다같이 하는게 좋을거 같고, 서버같은 경우 내가 폴더구조를 어느정도 나눠놔서 빠르게 할거 같다.
- 원호: 2:2 보다는 4:0 4:0 이 좋아서
- 혜라: 서버를 먼저 만들어야 sdk 나머지기능을 테스트 해보면서 만들 수 있을 거 같다!/ 그리고 초기 구조는 모두의 의견이 중요하다고 생각한다.
- 은빈: 서버는 같이 하는게 좋다고 생각함. 초기 구조 모두의 의견이 중요하다는 것 동의 +

4안) server 4 sdk 2명 / => 2명 다른 뭔가!

5안) 초기구조만 4명 붙고 API 만들때 4명 붙을 필요 없다 + sdk -> 4명 붙으면 안돼 !! (1~2 명이 적당하다고 본당.! )

... 두개를 합치면!

결론: server 초기 폴더구조 | db 연결 | swagger 설정 + API 한 개 ( pagination ): 다같이
이후, SDK: 2명 + 나머지 2명 ?!!

### test coverage 에 대해서
> test coverage는 어떻게 문서화 할 것이고, 언제 확인할 것인가
>
- jest --coverage 로 테스트하자
- 파일에 대한 어느정도의 coverage 가 나오는지 test coverage 를 작성하면서 알아보자

### swagger 사용법
> 주말동안 사용해본 swagger 기능에 대한 공유
- postman 처럼 기능이 있어서 전부 테스트하면 됨! (postman 을 쓰지 않고 테스트 할 수 있음! )
- 목록도 뜬다
- 나누는 법을 같이 찾아보자!
- JWT 토큰과 같이 로그인 상태를 유지할 경우를 알아보자.

### production과 development env에 따라 swagger route 구분 방법
Q. API Key -> .env 파일에 넣어두면 되지 않을까?!!

### MongoDB only vs MongoDB + Mongoose
> MongoDB를 처음 사용하는데 Mongoose를 같이 사용해도 괜찮을까? MongoDB가 더 헷갈려지지는 않을까?
>
- collection 을 생성할 때 Sequelize와 같이 모델을 만들어 사용한다.
- MongoDB는 모든언어 (java, python 등)에 대한 문서가 있어서 그 문서를 참고하여 javascript에서 사용하기 편하게 만든것이 Mongoose이다.
- typescript 와 같이 사용하기에 mongoose 가 더 편한 거 같다
- Sequelize처럼 Collections마다 변수가 있어서 new db.user({name: 'Santry'})와 같이 쉽게 선언 가능
- MongoDB의 경우 mysql2처럼 해당 쿼리를 그대로 넣어 사용해야 한다.

-> SDK를 class 써서 Server도 SDK와 일관성이 있게 구현할 수 있을 거 같다.

### 어떤 server를 쓸 것인가
>
pm2 clustering : stateless 하게 만드는게 중요함.( 서버에 변수를 못씀 ?!/ state 를 저장할 수 없음 ) -> Session을 사용하지 않고 token 을 이용해서 하는 login 으로 해야할 거 같다.
-> core 8개 8GB ram vs core 4개 16GB ram
-> Quad-core, 8GB ram 낙찰 (석민아 고마워~ )
석민의 생각 : 처음부터 좋은 서버를 빌려서 ㅎㅎ 성능을 높여보쟈!! 낮은 성능에서 돌아가는건 스트레스 테스트로 가능!

### Token 저장: Local storage vs Cookie

- 결론 안났다. 수요일에 다시 결론 내기로 !
> login에 따른 token 어디에 저장할 것인가
>
#### Local Storage
- 장점
- 쿠키에 비해 많은 정보를 저장할 수 있음 (쿠키에 4KB, localStorage 는 MB 단위)
- 쿠키와 달리 필요할 때만 Request를 담아 보낼 수 있다.
- 단점
- 보안성이 취약하며, 이를 해결하기 위해 토큰에 Origin IP정보를 담아 보내지만 구현이 복잡하다.
- token: asdf23923j239f1j3f
- {
user: 1,
ip: 111.111.111.111 // client IP // 이동중에 이사이트를 쓰면? 바뀜
}
->-> req.header.originIp === token.ip
request.ip / token.ip

로그인할 때마다 내 기기 IP 의 토큰을 새로 준다.
그럼 ? 내가 이동해서 IP가 바뀌면 (wifi 바뀜) request IP != token. ip
- OAuth의 경우 토큰방식으로 구성되어 있어서, passport를 사용하지 않고 직접 구현해야 한다.
- 이동중에 originIP가 바뀔경우 다시 로그인해야한다.

#### Cookie
- 장점
- 구현이 간단하며, Passport-OAuth를 사용하기 쉽다.
- 단점
- 원하지 않을때도 request에 쿠키정보를 계속 담아서 보낸다.
- 저장공간이 부족하다.
- 로그아웃 API를 따로 만들어야한다.

[로컬스토리지 취약성](https://snyk.io/blog/is-localstorage-safe-to-use/)