201202 team meeting

멘토님과 두근두근 미팅

질문

• 매칭하고 채팅까지 구현~?

  • 넵

• 질문에 대한 대답은 Apollo spec을 살펴봐야함 -> 성능 관련은 일단 보류하고 찾아보고 다시 피드백을 주겠다

  • 부분적으로 보내는게 subscription에 있을것임
  • spec?

발표자료 뭘 사용?

• 노션

다음주에도 이런식으로 발표에주시면 될 것 같습니다.

실시간 기능은 subscription을 사용?

• 넵

배포 어디로?

• 네이버 n cloud

따로 서버가 제공되었는지?

• 크래딧 주셔서 naver n cloud로 배포할 예정입니다.

멘토님이 요구하신 과제(?)

• 네이버 n cloud에다가 금요일 오후까지 서버에 배포
• 구현한 기능들을 살펴볼 수 있도록

다른 팀들 발표

B팀

• subscription으로 구현 하면서 드라이버에게 요청이 계속 올 때 어떻게 대처할지.
  • 큐를 이용해서 저장했다가 보여주도록 (데이터 넘어올 때마다 큐에 넣고 하는 처리를 해야해서 useEffect가 빈번하게 사용)
  • useEffect를 많이 사용하는게 문제가 없는지?

Q: 큐를 왜 사용? (어떤 작업을 하고 싶어서?) - 오더들을 큐에 순차적으로 넣고 대기하다가 하나씩 꺼내서 보내줌 - useEffect를 쓸 수 밖에 없는 작업이고 3개는 많지는 않음 - 이 로직을 다른 곳에서도 쓸 일이 없을 것 같으니 customHook을 만들지 않아도 될 것 같음 - *** useCallback으로 성능 개선할 수 있음 ***

Q: 요청이 너무 추상적 - 사용자 매칭을 위한 요청. 하나의 고객에 대한 요청.

C팀

Q: subscription을 어떻게 해야 다수의 라이더가 매칭 요청을 드라이버에게 문제없이 보낼 수 있는가 고민. (거리를 기반으로)와우 -

Q: 드라이버를 호출하는데 거리기반으로 드라이버를 정렬해서 가장 가까운 드라이버 부터 한명 씩 요청을 보내는 것과, 근처 드라이버에게 모두 요청을 보내는 것 중 어느 것이 더 좋을지? - 팀 결론: 한번에 한 명씩 보내기로 했는데 괜찮을까요? (가장 가까운 드라이버에게 먼저 보내고 반응을 확인 후 그 다음 드라이버에게 보낸다(?)) - redis라는 DB 사용하면 sngle thread라서 동시에 수락하는 일이 없음 - 효율적인것은 전체 보내는 방법 - DB를 사용하면 타이밍 이슈가 날 수 밖에 없음(redis를 사용하면 거의 날 일이 없다) - 몽고디비에서 전처리 단계를 만들어서 상태 체크를 진행한 다음에 update를 하도록 하면 괜찮지 않을까 - *** 전처리 만들던가 디비를 바꾸던가. - *** 상태값 체크해서 수락이 가능한 상태에만 수락하도록 하면 될 것 같음 - 전처리 해도 문제가 날 수도 있을까요? - 날 수 있지만 지금 수준에서는 날 일이 아니다. 이거에 너무 신경쓸 일이 아니다. 대용량 트래픽에서 사용되기 때문에 지금 상황에서는 거의 발생할 일이 없을것임(몽고디비가 싱글 쓰레드 기반이 아니기 때문에) - 지금은 그것까지 고려 안해도 돼요옹~ 하지만 고민 포인트는 좋음. - 시간이 적기 때문에 redis 쓰는것은 추천하지 않음. 다 만들고 나서도 궂이 고려하지 않아도 됨

근데 이 부분은 저희는 해결해서 괜찮은거 같네요 -우리팀 짱- 맞아요!!ㅋㅋㅋ 네엡! 저희는 리스트에 자동으로 업데이트 되서 이런 문제는 발생하지 않을거 같습니다.

Q: 비슷한 위치의 두 명의 라이더가 동시에 요청을 하여

1. publish 마다 드라이버에게 알림창이 뜨면, 먼저 요청을 보낸 라이더의 알림이 늦게 요청을 보낸 라이더의 알림에 덮어진다.
2. 드라이버 측에서 알림창이 떴을 때

• 실제 서비스에서도 그렇게까지 하지 않음
• 큐에 넣되 서버에서 조회에서 매칭이 됬는지 안됬는지 확인해서 가능하면 이후 처리

추천해주시는 해결방법을 저희가 했네요!! :) 역시 우리팀..

진짜 서비스를 만들었다면 너무 좋은 고민이지만 우리가 실제 서비스를 하는것이 아니라 핵심 기능을 구현해서 시현하는 것이 목표이기 때문에 크게 중요하지 않음.

Q: mutation, subscription 사용할 일이 있어서 에러가 많이 발생. 에러를 통합적으로 관리하는 시스템이 있는지? - 지금은 어떻게 하고 있는지? - 에러를 받아서 받은 결과 값에 따라 보이는 컴포넌트가 다르도록 하고 있음 - -> graphql 아니더라도 서버에서 에러가 발생하면 에러 컨벤션을 정하고 클라이언트에 toast로 보내줌.
- 저희는 result, error를 공통으로 보내주기 때문에 서버 쪽에서 error 메세지를 잘 정해서 보내주면 그걸로 toast 띄워주는 것도 괜찮아보이네요 - 저희 이미 되어 있지 않아욥? serverMessage로~? - 네 근데 실질적으로 서버에서 보낸 message를 클라이언트에서 쓰지 않는거 같아서요 ㅋㅋㅋ - 아항 그렇네요ㅋㅋㅋ

멘토님의 총평

실무를 들어가더라도 특정 포인트에 매몰되기 보단 뭐가 중요한지를 잘 판단(핵심 기능 구현이겠죠?)

이런 부분에서 봤을 때 A팀은 방향성을 잘 잡고 진행하고 있는 것 같다!!! 꺄아아아아 >_<

물론 고민 포인트는 좋지만, 핵심 기능 구현을 완료한 후에 그 해결책을 찾아볼 것

에러 관련되서 초반에는 뭐를 딱 정해서 한다기보단 그냥 에러 stacktrace를 보내주는게 낫다(문서화가 잘 되어있지 않기 때문에 에러 객체를 보내주는게 더 에러를 명확하게 파악할 수 있다) -> 실서비스가 아니라고 가정하고 준 피드백이다.

협업을 하면서 이슈 공유를 빠르게 빠르게 하는게 중요!! (혼자 끌어안고 고민하지 말고 적극적으로 말하고 해결할 것)

이슈를 빠르게 공유하고 해결하려는 태도가 가장 중요하다. -> 딱 이슈만 해결하는 사람이 있고, 그 이슈를 통해 더 발전시킬 무언가가 있는지 생각하고 발전시켜나가는 태도가 좋다!

cloneCoding -> nomadcoder