22.11.16. Week2 멘토링

🗣️질문 사항 요약

1. 조정한 피쳐 볼륨에 대한 질문
2. 레디스
3. 리액트 쿼리
4. 소켓

💬멘토링 내용 정리

1. 피쳐 볼륨 축소에 대한 피드백

현재는 잘 줄이고 있다. 이전에 기간에 따른 티어 시스템은 유저가 장기적으로 남아있어야 유의미한 지표를 보여줄 수 있는 반면, 변경된 3대 운동 중량에 따라 티어를 나누는 것은 유저의 수가 적어도, 그리고 장기간 이용하지 않더라도 즉각적인 요소를 줄 수 있어 이전보다 나은 기획이다.

• 체급에 따라 같은 중량을 들더라도 티어가 달라지는데, 이럴 때 체급을 바꿀까..? 하는 유저가 생길 수도 있어서 내 무게가 어떤 체급에선 어떤 티어인지를 보여주는 것도 있으면 좋을 것 같다.

2. 레디스

질문 요약: db의 부담을 줄이고자 레디스를 도입하는 것에 어떻게 생각하시는지.

레디스로 하고자 하는 것은 DB로도 충분할 수 있다. 레디스를 고민하기에는 아직 이르다. 현재 고민하고 있는 부분이 DB에 대한 부담인데, 사실 DB의 성능을 올리는 것이 가장 쉬운 방법이다. 그렇기 때문에 지금 단계에서 레디스에 대한 고민은 너무 이르며, 실제 써보고 나아가는 것이 좋다. 레디스를 붙이는 것 보다 나은게 4코어 DB를 쓰는 것인데, 이를 직접해보고 필요시 레디스로 전환하는 방식이 더 좋을 것 같다.

물론, 레디스의 장점으로 더 저렴하고 빠르다는 점이 있다. 선택은 자유지만 mysql로 먼저 구현을 해보고, 레디스를 사용하는 것이 더 와닿을 것 같다.

3.리액트쿼리

질문 요약: 리액트쿼리의 기능에 클라이언트가 정보를 가지고 있는 캐싱의 기능이 있는데 이를 활용하는 것은 어떤지.

안써보긴 하셨는데, 캐싱과 같은 기능이 리액트 쿼리의 메인 용도는 아닌 것 같다.

DB 정보를 로컬에 저장하기 위해 싱글페이지로 구현을 한다면, 전역변수를 활용해서 쓸 수도 있다. 전역변수화 시켜서 전역 객체로 만들어서 라우터를 오고 가더라도 다 쓸 수 있게 만들거나, 스토어에 담거나 로컬 스토리지를 사용할 수도 있을 것 같고 새로운 페이지로 넘어갈 때 세션류의 정보를 활용해서 가져오는 방법 등을 사용할 것 같다.

Q. 추가질문 : 프론트에서 db에 요청해서 프론트가 받으면 저장이 가능한데, 예를 들어 알림 서비스에서 알림을 받으면 db에 영향이 가고 이 영향을 프론트에서 감시가 가능한가? A. 소켓이나 sse를 활용해도 되는데, 소켓으로 충분히 가능할 것 같다.

Q. +추가질문 : 소켓은 TCP로 알고 있는데 브로드캐스트 되나요? A. 소켓에 브로트캐스트 기능이 있습니다!

4.소켓

질문요약 : 소켓 - 컴포넌트 마운트

소켓은 커넥트, 디스커넥트 비용이 가장 비싸기 때문에 이를 유의하여 관리를 해야한다. SPA라면 처음 연결시 소켓을 연결하고 계속해서 연결된 소켓을 재사용하는 것이 좋을 것이다. SPA의 화면 이동은 사실 눈속임과 같기 때문에 소켓 객체를 잘들고 다니면 된다.

새창을 켜는 경우는 소켓을 다시 고치는 경우가 있는데, 새창에 소켓을 옮기는 데이터 통신을 고려해보도록하자. 새창에서 소켓을 옮기면 커넥트 디스커넥트 비용이 줄어든다. 크롬의 경우는 post message로 가능하다.

소켓이 갑자기 리커넥트나 디스커넥트 될 때 발생하는데, 이 때 누락되는 이벤트를 어떻게 다시 전달할 수 있는지를 고려하는 것이 더 중요할 것이다.

Q. 소켓을 사용하는게 알림인데, 소켓을 사용하지 않는 페이지에서 연결 해두는게 비용이 클지 아니면 소켓이 필요한 알림창에만 연결할 때 커넥트하는 것이 비용이클지 A. 소켓은 커넥트 디스커넥트 비용이 가장 크기 때문에, 계속해서 띄워둘 것같다. 알림 개수는 계속해서 바뀌는데 이건 소켓으로 처리하면 돼서계속 연결할것 같고 소켓을 연결한다면 유기적으로 소켓을 계속해서 쓰는 방법을 연구하면 좋을 것 같다.

결론

레디스를 당장 사용하는 것보다 mysql을 적용을 해보고 필요에 따라 추후에 도입한 후 A B테스트를 하는 것이 좋을 것 같다. 디렉토리구조, 설계를 잘하고 연구하는 것도 좋지만 실제로 하는 것은 다르고 정석이 있다기 보다는 각 팀마다 다르기 때문에 먼저 해보는 것이 좋다. 성능 연구는 후일에 도모해도 늦지 않다. 팀에 맞게 구현, 안정성, 성능에 대한 우선순위를 해보자 빨리빨리 구현하고 여유가 생기면 연구를 해보자.