ft_transcendence

Overview

• 웹사이트 백엔드는 NestJS를 사용해야 한다.

• 웹사이트 프론트엔드는 TypeScript 기반 프레임워크를 사용해야 한다.

  → React 채택

  → 조금 고민 필요…

• 어느 라이브러리나 프레임워크든 자유롭게 사용 가능하나 latest stable version을 사용해야 한다.

• DB는 PostgreSQL을 사용해야 한다.

• 웹사이트는 반드시 SPA(Single Page Application)이어야 한다.

  → React는 SPA이다.

  → NextJS, Vue도 마찬가지

• 모든 것은 docker-compose up --build 명령어 한 줄로 launch되어야 한다.

  → 백엔드 서버, 프론트 정적 파일, DB 등 모든걸 전부 컨테이너로 관리해야 할듯

Security Concerns

• 모든 비밀번호는 DB에 hashed된 상태로 저장되어야 한다.

  → bcrypt로 단방향 암호화하면 될듯

• 웹사이트는 SQL injection 공격으로부터 보호되어야 한다.

  → https://it-timehacker.tistory.com/180 TypeORM을 이용하면 방어 가능

• 서버측에서 클라이언트의 요청을 적절히 검증해야 한다.

  → ValidationPipe를 이용하여 타입 검증

  → Guard를 통하여 권한 검증

• 모든 credential한 값들은 전부 .env 파일로 관리되어야 하고 당연히 gitignore처리가 되어야 한다.

User Account

• 유저는 42 OAuth 시스템을 이용하여 로그인해야 한다.

  → Passport 42를 이용하여 OAuth 인증 구현

  → Passport google을 이용하여 2차 인증

  → JWT 토큰을 인증을 하는 경우가 많음

• 유저는 웹사이트에서 보여줄 고유한 이름을 가져야 한다.

  → DB에 unique한 닉네임 필드 필요

• 유저는 아바타를 업로드 할 수 있어야 한다. 유저가 아바타를 등록하지 않았다면 디폴트 값이 설정되어야 한다.

  → 업로드 버튼?

  → 업로드 API → DB 저장

• 유저는 2차 인증을 할 수 있어야 한다. ex) Google OAuth, 휴대폰 인증

  → 전자는 Passport Google을 이용하여 쉽게 가능

  → 구글 OTP 인증 등을 말하는 것 같으므로 더 찾아보기..!

• 유저는 친구 추가 기능을 이용하여 다른 유저를 친구로 등록하고 해당 유저의 현재 상태(online, offline, in a game…)를 볼 수 있어야 한다.

  → 로그인 상태를 알 수 있어야 하므로 토큰 방식이 아닌 세션 방식을 해야한다.

  → User 테이블이랑 친구 관계를 저장할 friend 테이블..?

  → 친구 목록 모달?

• 유저의 프로필에 통계정보를 확인할 수 있어야 한다. ex) 승패 횟수, 승률, 래더, 업적 등등

  → stat 테이블?

• 각각의 유저는 일대일, 래더 매칭 등등 대전 기록을 가져야 한다.

  → stat 테이블? type 일대일 or 다대다

Chat

• 유저는 public, private, protected by a password 채팅방을 만들 수 있어야 한다.

  public → 공개방

  private → 초대 only

  protected by password → 비밀번호 방

  DM → 개인 메시지

  채팅 내용 저장은..?

  → socket.io에서 처리..?

  → 서버에 저장하지 말자!!

  → 클라이언트 브라우저에 임시로 저장하는 방식일듯

  💡web RTC

• 유저는 다른 유저에게 DM을 보낼 수 있어야 한다.

• 유저는 다른 유저를 차단할 수 있어야 한다. 차단한 유저의 메시지는 더이상 보이지 않아야 한다.

  → ban 테이블

• 채팅방을 만든 유저는 자동적으로 방을 떠나기 전까지는 채팅방 소유자 된다.

  → chatroom 테이블

  → 채팅방에 참여하는 userId 저장

  → 채팅방 제목

  → 채팅방의 현재 인원

  → 채팅방의 최대 인원

  → 채팅방 소유자?(방장) → web RTC를 더 공부 필요

• 채팅방 소유자는 채팅방에 들어가기 위한 비밀번호를 설정하거나 변경하거나 삭제할 수 있다

  → 채팅방 비밀번호 필드

• 채팅방 소유자는 채팅방 관리자이다. 다른 유저들을 관리자로 설정할 수 있다.

• 채팅방 관리자는 특정 유저를 특정 시간동안 차단하거나 채금을 줄 수 있다.

• 유저는 채팅 인터페이스에서 다른 유저에게 게임 초대를 보낼 수 있다.

  → 게임 초대장 전송 버튼?

  → 게임 초대장 확인 모달

• 유저는 채팅 인터페이스를 통해 다른 유저의 프로필을 볼 수 있다.

  → 프로필 정보 보는 모달?

Game

• 유저는 다른 유저와 웹사이트를 통해 실시간 Pong 게임을 할 수 있어야 한다.
• 대전 매칭 시스템이 있어야 한다. 유저는 자동적으로 다른 사람과 매칭되기 전까지 대기열에 있을 수 있다.
• 2D, 3D 게임 뭐든지 좋지만 original Pong을 충실히 따라야 한다.
• 이밖의 다른 커스텀 옵션을 제공해야 한다. 그러나 유저가 원한다면 추가 기능 없이 게임의 기본 버전을 선택할 수 있어야 한다.
• The game must be responsive!
• 제 3자가 실시간 관전을 할 수 있어야 한다.