3주차 팀 회고

프로젝트 진행 상황 & 주요 기능

클라이언트

• 홈, 로비, 룸, 룸 설정 UI 작업 및 mock data 작성
• 라우터 설정(protected router)
• TailwindCSS prettier, ESLint 관련 설정
• 로그인 context 설정

서버

• 서버 세팅
• docker compose로 배포 및 docker 변수 .env로 추출
• typeorm 엔티티 생성
• 스웨거 설정
• 프론트 분들과 같이 모의 ERD 생성 및 레퍼런스 프로젝트 참고

협업 중 겪은 어려움 & 해결 방안

• 점점 공유하고 얘기해야 할 내용이 많아지는데 슬랙 채널 1개로는 내용이 계속 섞이고 분류할 수 없고 스크롤링 압박이 심해 멀티 채널을 지원하는 디스코드로 이주함.
• 프론트와 백 협업 → 소켓 API 작성 → 소켓 api 작성 (카페에서 다 같이 케익 시켜놓고 해결)
• 카페 찾는 게 힘듦,,,
• 커피와 케이크를 먹고 혈당이 오르면 적극적으로 긍정적으로 빠르게 회의할 수 있다 (ㄹㅇ 다이어트 포기)

프로젝트 현황 공유 질문 정리

1. 전역 상태 라이브러리를 사용하지 않고 Context API를 선택하신 이유가 궁금합니다.
   1. 굳이 전역 상태 라이브러리를 도입해야하나? 현재 상태관리 라이브러리 들은 context api로 구현되어 있다. 가장 근본되는 기술인 context api를 학습하면 좋지 않을까? 저희 프로젝트는 이정도만 써도 상태관리가 가능할 것 같습니다.
2. loader를 사용했을때 렌더링이 더 빠른가요?
   1. 렌더링 속도랑은 큰 관련이 없는 것 같습니다. 로딩 되는 창을 예쁘게 해서 느리지 않게 보여주는 효과는 있는 것 같습니다.

피드백

1. 플러터의 라우터 방식을 참고해서 리액트에 적용하신게 참신하네요!
   1. 정확히는 플러터의 방식을 리액트에 적용한 것이 아니라 플러터와 리액트의 라우터 방식이 매우 비슷합니다!