피드백

• usecase에 어떻게 구현할지에 대한 내용이 부족
• mysql에 저장해도 충분, 카카오톡 처럼 많은 사람들이 쓰는게 아니면 mysql에 저장해도 충분
  • 사용자가 많아지면 nosql 사용 → mongoDB, 카산드라 등 어떤걸 써야할지에 대해서는 usecase가 어떻게 나오느냐에 따라 좀 달라짐
  • 장단점에 대해서만 알고있으면 되고 지금 단계에서는 mysql에 저장해도 됨.
• 채팅 보내기 POST → 서버에 저장
• 그 다른 사용자가 채팅을 받았다 라는 걸 알아야 하는데 이 부분에 대해서는 고민을 해봤는가?
  • 채팅방 조회로 될 것 이라고 생각했다
    1. 상대방이 계속 API로 조회를 하는 방법 나한테 온 채팅이 있나 없나/ GET API 요청 1초마다 → 가장 단순
       1. http polling 이라고 함. 계속 조회를 하니까 서버에 부하가 간다.
    2. 웹 소켓을 이용해서 push 알림을 받는 것처럼 만약 메시지를 보냈으면 메시지를 보내자마자 서버에서 알아차리고 상대에게 push 알림 같은 걸 보내는 것. → 보편적인 방법
• API 명세는 죄다 HTTP 프로토콜 이용하는 건데 장단점이 있다.
  • 서버와 유저가 계속해서 연결을 안 하는 방식이다.
  • 요청을 하지 않아도 연결을 해두면 서버에도 부담이 간다.
  • 그래서 연결을 끊어놓고 필요할 때만 요청
  • 웹 소켓은 계속 연결을 해놔야 해서, 사용자가 늘어나면 부하가 늘어남.
• 구현 방식은 채팅에 대해 많이 나와있으니까 검색해서 어떻게 해야할지 이해를 좀 해보는 게 좋을 것 같다
• 코드 구현보다 개념을 명확하게 알고 가는게 좋을 것이다. 개념에 대해서 이해하는게 굉장히 중요하다. 검색 많이 하면서 이해하는게 중요할 것 같다.
• 프론트에 많은 시간을 쏟지 않는 것이 좋을 것 같다
  • 시연만 가능할 정도로만 구현할 것
  • 구현을 한 번 해봐야 어떻게 돌아가는지 전체적인 흐름의 이해가 쉬울 것이다.
  • 대신 화면을 최대한 간단하게 하는게 시간 확보가 좋을 것이다.
  • 지금 와이어프레임 정도도 좋고 타임리프로 구현하는 강의자료
  • API 요청 부분, 응답 받아와서 보여주는 부분도 세명이서 같이 하는게 어플리케이션 흐름을 이해하는데 확실히 좋을 것이다.
• 1:1 채팅 먼저 해두고 단체 채팅방 하는 걸로!
  • 이런 구조로 가면 나중에 단톡방 할 때 문제가 있을 것 같아 보이면 말씀을 주신다고 하심
  • 1:1 채팅만 해도 고려할 사항이 많다.
    • rdb에 저장, nosql에 저장 → 5번 질문
      • 우선은 mysql에 구현하고 nosql 면접 때 나올 수 있는 질문들 정리해주신다고 하심
      • nosql까지 구현 안 해도 되는데, 왜 이걸 썼는지 장단점에 대해서는 명확하게 알아야 면접 때 답변할 수 있음.
      • 내가 이런거 까지 생각할 수 있는 녀석이다! 를 보여줘야 함.
      • 중간 발표 지나고 나서 다시 고려해보는 걸로 하자!
    • 웹소켓, http polling → 6번 질문
      • 기술 회의로 문서화 어떤 논의를 거쳐서 이걸 쓰게 됐는지 정리해라.
      • 논의를 실제로 하고, 정리하는 과정에서 면접에서 어떻게 말할지 논리가 정리되기 때문에 직접 해보는 게 좋을 것 같다고 하심.
    • 다른 사람이 한 부분에 대해서도 확실하게 알고 답변할 수 있어야 한다.
      • 이 프로젝트로 면접을 볼 거니까, 이런 기술 회의를 통해서 서로 어떻게 구현할지에 대해서 문서로 정리해두는게 좋다.
      • 면접을 2-3달 뒤에 볼텐데 내가 구현한게 아니면 까먹을 수 있어서 정리해두고, 그 과정에서 공부가 많이 될 것이다.
      • 단톡방에 이렇게 정리했다~ 고 남기면 노션 댓글로 피드백 남겨주신다고 함
    • 7번 : 일반적인 채팅 구현 방식은 무엇인지 → 6번 연장선상
      • 구글에 검색해보면 채팅 구현 어떻게 하는지 자료가 많고, 사실 거기서 거기지만 다른 서비스들은 어떻게 구현하는지, 카카오 라이브 채팅 구현기 이런 글 많으니까 어느정도 어떻게 구현하는지에 대한 감을 잡았으면 좋겠다.
      • 본인들의 학습을 위해서 이것도 정리해라.
    • 8번 : 장단점 분석해서 선택하게 된 계기, 원인 적으면 됨
      • ex) nosql보다 rdb 보다 성능이 훨씬 좋은데, 그런데도 RDB를 선택하는 경우가 있다.
        • nosql은 비용이 비싸다.
    • 14번 : 레디스, 글로벌 캐시 / spring 제공 로컬 캐싱
• 도커에 대해서는 지금 단계에서는 생각하지 않아도 되고, 알면 좋은데 배포하는 단계에서 쓰는 건데, 너무 방대한걸 생각하면 머리가 아픔.
  • 지금 해야할 것을 못할 수도 있음.
  • 어느정도 구현이 완료 되면 가이드를 주신다고 함.

채팅을 어떻게 구현할지,

어떤 기술을 쓸건지만 정해라!

배포는 처음 해보면 엄청 어려운데 차근차근히 정리된 블로그가 엄청 많아서 그거 따라해보면 오히려 쉽다. 쉬운 길을 알려주신다.

도커나 배포에 대해서 엄청 잘 알 것이다 라고 생각하진 않는데, 잘 하면 좋다.

기본부터 잘 하고 나서 더 잘하면 훨씬 좋다.

• 프로젝트를 할 때 선배포 하는 이유?
  • 배포 과정을 해보고 싶어서?
  • 선배포를 하긴 해야함
    • 중간 발표도 있으니까