코드 살펴보던 중에 발견한 것

안녕하세요~! 지금 보니까 일관성 없이 id가 아닌 email로 넣은것 같습니다. 다만, email을 넣든 id를 넣든 refresh토큰에서는 전혀 문제될것 같지 않습니다. refresh토큰의 목적은 rt를 통해 at를 발급하는 것이라, rt안에 사용자를 구분지을수 있는 unique한 값만 있으면 돼서 email과 id 모두가 가능합니다. at는 각 서버에서 token안에 id값을 지속적으로 사용하고 있기 때문에 id를 토큰에 넣었던 것인데, rt도 id를 넣어두는게 더 일관성 있을것 같습니다!!

추가 커스텀 구현 질문 있습니다.

안녕하세요~안 읽은 메시지의 숫자가 실시간으로 변화돼야 한다면, 매우 빈번하게 통신을 해야 하니 채팅을 하는것과 동일하게 웹소켓 connect를 통한 실시간통신을 활용하는게 좋을것 같습니다.

connect와 동시에 구독하는데 구독 검증이 꼭 필요한가요?

안녕하세요. 연결시에 토큰 검증을 하고 있지만, 만약 구독시에 검증을 하지 않으면 참여자로 속해 있지않은 다른 방을 검증없이 구독해버릴수 있어서 다른방의 메시지를 받아볼수 있게 돼 버립니다. 이 부분때문에 구독시에도 검증을 진행했습니다.

Redis Pub/Sub, Stream과 Kafka 비교 질문입니다.

안녕하세요~! 메시지 pub/sub목적으로 kafka를 쓸것인가, redis를 쓸것인가에서 어떤것이 더 일반적이냐를 물으신다면 저는 중립일것 같습니다. 먼저, 실시간상황에서 유저입장에서 속도차이가 없다고 단정지을순 없습니다. 실제로 아주 작은 지연(latency)로도 유저는 속도체감을 할수 있기 때문입니다. 더불어, 만약 2대 이상의 서버가 운영중인데, 2대의 서버가 모두 죽어서 redis로부터 메시지를 전파 받지 못한다고 가정하면 이때에는 redis는 분명 문제가 있습니다. 그런데 어차피 이 상황에서는 서비스 자체가 안되는 상황이기 때문에 사용자는 서비스 불능을 경험하게 될것이라서 안정성 측면에서도 크게 kafka에 비해 불리하다고 보기도 어려울것 같습니다. 결론은 redis, kafka 모두 장단점이 있으므로 어떤것을 우선순위에 둘지에 따라 서비스별로 판단해야 할것 같습니다.

채팅 서비스 관련하여 질문드립니다.

안녕하세요~ 혹시, 말씀하시는 내용이 채팅 또는 알림 등의 실시간 서비스를 구현할때, 웹소켓이나 sse없이 redis pub/sub만으로 가능하냐 를 물어보시는걸까요? 만약 그런 질문이라고 한다면, 그럴수는 없습니다. redis pub/sub은 다중서버 환경에서 메시지를 전파해주는 역할을 하는 것일뿐, 실시간 서비스 자체를 구현하는 기능은 아니기 때문입니다. 그래서 redis pub/sub은 sse 또는 웹소켓과 함께 보조적으로 사용될때 필요한 기술이라고 보시면 될것 같습니다.

궁금한 점

안녕하세요. 질문주신내용중에 첫번째. 일반적으로 git pull origin develop을 수행한후에 충돌이있다면 해결후에 내 브랜치를 머지합니다. 두번째.pull origin develop을 한다면 모든 최신 커밋을 받아오는 것입니다. 감사합니다.

저도 동일한 질문인데

안녕하세요~!! 혹시 펍섭 관련 코드를 한번 보내봐 주실수 있을까요? 테스트 과정도 조금만 더 상세하게 알려주시면 김사하겠습니다.

token이 필요한 엔드포인트에 의도적으로 토큰 누락시 대처

안녕하세요~ 말씀해주신바와같이, 토큰을 누락하고 요청을 보낸경우 filterchain레벨에서 에러가 터져서 컨트롤러까지 이어지지 못합니다. 그래서 아래 AI에서 답변한것과 같이,securityconfig에서 에러 핸들러를 추가 해야 합니다.filterchain에서 발생하는 에러를 catch하여 커스텀할수있도록 코드추가가 필요합니다.

수업자료가 왜 다 나눠져있나요?

안녕하세요~수업자료는 1개 입니다. 그런데, 혹시나 수강생들이 못 받을까봐 강의마다 올려두었습니다.pdf1개만 다운로드 받으셔도 되고, 올려둔 노션 링크로 보셔도 됩니다.

메시지 전송 시 검증

안녕하세요 근영님.일단, 좋은 질문 감사드립니다. 말씀해주신 내용을 고민해보니, send시점에도 사용자가 해당방의 참여자인지를 확인하는게 적절해 보입니다. 안 그러면 해당방에 참여자가 아닌데도 메시지를 발송할수 있을것 같습니다. 물론 메시지를 subscribe는 못하겠지만요. 말씀해주신 내용참고해서 서비스를 develop 시켜주시면 좋을것 같습니다.