22.11.08.

오늘 논의한 것

권한과 역할은 어떻게 할까?

역할이란 무엇인가

역할은 권한의 집합이다.

커스텀 역할을 도입할까?

도입한다면

1. 채널마다 역할을 만들 수 있게 할까? → 채널마다 하는 건 굳이 그럴 이유가 있을까. 내가 A, B, C 채널에서 개발자 역할이고 싶은데 그러면 채널마다 개발자 역할로 해줘야함.
2. 커뮤니티마다 역할을 만들 수 있게 할까?

결론

- 커스텀 역할 현재 단계에서는 어려운 거 같다.
	- 어떻게 채널마다 역할을 저장해줄 것인지 어렵다.
- 따라서 역할은 커뮤니티/채널을 생성한 `관리자`와 커뮤니티/채널에 참여한 `사용자`로 나눈다.

→ 앞으로의 과제는 관리자와 사용자라는 역할이 어떤 권한의 집합인지 정의하는 것이다.

사용자 앱 접속 시 어떤 화면을 보여줄 것인가?

• 디폴트 커뮤니티 / 디폴트 채널의 의미
  • 마지막으로 접속한 커뮤니티/채널
  • 이름에 의해 정렬했을 때 첫번째 커뮤니티/채널
  • 사용자가 설정한 커뮤니티/채널

결론

- 애플리케이션 접속 시 디폴트 커뮤니티를 보여줄까? → DM 목록 보여주기로 한다.
- 커뮤니티 접속시 디폴트 채널 보여줄까? → 그러자.

• 디폴트 커뮤니티는 없고, 로그인시 DM 화면 렌더링
• 이후 커뮤니티 선택 가능.
  • UX 고려사항
    • 마지막으로 접속한 채널 화면을 보여줌 (DB에 저장하기)

안 읽은 채팅은 어떻게 할까?

안 읽었다는 걸 표시해주는 게 UX에서 좋다.

어떻게 구현할것인지

• 채널별로 타임스탬프 기록
  • 채널 입장시
  • 채널 퇴장시 (다른 채널로 이동 or 다른 커뮤니티로 이동)
  • 어플리케이션 종료시
• 타임스탬프랑 채팅의 createAt이랑 비교하기 (타임스탬프 이후의 채팅 개수를 렌더링)

기능 정의

• 채널별로 안 읽은 채팅 개수 보여주기 (max값 정하기)
• 커뮤니티별로 안 읽은 채팅이 있다면 N표시만

상태 관리 라이브러리는 어떤 걸 쓸까?

• 클라이언트 상태 관리 도구: Redux, Zustand, Recoil, Jotai 등등… 뭘 쓸까?
• 서버 상태 관리 도구: @tanstack/react-query, SWR

결론

• 클라이언트 상태 관리: Zustand
  • 선택 이유(민종)
    • Reducer 정의하는 코드 블럭이 너무 큼. (대신 데브 툴이 잘 되어있음.)
    • 서로 영향을 주는 상태를 응집시켜서 store에서 관리하고자 함. (중앙 저장소)
    • 리덕스는 useReducer + Context API를 이용한 상태 관리와 문법이 유사함. 그래서 store로 관리하는 컨셉의 새로운 라이브러리를 선택하고 싶었음.
    • Zustand는 리덕스와 비슷한 패턴으로 리듀서 역할을 하는 Setter를 정의할 수 있는데, 간략해서 러닝커브가 더 낮을것이라고 생각했음.
    • Zustand 데브툴도 지원한다고 함.
  • 선택 이유(준영)
    • useReducer hook을 좋아하지 않았음.
      • action type-magic string의 관리가 어렵다. 따로 정의하고 다른 파일로 분리해야한다.
      • typescript 작성시 reducer에 대한 type 정의(action type이나 payload 등) 귀찮음
    • redux 도입을 고민했으나, zustand에 대해 조사해보고 사용하기 쉬워보여서 도입하는데 동의함.
      • store이지만 코드가 redux reducer에 비해 상당히 짧고 읽기 쉬움
      • get, set 메서드로 state를 조작할 수 있는 메서드를 정의하는게 recoil을 경험해본 입장에서는 이해하기 쉬웠음
• 서버 상태 관리: @tanstack/react-query
  • 사용 이유
    • 서버 상태 / 클라이언트 상태를 분리하는 컨셉
    • 비동기 데이터의 상태 관리를 위임.
    • 다양한 API 지원

DB 설계-커뮤니티 내 채널의 public 상태를 어떻게 성능 좋게 가져올 수 있을까?

[DB 설계](https://www.notion.so/DB-790e3113e3b84e699131418d315de4b2)

모노 레포는 왜 도입해야할까?

- 클라이언트와 서버가 공유해야하는 소스가 있다.
    - 타입 정의들
    - eslint, prettier 등
		- 혹은 공유할 수 있는 라이브러리들

어떤 도구를 선택할까? 아니면 도구를 쓰지 말까?

1. 사실상 멀티 레포처럼 해야할까?
2. 아니면 yarn workspace, npm workspace 같은 도구를 사용할까?

Git-flow 관련

1. main(배포 브랜치)에서 파생된 dev
2. dev에서 파생된 dev-fe와 dev-be
3. dev-fe나 dev-be에서 파생된 feature

merge 종류 뭐로 할까?

1. dev에서 main으로 머지할 때는 : merge commit 남는 merge
2. dev-fe나 dev-be에서 dev로 머지할 때는: merge commit 남는 merge
3. feature에서 dev-fe나 dev-be로 머지할 때는 rebase (혹은 커밋 너무 많아서 하나로 합치려면 squash)