CD뽀개기
•
•
프론트에 글 작성 버튼/ 닉네임에 마이페이지 연결 버튼 등 연결
•
API 전체적으로 재점검, 명세서에 정리(Post 부분)
•
맡은 MVP부분 ppt에 정리, 추후도전및 기술적의사결정과 어제 질문 답변도 정리
명마처럼 달리고
•
CD 손봐보고 도저히 안되겠다 싶으면 수동배포로 중간발표 하기로하고 일단 손절
•
CICD 기술적 고민 작성
•
알림 테스트 / 알림프 론트 전체조회
기술적 의사결정
질문 답변 준비
1.
(면접관) 채팅 기능을 구현하셨는데 채팅 기능에 대해 설명해주세요. (채팅 기능을 어떠한 기술을 활용하여 어떻게 구현했고 왜 그러한 선택을 했는지를 답변해주세요. 채팅 기록을 어떻게 처리했는지에 대한 내용도 꼭 추가해주세요.)
keyword: 실시간 알림을 위한 websocket, STOMP, SSE, Redis, MongoDB 등…
⇒ 채팅 기능에 대한 기술적 의사 결정이 명확하지 않아 디테일하게 물어보지 못하고 포괄적으로 질문했습니다.
추후 개발 및 기술적 도전 결정 각자 1개씩 써오기
mvp 작업 정리 각자 맡은 부분
1.
(면접관) RESTful 한 API 설계를 하셨나요? 하셨다면 어떠한 노력을 하셨고 어느 부분이 Restful한 설계라 볼 수 있을까요? (유민아님)
keyword: API naming 규칙, 메소드 활용 등…
답변
2.
(면접관) API는 어떻게 관리하셨나요? 문서화 하셨다면 어떻게 문서화하셨고 API 문서화는 어떠한 장점이 있을까요?(김민선)
답변
keyword: Swagger, ReDoc, Notion 등…
3.
(면접관) 채팅 기능을 구현하셨는데 채팅 기능에 대해 설명해주세요. (박준영)
답변
저녁 7시에 미팅
STOMP는 pub/sub(발행/구독) 패턴으로 동작합니다. 채팅방은 post를 게시하면 해당 post에 하나의 채팅방이 생성됩니다. 그리고 채팅방에 입장하면 해당 채팅방에 구독이 이루어지고, 채팅방에 발행되는 메시지를 수신할 수 있습니다. 채팅은 user의 nickname과 채팅 내용이 담긴채 db에 저장이 됩니다.
데이터베이스는 MongoDB를 선택했습니다. 채팅은 실시간으로 빈번하게 발생하므로 읽기/쓰기 성능이 좋고, 유연한 데이터 모델로 추후 확장성을 고려해서 NoSQL을 선택하고, JSON 형태로 넘어온 데이터를 쉽게 처리할 수 있는 MongoDB를 사용했습니다.`
STOMP는 pub/sub(발행/구독) 패턴으로 동작합니다. 채팅방은 post를 게시하면 해당 post에 하나의 채팅방이 생성됩니다. 그리고 채팅방에 입장하면 해당 채팅방에 구독이 이루어지고, 채팅방에 발행되는 메시지를 수신할 수 있습니다. 채팅은 user의 nickname과 채팅 내용이 담긴채 db에 저장이 됩니다.
데이터베이스는 MongoDB를 선택했습니다. 채팅은 실시간으로 빈번하게 발생하므로 읽기/쓰기 성능이 좋고, 유연한 데이터 모델로 추후 확장성을 고려해서 NoSQL을 선택하고, JSON 형태로 넘어온 데이터를 쉽게 처리할 수 있는 MongoDB를 사용했습니다.
