-
Notifications
You must be signed in to change notification settings - Fork 8
회의록_19.11.08
Einere edited this page Nov 8, 2019
·
4 revisions
- 시간 : 19.11.08
- 장소 : 패스트파이브 강남 4호점 8층
- primary-secondary 구조로 구현 시 마스터님이 primary 서버에 트래픽이 몰려 로드밸런싱한 게 효과가 없을 것이라 말씀하심.
- 근데 특정 경우에만 primary 서버에 접근하면 해결할 수 있다고 생각함.
- 하지만 서버에만 치중하면 개발 속도가 너무 느려질꺼라 생각해서 처음에는 서버 한대만 고려하고, 추가적으로 로직을 더할 수 있는 방법을 찾아봄.
- 최종 아이디어
- auto scaling / load balancing을 사용
- 처음에는 하나의 primary server, 하나의 secondary server만 존재하는 것으로 구현
- secondary server가 다 차면 그 때 auto scaling해서 하나의 서버를 더 만듦
- 두개의 secondary server가 생기고, 하나의 secondary server가 이미 꽉 차있으니 남은 하나의 서버로 사용자를 접속시킴
- 두개의 서버가 다 차면 세번째 서버가 auto scaling으로 만들어짐
- 반복....
- secondary server 여러대에 유저가 나뉘어있으면 그 때 primary server에 접근해서 교류
- yoga는 라우팅이 불편하다. 파일분리가 안됨.
- apollo랑 yoga를 쓰지말자
- graphql만
- snapshot은 object storage로
- primary서버에 message Q(rabbitmq, kafka) 등을 사용하면 완전 동시성을 보장 할 수는 없다
- 하지만 캐치마인드는 완벽에 가까운 동시성이 필요없기 때문에 primary-secondary 구조로 가능할 것
- 시도해봐도 좋다
- 하지만 1000명도 서버성능에 따라 한 서버안에 다 담길 수 있음
- 테스트는 알아서
- 영훈님조에서 소켓써서 isOnline
- 기표님조에서 알림인가, 메세지인가..서비스워커나 웹소켓 사용하신다고하시고, 마지막으로 읽은 날짜를 저장해서 그 전꺼를 다 읽음처리 해준다고 하심
- 기원님조도 단어들 크롤링해올듯
- 캔버스 : paper.js
- 테스트 :
- 단위 테스트 : jest (react에 잘맞는다)
- 통합 테스트 :
- 시스템 테스트 :
- 의존성 관리 : npm
모든파일은 .js 파일
-
back
- bin/
- config/
- db/
- graphql/
- resolvers/
- type-defs/
- schema.js
- middleware/
- router/
- test/
- .env
- app.js
-
front
- public/
- src/
- components/
- pages/
- queries/
- themes/
- logics/
- test/
- components/
- 프론트는 모두 확장자를
js로 통일 - 컴포넌트의 경우,
index.js대신컴포넌트명.js로 - 컴포넌트 폴더의 경우, 컴포넌트 명과 동일하게 (첫 글자는 대문자, camel case)
- 컴포넌트를 제외한 폴더의 경우 모든 파일 시작은 소문자로
A. 개인정보를 최소화하고싶다. Oauth정보, 게임기록만 보관 예정
A. 다시 로그인하면 됨
A. 웹소켓을 이용
A. ㅇㅇ 창띄워논사람. 게임 같이 할 수 있는 사람.
A. 중간에 난입됨
A. 인원수만큼(100명) / ㅇㅇ 움짤 조회해야하니까 넣을거임
A. 구상중. 아마 접속순이지 않을까
A. 소켓 방에 추가시켜주면 됨
테스트, 성능개선은 너무 앞서나간 것 같다. (하다가 느려지면 고민해라)
다른 팀과 협업하자.
코드품질, 클린코딩, 리팩토링을 고민하고 잘 풀어나가라.
기능이 너무 많다. 우선순위를 정해서 개발할 기능 순위들을 정해라. 회고를 통해 개발 시간 및 역량을 스스로 측정해봐라.
발표는 상대방이 듣고 싶은 말들을 하자. (청자들의 관심을 이끌만한 내용을 말하자)
발표 시간을 준수하고, 연습해라.