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 시켜주시면 좋을것 같습니다.

JWT 생성 시 subject 설정에 대한 질문

안녕하세요~! 말씀해주신것처럼 저희 수업의 코드는 claims를 만들어서 세팅해주고 있습니다. 그런데, 가은님이 올려주신 코드처럼 claims 대신 setSubject를 따로 세팅해도 됩니다. 다만, 이 경우 role등 추가 커스텀 값을 세팅할때에는 .claim("role", role) 이런식으로 세팅해야할것으로 보여집니다. 그런데, 결국 추후에 token을 파싱해서 payload를 추출할때에 claim을 추출해야 합니다. 그래서 코드의 가독성을 높히기 위해서 token생성과 파싱 부분을 claims를 사용해서 세팅했다고 보시면 될것 같습니다. token parsing관련 코드는 아래와 같습니다. Claims claims = Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(token) .getBody();

깃허브 main 브랜치에서 dev 브랜치 분기

dev브랜치를 기준으로 하위 브랜치를 만드는 상황일까요? ui를 보면 source가 main으로 잡혀있는데 이를 dev로 두고 브랜치를 만드시면 됩니다!!