8/3 빅토리 멘토님 코칭 일지Record Validation 중복 문제문제 분석멘토님 피드백대댓글 관련 이슈문제 분석멘토님 피드백좋아요 api 설계문제 분석답변8/10 빅토리 멘토님 비동기 질문 피드백문제 상황피드백
8/3 빅토리 멘토님 코칭 일지
Record Validation 중복 문제
문제 분석
- 특정 ID를 가진 Domain의 Record가 존재하는지 확인하는 로직이, 서비스 클래스들이 이용하는 Domain들이 겹치기 때문에 중복되는 문제가 발생했다.
멘토님 피드백
- AOP이용
- 해당 Validation 코드들은 Domain이 달라도 동작 방식은 거의 유사하기에 AOP와 Generic 을 이용해서 해결할 수 있을 것이다.
- 중복 감수
- 중복의 사항이 크지 않기 때문에 중복을 감수한다. 현업에서도 이런 중복을 감수하는 경우가 많다.
- 사실 이 문제는 팀 별로 제대로 정해 놓으면 문제가 안되는 계열의 문제이다. 이런 고민을 해 봤단 것 만으로도 도움이 된다고 하신다.
대댓글 관련 이슈
문제 분석
- 우리 서비스는 대댓글을 1단계의 깊이로 작성이 가능하다. (대댓글의 대댓글은 불가능)
- 초기 기획에서는 댓글 페이지네이션 시 부모 댓글과 자식 댓글을 같이 카운트 해서 보내주기로 했다.
- 그럴 경우 두 가지 문제가 생긴다.
- 부모 댓글과 자식 댓글의 경우 view 상 댓글들의 생성 시간이 중구 난방이 될 수 있다. 따라서 이를 정렬하려면 백에서 레코드를 하나하나 찾아가며 따로 처리를 해줘야 할 것이다. → 구현의 난이도 상승 및 성능 저하
- 위에 이어서, 다음 페이지를 불러오기 위한 쿼리에서 어떤 조건을 걸 지 마땅히 생각이 잘 나지 않는다. → 구현의 난이도 급 상승
- View 상 대댓글 부터 시작하는 페이지가 있을 수 있다. 이게 맞는 기획인가? → 프론트 구현의 난이도 상승
- 따라서 프론트와 합의를 봤다.
- 기본적으로 부모 댓글의 갯수만 Count를 해서 페이지네이션을 진행한다.
- 대댓글의 경우 10개 미만은 다 보내주고 10개 이상의 경우 보내주지 않는다.
- 대댓글의 갯수를 따로 보내준다. (childCount)
- view 상에서 10개 이상의 대댓글을 가지고 있는 댓글은 대댓글 대신 더보기 버튼이 존재한다.
- 해당 더보기 버튼을 누를 시 대댓글 조회 API로 요청이 와 해당 댓글의 대댓글을 return 해 준다.
- 두번째 의견이 괜찮은가? 그리고 첫번째 방법을 쉽게 구현할 수는 없을까?
멘토님 피드백
- 두번째 의견이 오히려 더 괜찮다!
- 첫번째의 경우 대댓글부터 노출되는 페이지가 존재한다는게 좋은 UI 같지는 않다.
- 그대로 진행해도 좋을듯
- 첫번째 의견의 경우 배열의 인덱스처럼 씨리얼 넘버 칼럼을 데이터베이스에 추가해서 관리하면 구현할 수 있을듯
- 다만 관리의 추가적인 오버헤드가 든다. 대댓글이 달릴 때마다 전체의 씨리얼 넘버를 관리해 줘야 한다.
- UI상이든 구현 비용, 시간이든 효율성이든 두번째 의견이 더 낫다!
- 나의 평소 생각과 같은 말씀을 해주셨다.
기술상 웬만한 구현은 다 가능하다. 안되는건 없다. 다만 비용과 시간, 효율성의 차이만 있을 뿐이다.
좋아요 api 설계
문제 분석
- 좋아요 on, off API 분리/통합에 대한 고민
- 좋아요 on, off API를 하나로 제공하기로 결정했는데, 괜찮은 설계인지 궁금해서 질문드림
답변
- 괜찮다👍
8/10 빅토리 멘토님 비동기 질문 피드백
문제 상황
멘토님! 질문이 있어 슬랙 남깁니다. 현재 인증 관련 프론트팀과 의견이 갈리는 부분이 있어서 멘토님 의견 여쭙고 싶습니다. 문제상황은
- 로그인 시 access, refresh Token과 유저 정보 전달
- 프론트에서는 access Token을 local storage에 저장 (refreshToken은 어디 저장하는지 못 물어봤습니다.)
- 유저 정보는 전역 상태로 관리
- 새로고침 시 유저 정보가 날라감
- 따라서 프론트팀은 새로고침마다 데이터를 호출하는 API 외에 추가로 accessToken으로 유저 정보를 얻어오는 API를 호출하기를 희망함
- 백엔드팀은 새로고침마다 API 호출이 2번 오는 것이 유저가 많아지면 서버에 부하가 커지는 좋지 못한 구조이지 않을까 염려함
입니다.따라서 저희가 생각한게
- JWT token에도 유저 정보가 있기에 새로고침 시 local storage의 JWT token을 디코딩해서 내부의 유저 정보를 가져옴
- 로그인 시 유저 정보도 localstorage에 저장. 새로고침 시 유저 정보를 local storage에서 가져옴.
입니다. 처음엔 저희 의견이 더 합리적이라 생각했는데, 보안 관련해서 프론트에서 JWT 를 디코딩 하는 것이 안전한지, 유저 정보가 변경가능하다면 localstorage에 있는 정보를 가져오는 것보다 차라리 api를 추가로 호출하는 것이 변화에 더 잘 대응할 수 있는게 아닌지 등에 대한 생각을 하고 나니 어떤게 정답인지 잘 모르겠습니다. 이에 대해서 멘토님 의견은 어떠하신지가 궁금합니다!
덧붙여 말씀드리자면, 유저 정보에는 보안상 민감한 정보가 없다는 가정이 있습니다.
피드백
멘토님 :
상혁님의 의견대로 하는게 맞는거 같습니다.
토큰을 그렇게 쓰려고 하는거니까요! 그리고 토큰에는 패스워드 같은 정보가 들어가지 않으니까 프론트엔드에서 디코딩 해도 됩니다! ㅎㅎㅎ
잘 생각하셨네요!!
박상혁 :
JWT를 디코딩 하는데에 있어서 거부감을 가질 필요가 없다는 말씀이시죠? 답변 감사드립니다.
추가적으로
유저 정보의 수정이 잦다면 새로고침 시 새로 불러오는 방식이 더 나은지,
새로고침 시 API를 추가적으로 호출하게 되는 것이 서버에 과부화를 어느정도 줄 지
에 대해서도 궁금합니다!
멘토님 :
수정이 잦게 일어나는 유저 정보 전체를 토큰에 넣을려고 하시는건가요?
박상혁 :
음 꼭 그런건 아닌데 프론트 쪽에서 나중에 전역적으로 관리할 유저정보가 좀 많이 필요할 수 있다고 말씀을 하셔서, 나중에 어떤 데이터가 들어갈지 확실하지 않아서 여쭤봤습니다.
멘토님 :
전역적으로 관리하면서 리프레쉬 할때도 남아있게 하기 위해서는 여러분이 이미 말씀하신대로, local storage를 이용해달라고 얘기해주세요! 토큰에는 id 값만 들어가는게 일반적이고 보통 프론트에서도 민감한 정보가 아닌것들은 local storage를 활용하는것으로 알고 있습니다.
박상혁 :
넵 좋은 조언 감사합니다 멘토님!