redis 개발 환경 수정 시 질문 입니다.

안녕하세요. 실무에서 rdb를 그렇게 백업하는건 흔한일인데, redis의 경우 어떤데이터가 redis이 쌓이는지에 따라 달라질것 같습니다.보관의 의미가있는 데이터인경우와 보관의 의미가 없는 데이터인지를 따져야할것 같네요.

질문

선수 과정 아니에요~! 물론 들으면 도움은 되시겠지만, 제가 MSA 개괄적인 내용에 대해서 어느정도 상세하게 설명을 하고 갑니다~!

6, 도메인구성 강의에서 ddl-auto: update 부분 질문있습니다.

안녕하세요 update로도 최초 테이블 구성이 됩니다. 다만, 컬럼의 길이나 타입 변경시에 자동반영이 안되기에 개발의 편의상 create모드로 두고, 혼란의 여지를 없애고자 했습니다~!

프론트엔드에서 Auth.js를 사용했을 때, 질문 있습니다.

찾아보니 auth.js는 인가코드를 받기 어려운 구조라고 하네요. 그런데, 현재 저희 수업에서 다루는 2가지 방식 중에 서버에 의존적으로 로그인과정을 진행하는 방식을 사용할거면, 굳이 별도의 라이브러리 자체가 필요 없긴합니다. 그냥 서버에서 지정한 화면만 아래와 같이 라우팅 해주면 됩니다.ex) http://localhost:8080/oauth2/authorization/google그래서 이 방식 또한 next.js에서 사용하는 auth.js의 기능을 살리는 방향은 아닐것 같아요.auth.js를 활용한 방식에 대한 레퍼런스를 더 찾아봐야 하지 않을까 싶습니다. 그와 별개로 제 개인적으로는 auth.js자체를 쓸필요가 없을것 같다는 생각이 듭니다. 저희 수업에서도 어떠한 라이브러리 없이 일반적인 axios를 통한 http요청으로 로그인 처리를 하고 있으니, 프레임워크와 상관없이 동일하게 구현하면 될것 같습니다.

[질문] 소셜 로그인한 적이 없다면 회원가입 시키기

안녕하세요~! 답변이 조금 늦었습니다.제가 고민해보니, 말씀해주신대로 email로 검증하는게 오히려 더 맞을것이란 생각이듭니다.만약 같은 이메일을 쓰더라도 로그인한 플랫폼이 다른 경우엔 다른 사용자처럼 취급할목적으로 socialId로 검증할수도 있겠지만,email에 어차피 unique가 걸었다는것 자체가 같은 이메일에 대해 로그인을 허용하지 않겠다는 뜻이므로, 오히려 socialId로 검증하면 나중에 email insert시에 에러가 발생할 여지도 있기 때문에 애초에 email로 검증을 하는 말씀해주신 방안이 더 나은 방안이 될수도 있을것 같습니다.

토큰 만료시 처리

넵 저희 수업에서는 코드의 간결함때문에 그런 부분들까지는 의도적으로 배제가 됐습니다. main.js와 같은 코드에서 400번대 인증에러가 터지면, refresh토큰으로 accesstoken을 받아오는 코드를 추가해주면 될것 같습니다.

안녕하세요 선생님 채팅방 history를 불러올때 scrollToBottom에 대해 질문 있습니다.

안녕하세요. 코드를 보시면 this.connectWebsocket();이 함수를 호출하고 있고, 이미 이 함수에서 this.scrollToBottom(); 을 호출하고 있어서,하시려고 하는 작업이 불필요해 보입니다.

개발환경세팅에서 npm run serve 명령어 입력 시 오류

npm install 진행하셨죠? 명령어를 사용하는 위치에 package.json폴더가 있는지도 확인부탁드립니다.

섹션 6. '이전메시지조회' 강의에서 질문 있습니다.

1.네 문제 없습니다. 오히려 이미 만들어둔 findByChatRoomAndMember를 활용하는게 더 적절해 보입니다. 제가 메서드를 만들어두고, 놓친부분이라 생각됩니다. 2.getHistory관련하여 참여한 이후의 시간의 message를 가져올거면 말씀하신대로 채팅방참여이후의 시간대를 기준으로 jpa로 filtering해서 history를 출력하면될것 같습니다. participatedTime을 chatParticipant로 등록된 시간을 가져다가 greater than으로 조회를 하면 될것 같습니다. api관련해서는 태우님이 생각하시기에 더 효율적이거나, 개선할점들을 찾아서 편하게 디벨롭 시켜나가도 될것 같아요.

섹션6. '채팅메시지 저장' 강의에서 질문 있습니다

답변이 조금 늦었습니다!!맞아요 ChatRoom객체에서도 participants를 조회해올수 있으니 그렇게 가져오는게 더 간결하겠네요.저는 소스코드 전반에 jpa에 익숙치 않으신분들을 위해 jpa활용을 자제하려고 했었습니다. 말씀하신대로 구현해도 전혀 문제 없을것 같습니다!!