🐱온라인 화상채팅 보드게임, We All Lion

'We All Lion' 은 보드게임 '스파이 폴' 을 모티브로 만든 온라인 화상 채팅 보드게임 플랫폼 입니다.

1. 소개

📝Notion

👉 'We All Lion' 노션 주소

📆기간

• 2022.11.04 ~ 2022.12.16 (6주)

👨‍💻팀원

Position	Name	blog	Github
BE L	김연석	https://tastekim.notion.site/	https://github.com/tastekim
BE	김형석	https://stone1207.tistory.com/	https://github.com/kimhsno1
BE	송민형	https://www.notion.so/Home	https://github.com/Minhyeong-S
BE	최윤진	https://velog.io/@yunjin5450	https://github.com/yunjin5450
FE VL	강승훈	https://velog.io/@deepthink	https://github.com/seunghoonKang
FE	박하은	https://haro-e.tistory.com/	https://github.com/parkharoi
FE	최진영	https://www.notion.so/yoooooooung/	https://github.com/yoooooooung
Design	이주은	https://cloudtraveljournal.tistory.com	Gmail : [email protected]

2. 서비스

👨‍🏫서비스 소개

• 사자들 사이에 숨어든 고양이로 디자인 컨셉을 정해 모든 연령대가 접근하기 쉽게 제작했습니다.
• 최소 4명 부터 최대 8명 까지 쉽고 간단한 게임 규칙으로 즐길 수 있습니다.
• 우리끼리?! 지인들과 즐길 수 있도록 비밀방 설정이 가능합니다.
• 실시간 채팅과 캠으로 유저들과 소통하며 온라인으로 지금 당장 게임을 즐겨보세요!

👉 We All Lion 바로가기

📰페이지 소개

게임설명 & 로그인 페이지	로비 페이지

유저 프로필 변경	방 만들기

방 입장 & 대기 페이지	게임시작 페이지

게임투표 페이지	게임종료 페이지

🔍기능소개

게임설명 & 로그인 페이지

• 카카오 소셜로그인 회원가입
• 게임 설명 모달

로비 페이지

• 방 목록 (방 정보 실시간 확인 가능 : 인원, 모드, 방 상태 등)
• 방 만들기 버튼 (공개 & 비공개 / EASY & HARD)
• 로비 전체 채팅

유저 프로필 변경

• 이미지, 유저이름, 게임 승률
• 유저 이름 수정

방 만들기

• 방 만들기 버튼 (공개 & 비공개 / EASY & HARD)

방 입장 & 대기 페이지

• 방 정보 (모드, 인원 등)
• 게임 준비/ 게임 시작
• 방 전체 채팅
• 마이크, 카메라 기능

게임시작 페이지

• 각자 역할 카드 분배 / 제시어 카테고리 & 단어 모달
• 사전 투표 기능

게임투표 페이지

• 스파이 투표하기
• 스파이 정답 제시어 선택

게임종료 페이지

• 스파이 밝히기
• 재시작 및 나가기

3. 구조

🤹‍♂️서비스 아키텍처

📊ERD

ERD

📈프로젝트 구성

프로젝트 구성

├── Dockerfile
├── nodemon.json
├── package-lock.json
├── package.json
├── server.js
├── src
│   ├── app.js
│   ├── chat
│   │   └── chat-socket.js
│   ├── game
│   │   ├── game-provider.js
│   │   ├── game-repo.js
│   │   └── game-socket.js
│   ├── middlewares
│   │   ├── auth-middleware.js
│   │   ├── exception.js
│   │   ├── passport
│   │   │   ├── index.js
│   │   │   └── kakao-stratege.js
│   │   ├── socket-auth-middleware.js
│   │   ├── test.js
│   │   ├── user-error-handler.js
│   │   └── wrap-async-controller.js
│   ├── redis.js
│   ├── rooms
│   │   ├── room-provider.js
│   │   ├── room-repo.js
│   │   └── room-socket.js
│   ├── schemas
│   │   ├── game.js
│   │   ├── index.js
│   │   ├── room.js
│   │   └── user.js
│   ├── socket.js
│   ├── users
│   │   ├── user-controller.js
│   │   ├── user-repo.js
│   │   ├── user-route.js
│   │   ├── user-service.js
│   │   └── util
│   │       ├── jwt.js
│   │       └── user-function.js
│   └── webRTC
│       └── webRTC.js
├── test
│   ├── mockData
│   │   └── user-data.js
│   └── user-test
│       ├── jwt.spec.js
│       ├── user-controller.spec.js
│       ├── user-function.spec.js
│       ├── user-repo.spec.js
│       └── user-service.spec.js
└── 제목 없는 다이어그램.drawio

🛠사용한 기술

• BackEnd

  
  

• FrontEnd

  
  

⁉기술적 의사 결정

• BE

  1. Nginx

  
  

  　사용이유

  • event-driven의 비동기 구조이므로 채팅 기능이나 RTC기능을 사용 할 때, 동시 접속자 수가 증가를 대비하여 적합한 방식의 웹 서버라고 생각했습니다. 또한 NginX는 이벤트 처리 방식, 비동기식 처리, 논블로킹 방식 처리를 통해 고속으로 처리하는 특징이 있어 사용하게 되었습니다.
  • 동시 접속자 수가 많아져도 Apache에 비해 메모리 사용률이 낮고, 처리하는 초 당 요청 수가 앞도적으로 높은 모습을 보여줍니다.
  • 메모리를 좀 더 효율적으로 운영할 수 있는 결과를 갖고 오기 때문에 사용하게 되었습니다.
  • reverse proxy로 서버 확장에 용이하고 보안적으로 뛰어나기 때문에 사용했습니다.
  2. Socket.io

  
  

  　사용이유

  • 통상적으로 사용자(서버에 연결된 소켓들)을 세밀하게 관리해야하는 서비스에는 socket.io에 있는 브로드캐스팅을 사용하는게 더 효율적이라고 합니다.
  • socket을 이용해서 게임 로직과 같은 복잡한 구조를 갖고 socekt이라는 객체를 활용해서 서비스 내에서 활용하는 부분들을 생각하면 socekt.io가 더 적합하다고 판단했습니다.
  3. Redis

  
  

  　사용이유

  • 각 게임에 대해 투표 결과 집계나 준비 상태 등 DB에 저장할 필요는 없다고 생각했습니다.
  • I/O에 빈번한 간단한 액션들에 대해 가볍게 저장해 둘 DB에 memcached랑 redis 가 후보였습니다. memcached보다 redis가 cloud서비스로 제공이 초기 세팅하기에 더 빨라서 선택하게 됐습니다.
  • 간단한 데이터 타입들과 key, value 형식으로 저장할 수 있는 메모리를 사용하는 DB라서 I/O을 다루기에는 redis가 적합하다고 생각했습니다.
  • redis를 선택할 때 local과 cloud 두가지 옵션이 있었는데 협업하면서 사용하기에는 아무래도 local보단 cloud가 더 효율적일 것 같다는 생각이 들었습니다.
  4. JWT

  
  

  　사용이유

  • 카카오에서 발급받은 accessToken을 그대로 사용해도 되지만 카카오의 accessToken 의 유효시간이 11시간으로 굉장히 긴 편이라고 생각했습니다.
  • 직접 accessToken을 발급하고 유효시간을 줄여 보안을 조금 더 강화하고자 생각했습니다.
  • 세션 방식과 다르게 별도의 인증 저장소가 필요하지 않아 서버와의 커뮤니케이션을 최소한으로 할 수 있어 트래픽에 대한 부담이 적다고 생각이 들었습니다.
  5. MongoDB

  
  

  　사용이유

  • 프로젝트에서 DB에 저장하는 대상은 유저(전적, 개인정보) / 룸 / 게임 이렇게 세 가지 테이블(콜렉션) 밖에 필요하지 않고, 데이터의 집합 간의 종속성이 많지 않다고 생각했습니다.
  • 게임 내에서 실시간으로 변하는 정보나 방 상태의 변화의 경우 일시적인 정보는 Redis를 통해서 저장하기도 하지만, Redis로 모든 정보를 전부 처리할 수는 없기에 DB를 사용해야 하는 경우가 있고, 또 굉장히 자주 DB의 정보를 가져오거나 업데이트해야 하는 상황이 발생한다고 생각이 들었습니다.
  • 다른 데이터 집합을 연결시켜서 가져와야 하는 경우가 없다시피하기에 처리 속도가 빠른 NoSQL이 우리의 프로젝트와 더 적합하다고 판단했습니다.
  • 소켓을 통해 실시간으로 많은 정보가 생성, 변경되는 서비스이기 때문에 데이터를 빨리 읽어올 수 있으며 수직 및 수평 확장이 가능하다고 생각이 들었습니다.
  6. Prettier / ESLint / Babel

  
  

  　사용이유

  • prettier 깔끔한 코드와 협업을 위해서 일관성 있는 코드 스타일을 제공해준다 생각하여 사용했습니다.
  • eslint 다양한 방식으로 구현할 수 있는 코드 방식을 일관성 있게 구현할 수 있도록 해준다 생각하여 사용했습니다.
  • babel Babel을 이용하면 ES6 이상의 최신 문법으로 작성한 자바스크립트 코드를 ES5 이하의 예전 문법으로 작성한 것 처럼 소스 코드 내의 문법의 형태를 변경해주어 다양한 실행환경에서 작동할 수 있게 해준다 생각하여 사용했습니다.

　　👉 기술적 의사 결정

⚽트러블슈팅

• BE

　　👉 카카오소셜 로그인 : 프론트로 데이터 전달 불가

　　👉 socket.js 기능별 분리 중 연결 에러

　　👉 특정 룸으로 채팅메세지 전달 불가 (Socket.io)

　　👉 docker image로 서버 실행 시 'Javascript heap out of memory' 현상

　　👉 docker에서 openvidu 서버를 활용한 SFU 방식 테스트 진행 내용

4. 기타

💻GitHub

• BackEnd: WeAllLion-BE

• FrontEnd: WeAllLion-FE