Dev_Henry

스프링 프로젝트를 만들면 application.properties 혹은 yml 파일에 각종 설정 정보를 입력하게 된다. 이 정보에는 api key, db 접속정보 등 보안정보도 포함되기 때문에 그대로 Git과 같은 온라인상에 올려버리면 낭패를 겪게된다. 이런 문제를 해결하기 위한 방법으로는 암호화 라이브러리를 사용하여 암호화하는 방법과 해당 정보를 다른 파일로 분리하고 gitignore에 추가하는 방법이 있다. 나는 정보를 다른 파일로 분리하는 방법을 사용할 것이고 git에 공개된 설정파일에서도 대략적인 코드 구성을 파악하기 쉽도록 해당 '보안데이터' 만 분리 할 것이다. 스프링 프로젝트를 할 때 항상 properties만 사용했는데 이번에는 yml파일을 사용해보고싶어서 처음으로 시도했고 yml에서는 설..

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

이어서 controller의 테스트 코드를 작성해 보겠다. memberAccountController @ApiOperation(value = "회원가입") @PostMapping("/join") public ResponseEntity joinPOST(@Valid @RequestBody MemberJoinDTO memberJoinDTO){ memberService.join(memberJoinDTO); //return ResponseEntity.ok(ResultResponse.of(REGISTER_SUCCESS, true)); return ResponseEntity.status(HttpStatus.CREATED).body(ResultResponse.of(REGISTER_SUCCESS, true)); } 테스..

1편에 이어서 service의 테스트 코드를 만들어 보자. memberServiceImpl @slf4j @Service @RequiredArgsConstructor public class MemberServiceImpl implements MemberService{ private final AccountUtil accountUtil; private final ModelMapper modelMapper; private final MemberRepository memberRepository; private final PostRepository postRepository; private final ScrapRepository scrapRepository; private final PasswordEncoder ..

스프링부트를 이용하여 프로젝트를 하던중 1차 개발이 끝나고 2차 개발을 시작하기 전에 컨벤션에 맞지 않는 무분별한 네이밍과 깔금하지 못한 코드들을 리팩토링하는 과정을 먼저 거쳤다. 팀원 모두 스프링에 대한 이해도가 부족한 상태에서 처음 진행하는 프로젝트다보니 테스트코드를 작성할 여유도 없었고, 어떤식으로 작성하는지도 몰랐기 때문에 테스트코드 없이 postman을 이용해 직접 테스트하며 구현했었는데, 나중에 리팩토링을 하려니 문제가 생겼다. 기존 변수명,함수명, 클래스 구조 등이 바뀌다 보니 예상치 못한 에러가 많이 발생해서 어려움을 겪었는데 테스트코드가 있었다면 이 과정이 훨씬 편해졌을 것이란걸 알고서 테스트코드의 필요성을 느꼈다. 이런 이유로 spring mvc의 테스트 코드 작성법을 공부하고 조금씩 ..

진행중인 프로젝트에서 처음 구현할때 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은 라우팅 키를 패턴으..