Dev_Henry

이제까지 프로젝트를 하면서 값을 주고 받을 때 다양한 방법으로 객체와 데이터를 매핑시켰다. 그런데 구체적으로 어떻게 매핑이 되는지 이해하지 못한 상태로 사용하다보니 종종 에러가 발생하는 경우가 있었기 때문에, 이에 대해서 공부해보려 한다. 우선 objectMapper와 modelMapper를 알아본 뒤에 아래에서 간단한 테스트도 진행해 보겠다. 우선 객체 데이터를 json으로 주고받을때 많이 사용하는 objectMapper. @RequestBody는 내부적으로 objectMapper를 사용한다. 스프링 부트에서는 기본적으로 jackson이 내장되어있고, 여기에 objectMapper클래스가 있다. 직렬화를 할때는 getter를 통해 필드 값을 알아내고 값을 내보낸다. 즉 getter가 필요하다. (맴버변..

spring을 이용한 캡스톤 프로젝트 진행 중 요구사항 중 채팅 기능이 있었다. 이를 구현하기 위해 spring에서 webSocket과 stomp를 사용해 구현했다. 이때 기본 내장 브로커는 안정성, 확장성 측면에서 단점이 많아 외부 브로커를 도입했다. (장애 발생시 메시지 유실, 수용가능한 세션 크기 제한, 모니터링이 어려움, 서버 분리,확장이 안됨) 찾아보니 많이 사용하는 것들이 아래의 3개이기 때문에 각각의 특징을 알아보려고 한다. 우선 아래의 세가지 모두 비동기 메시지를 사용하는 서비스들 사이에서 데이터 송수신을 의미하는 MOM(메시지 지향 미들웨어)를 구현한 메시지큐이다. 메시지 큐의 특징으로는 큐를 사용한 비동기 처리 어플리케이션과의 분리 실패에도 전체에 영향을 주지 않음 여러 프로세스가 큐에..

진행중인 프로젝트에서 처음 구현할때 refreshToken도 만들긴 했는데 급하게 만들다 보니 redis 같은 db를 사용한 검증방식도 없었고 어차피 jwt관련 코드가 모두 리팩토링이 필요했기 때문에 refreshToken 부분도 새로 구현하면서 알아보려고 한다. 우선 refreshToken(이하 rtk)은 JWT방식의 단점을 어느정도 보완하고자 생긴 방법인데, accessToken(이하 atk)을 탈취당하면 해커가 계정을 자유롭게 사용할 수 있기 떄문에 atk의 만료시간을 짧게 주고 비교적 만료시간이 긴 rtk을 함께 생성해 둔 뒤에 atk가 만료되었을때 rtk를 통해 atk를 재발급 해주는 방식으로 동작한다.. 라는 내용으로 만들어진 rtk이고 공부를 하면서 찾아본 책, 블로그 등에서도 모두 이정도로..

refreshToken 리팩토링 : https://devsungwon.tistory.com/entry/Spring-JWT-refreshToken%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EB%AF%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0Redis 소셜로그인 리팩토링 : https://devsungwon.tistory.com/entry/Oauth2-%EC%B9%B4%EC%B9%B4%EC%98%A4-%EC%86%8C%EC%85%9C%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EB%A6%AC%ED%8C%A9%ED%86%A0%EB%A7%81 처음 책을 보고 따라만들어서 jwt토큰 관련 구현이 이상함 문제1. 사용중인 jjwt라이브러리가 옛날 버전이..

채팅목록 관리는 기존 사용하던 방식 그대로 Spring Data JPA와 mysql을 사용했다. 채팅내용을 관리하는 부분에서 어떤식으로 구현을 할지 고민을 많이했다. 처음에는 서버에 저장하지않고 클라이언트에만 저장하려 했으나, 어플이 꺼져있는 동안(소켓연결이 끊겨있는 동안) 온 메시지를 접속시 보여주려면 메시지큐를 다루어야 할것같은데 이 부분이 어렵기도하고 안정성이나 관리 측면을 생각해서 서버에 저장하려고 한다. 하지만 채팅 특성상 채팅데이터가 여러가지 형태로 올 수 있고, 삽입과 조회가 빈번하게 일어나기 때문에 RDB를 사용하면 성능이 떨어질듯 해서 사용해본적 없는 nosql을 써보기로 결정했다. 의존성 추가 implementation ('org.springframework.boot:spring-boo..

현재 프로젝트에서 구현하고자 하는 요구사항은 카카오톡처럼 클라이언트가 꺼져있을때 온 메시지도 받아야하고 내용을 유지시켜야하기 때문에 DB를 연결해야한다. 채팅내용은 어떤식으로 다룰지 고민이 필요하기 때문에 우선 채팅목록과 참여자 등을 관리할 수 있도록 먼저 구현한다. chatRoomDTO @Getter @Setter @NoArgsConstructor public class ChatRoomDTO { private String roomId; // 채팅방 아이디 private String roomName; // 채팅방 이름 private long userCount; // 채팅방 인원수 private List userList = new ArrayList(); public ChatRoomDTO(ChatRoom c..

기본적으로 스프링에서 내장브로커를 제공하지만, 1. 인메모리 형식으로 데이터의 유실 위험도 있고 2. spring boot서버 내에서 함께 처리하기 때문에 서버의 부담도 커진다. 3. 메시지 큐를 모니터링하기 어렵고 4. 또한 현재 프로젝트 규모에서는 아직 필요없지만, 추후 서버를 여러개 둔다면 메시지를 함께 처리할 수 없어 확장성이 떨어진다. 이러한 여러 이유들로 외부 메시지 브로커인 RabbitMQ를 도입하고자 한다. RabbitMQ 의 메시지 전달 과정 1. 송신자가 메시지를 보내면 브로커가 처리과정을 위임받는다. 2. 일종의 우체통 역할을 하는 Exchange로 먼저 전달해서 메시지를 분류한다. 3. exchange에서는 몇가지 종류가 있지만 여기서는 넘어간다. ( Topic은 라우팅 키를 패턴으..

이전 글에서 사용한 방식은 세션을 직접 관리,처리 해주어야했다. 하지만 스프링에서는 웹소켓에 STOMP를 함께 사용할 수 있는 방법을 지원해주는데, 이를 사용하면 메시지처리를 직접하지 않고 편리하게 통신을 구현할 수 있다. STOMP란 Simple Text Oriented Messaging Protocol의 약자로 쉽게 메시지를 주고 받을 수 있게 하기 위한 프로토콜이다. pub/sub 기반으로 작동하며 웹소켓만을 위한 것은 아니나 웹소켓 위에 얹어 편리하게 메시지전송을 구현할수있다. pub/sub 을 간단하게 예로들면 클라이언트들은 특정 주소(채팅방)를 구독할 수 있고, 메시지를 보낸다면 메시지브로커가 해당 주소를 구독하는 모든 클라이언트들에게 메시지를 보여주는 방식이다. stomp를 사용해 통신을 구..

작업중인 프로젝트에서 JWT인증방식을 사용하여 로그인을 하도록 만들었다. 대략적인 흐름은 아이디,비밀번호로 로그인을 했을때 스프링 시큐리티에서 login필터를 거쳐서 로그인을 확인하고 성공시 jwt토큰을 발급해준다. 이후 jwt토큰과 함께 요청이 들어오면 토큰체크필터에서 jwt토큰을 검증하는 방식이다. 그런데 책과 자료를 참고하면서 구현하던중 로그인 필터는 AbstractAuthenticationProcessingFilter를 상속받아 구현했지만 토큰체크필터는 OncePerRequestFilter를 이용하는 경우가 많아 필자도 같은 방식으로 구현을 했다. 우선 OncePerRequestFilter에 대해서 찾아보니 모든 서블릿 컨테이너에서 요청 발송 당 단일 실행을 보장하는 것을 목표로하는 필터 기본 클..

프로그래밍 언어들을 공부한지도 시간이 꽤 흘렀고 물론 이제까지 네이밍 컨벤션을 지켜서 코딩하는 것이 좋다는 것을 알고있었다. 자바에서는 가장 기본적인 규칙중 카멜케이스 사용과 변수명은 소문자, 클래스명은 대문자로 시작하는 것 또한 잘 알고있었고 이제까지 그렇게 코딩을 했었지만 나는 이게 개발에 어떤 문제를 일으킬만큼 중요한 것이라고는 생각하지 못했고 단순히 '개발 중 내가, 혹은 협업하는 동료가 헷갈리지 않도록 통일성을 지키는 것' 정로도 생각하고 있었다. ​ 이제까지 학부생활 중 팀프로젝트로 협업한 규모들이 대부분 작았고, 같은 학생들 입장에서 고작 변수명으로 이래라 저래라 하는 것을 팀원들이 나쁘게 생각할수도 있겠다싶어 종종 지키지 않는 팀원들이 있어도 강요는 하지 않았었다. 모순적이게도 '협업을 위..