## 오늘은 못 자도 할 것 - NCP 서비스 Server - SDK 랑 맞추기 ( DB에 들어갈꺼랑 ) - test-coverage 측정하기 - SDK쪽 API, 테스트 코드 못만든거 있으면 만들기 - 멘토링 준비 - Swagger, webpack production 넣는것 -> nep ! - df?? ## 내일 할 거 - event 받아오는거 프론트에서 해라 - JEST 사용 - ### 멘토님 질문 - 웹팩 고려? 소스맵 찾아서? - 핵심기술? 어떤 부분에 좀 더 집중하면 좋을지 => - 기능을 빠르게 만들어서 코드의 구조적인 부분을 더 부각시키면 좋겠다. 디자인패턴도 적용하길 바람 - PM2 클러스터링은 버전업이 되면서 많이 개선되었다. - 성능 개선은 무거운 코드가 없기 때문에 많이 힘들거 같다는 예상 - 백엔드에서 React, Express로 나누지말고 하나로 합치고 내부에서 나누자. - 리액트 HOC (high order components) -> 로직 재활용 - PureJs 기반 후 React, Express SDK 작업 - Cors => origin: true - tsc는 안쓰는 추세 => 주로 babel-loader를 사용한다. - 프론트 CSS는 Material UI를 추천 -> 커스텀마이징이 쉽다. - yaml(야믈)이 요즘 많이 쓰임 - locale or moment 관련해서 (node module 크기가 크다) 웹팩 설정을 잘하자. 1. pm2 clustering 클러스터링 할건데 1.1 리로드 하는 과정에서 새로운 프로세스 준비 되기전에 ready 메시지를 보낸다. 준비 되기전에 자빠진다 .는 이슈가 있다는걸 알게됨 -> 우리도 뭔가 이렇게 pm2 클러스터링 해서 서버 올리면은 문제가 발생할 수 있는데 주의할 필요가 있을까? 1.2 실제 서비스 할때 서버가 멈추는 경우가 많나요? => 기존에 운영할때는 서버가 멈추는 경우를 당연히 여겨서 watchdog과 systemctl을 이용해서 자동으로 재부팅 하는 형식으로 하였습니다. 1.3. 이외에 좋은 서버 성능 개선 방안이 있을지? 쉽고 공부할만한거 ?? 4. 무한 루프로 인해 에러가 계속 오는 경우 서버는 서버대로 부하가 걸리지만 실질적으로 무한루프로 인해 발생한 에러 개수이기 때문에 많은 양이 오는 것이 유의미한지 모르겠다. 지금까지 구현 현황 관련 질문 2. express 는 미들웨어로 만들어서 에러를 잡았는데 ... + try catch 놓치는 에러가 있을지? 다양한 에러 상황에 대한 테스트를 해보기가 어려움. 그래서 현재는 단순하게 throw error 정도로 테스트하고 있는데, 생각하지 못한 에러상황은 없을지 확신이 안생김(?)어떤 상황에서 에러가 나는지를 잘 몰라서 이런 생각이 드는건 아닌지..ㅠ - 3.프로세스가 갑자기 죽는 경우????! 이렇게 구현했을때 놓치는 에러가 있을지? watchdog ????! 3. pm2 clustering 구현할 생각인데 어떻게 생각하는지 4. CORS 옵션을 SDK 모듈 때문에 origin: true로 설정해야 하나요? 5. process.uncaughtException(err){ } 별도 서버에 만든 다음에 해당 서버에서 테스트 서버를 별도로 만드는게 더 정확함 테스트도 별도 서버에서 호출하면 문제가 없을 듯 아트렐리를 로컬에서 띄우니까 로컬 장비에서 소켓 타임아웃이 나는 것 테스트 서버도 소켓을 열어놔야 소켓을 최대한 열고 테스트를 해야함 해보면 좋다. 라는 내용 하는 것부터 빨리 완성한 다음에 나중에 퍼포먼스 테스트 이런거 할애하는거에 시간이 아까움 다 소켓 타임 pm2로 클러스터링, 노드 클러스터 이거는 해줘야됨 클러스터 하면서 생각해야할 부분? - 서버 인스턴스 자체를 이중화해줘야함 그 안에서 노드 클러스터링을 해주게 될텐데 l4 load balance에서 pm2 를 up-down - l4에 이중화될 때 l7 체크를 해서 인스턴스가 살았는지 죽었는지 알려주는데 확실하게 체크해서 fail 보내줘서 instance 빠진 다음에 pm2를 내렸다 올려주면 될 듯. 이중화를 하게되면 pm2 자체적으로는 - sigint 날려주는 로직은 넣어줘야함 reload 하던지 sigint 값을 주게됨 l4에 연결이 돼서 일정 시간 뒤에 health check 값을 l4에서 뺴달라는 404 return, 일정 시간 뒤에 node 죽이는 작업을 한번 해야함. node에서 sigint 를 받는 class, method 찾아서 404 return 해주고 일정 시간 뒤에 node 를 kill 해주는 로직을 담으면 됨. 구조적인거를 더봤으면 좋겠음. 코드의 구조를 잘 잡는 것을 부각했으면 좋겠음. node http spec에 맞는 기능은 빠르게 만들고 구조적인걸 개선하는 걸 심화로 잡으면 좋겠음 axios를 사용하는데 sdk에서도 사용하고 react, js용에서도 사용할텐데 http request 를 따로 나누려고 별도 http client를 만든 다음에 전략 패턴같은걸 이용해서 base client를 쉽게 만들고 쉽게 갈아끼기 쉽게 공통적으로 쓸 수 있는 것들은 공통화 해서 모듈화하고 디자인 패턴 사용할 것이 있으면 사람들이 쉽게 쓸 수 있게 구조적인 것 SDK 쪼개서 strategy pattern 이용해서 구조적으로 만들면 좋을 것 같음 퍼포먼스 개선 좋은데 쉽지 않을 것 같다. 무거운 로직이 많이 없을 것 같아서 개선이 될 점이 많지 않을 것 같다. 가시적으로 퍼포먼스 성능이 올라갈 포인트가 있을까 하는 생각이 든다. 그런 포인트가 보이면 퍼포먼스 테스트 하면 좋을듯 백엔드는 error를 받는 endpoint는 하나로 interface는 같으니까 관리 포인트만 많아지지 error가 들어오는 Endpoint는 하나로 두고 미들웨어로 잘 처리해서 프론트엔드는 하이오더컴포넌트 HOC higer order component 로직을 재활용해서 동일 로직을 여러컴포넌트가 가지고 있을 때 코드 동일 작업을 안하게 하는. 구조적으로 component, container 잘 이해해서 component state 갖지 않게 해서 최대한 재활용할 수 있게 하고 container는 state를 넣어서 활용 uncaughtException uncaughtRejection 처리할 수 있도록 on off 로 킬 수 있나 그랬던 것 같음 sdk에서도 해줄 수 있고 개발자가 선언해서 catchException을 사용해서 할 수도 있고 굳이 없어도 넣을 수 있는 부분 기능적인 확장 vs 플랫폼적인 확장 어떤 기능이냐에 따라 다를 것 같음 pure js를 기반으로 먼저 만들고 그러고나서 express, react는 어차피 pure js를 기반으로 만들어지니까 어렵지 않을 것 같음. 그걸 기반으로 빠르게 express, react용 만들면 될 듯. pure js 먼저 만들고 시간이 되면 기능적 sampling 기능 너무 많이 날아가면 네트워크 대역폭을 낭비하는 거니까 100개면 100개를 다 날리는게 아니라 20%만 날린다던지 100%를 받나 10%를 받나 똑같으니까. 너무 플랫폼적인거 많이 만들지 않아도 될 것 같음. pure, react, express 3개정도 좋을 것 같음. dsn을 봤는데 하드코딩해서 들어가있음. 나중에는 받을 수 있게. 어디다 쏠 것인지 dsn 넣을 때 이중화 할 때 vip domain까지 받는가? sdk에서 받을 수 있도록 개발. 어디에 보낼 지에 대한 domain, project id -> parsing 해서 날아가는 형태 주입 받아서 호출만 하면 되는 거니가 서버쪽 웹팩으로 빌드하는 module alias, swagger 요새는 tsc안쓰로 babel plugin으로 보통 하고 보통 babel으로 처리함. bundler니까 react 같은데서 파워풀하게 쓸 수 있음. CORS 옵션을 true로 해야할 것 같은데 어쩔 수 없이 그렇게 해야함. 도메인이 다르면 어쩔 수 없이 발생하는 이슈. 서버쪽에서도 풀어줘야되고 어쩔 수 없는 부분임. 로그인은 token으로 -> jwt 별도로 sdk에서 dsn 파싱 해서 사용해도 괜찮을 듯 hashing해서 써야함*** 내부적으로 가지고 있 프론트 진행을 빨리 해야할듯 프론트 쪽이 오히려 헬일 수 있음 meterial UI 추천 custom을 세밀하게 할 수 있음 기본적으로 주는 component를 극강으로 custom 할 수 있음. 프론트 작업도 시작해야함!!!!!!!! 웹팩 설정같은거는 봤으면 좋겠음 react는 웹팩 설정에 따라서 파일 사이즈가 차이남 크면 그만큼 느리게 응답이 올꺼니까. 기능이 너무 많아서 module 사용할 때 moment 같은 시간 관련 라이브러리 사용하면 chunk 사이즈가 엄청 커짐. 그런거 어떻게 ignore 할껀지 고민해야할듯. 시간관련된건 locale, moment 쓸텐데 웹팩 설정 merge된거는 삭제하는게 좋음 코드관리는 enum? yaml - 야믈 이라고 발음한다고 한다 요새는 yaml 많이 쓴다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 설정값은 다 yaml 로 하는 추세 / 다른 설정 파일들도 yaml 로 작업한다고 함. -> yaml 로 전부 바꾸면 트렌디해 보일듯.. ㅋ enum 다른 멘토님 - 프로젝