✔️ 결론 및 To Do
[FE]
- 기술스택 근거있게 결정하기
- canvas 사용을 하는 경우에는 tree에 대한 이해를 높일 수 있다. 하지만 디자인 쪽으로 치우쳐질 수 있다. 라이브러리를 쓰는 방법도 있다. 이 주제에 대해서 다시 여쭤보고 논의해보기
[BE]
- 긍정적인 피드백
- 아키텍처 그림이 필요하겠다
- 11/15 20시에 BE 멘토링
공통
- 아이디어가 좋다
- 11/22 20시 30분에 FE, BE 통합 멘토링
✔️ 아젠다 및 질문
멘토링 아젠다와 멘토에게 하고 싶은 질문을 사전에 준비합니다.
프로젝트 기획서
- 📎 Github wiki 링크
- 현재까지의 의사 결정 공유 및 검수
- 백로그 관리 툴: Jira와 Github 프로젝트 중 백로그 공개가 가능한 GitHub 프로젝트를 선택했습니다.
- 사용자가 Git 문제를 풀 수 있는 터미널 환경 제공: 터미널 구현 방법으로 소켓 통신 기반의 라이브러리인 xTerm.js와 직접 구현하는 것을 고민했습니다. 아래 두 가지 이유로 직접 구현하기로 결정했습니다.
- 현재 Git 상태와 사용자에게 보여지는 Git 그래프 시각화(애니메이션) 동기화 문제
- 사용자 입력과 터미널 동작 제어 자유도 제한
- Git Challenge 문제를 직접 출제했습니다.
- 기술적 과제를 한 문장으로 정리
- FE: 터미널 직접 구현 + 캔버스로 Git 그래프 시각화 및 애니메이션 적용
- BE: TBD
- BE
- 문제 풀이 환경 구현을 위해 Docker를 사용할 것인가?
- 문제 상황별로 도커 컨테이너를 올려서 대응하려고 했다.
xTerm.js를 사용하게 되지 않으면서 사용자 입력을 완전히 제어할 수 있게 되었다.
그래서 도커로 격리할 만큼 위험하지 않다. 디렉토리로 해결!
- 대신 백엔드 서버 배포 시에는 도커 사용 고려 중
- DB
- 세션 별로 로그를 관리하는 측면에서 NoSQL이 많이 유리하다.
- Redis로 세션 관리 + MongoDB로 장기 미접속자 + 사용자 입력 기록 관리
- 서버 로그관리는 우선 파일로, DB를 활용하지는 않는다(추후에 db사용 가능).
✔️ 멘토링 내용
[FE]
next.js 를 사용하는데 react query를 도입해야 하는 이유?
: 개인적으로는 추천하지 않아요. react query 메인테이너인 Dominik 도 같은 이야기를 하고 있습니다. https://tkdodo.eu/blog/you-might-not-need-react-query#you-might-not-need-it
✔️ 체크리스트
이번 주 멘토링에서 이야기 나누면 좋을 주제입니다.
우리 팀의 상황은 어떤가요? 멘토님과 이야기 나눈 후 셀프 체크하고, 그 이유를 작성해보세요.
추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.