Dev_Henry

현재 진행중인 프로젝트에서 하나의 이미지와 다른 값들을 받아서 방명록 객체를 만드는 api가 있다. 처음엔 다른 일반적인 요청을 받을때처럼 하나의 DTO를 정의해서 요청값으로 받았다. 다만 평소처럼 그냥 RequestBody를 적어주고 스웨거를 들어가면, 파일을 올릴수없고 다른 값들과 함께 Json 텍스트값을 입력받게 되어있는 것을 볼 수있다. 사진파일은 다른 값들처럼 JSON으로 보낼수 없다. 사진파일을 받기위해 MULTIPART_FORM_DATA 타입으로 요청을 받도록 했다. @Getter @Setter @NoArgsConstructor(access = AccessLevel.PROTECTED) @AllArgsConstructor public class GuestBookRequest { String n..

우테코 프리코스를 진행하다보면 배워갈게 많다고 해서 프리코스를 진행중이다. 과제의 요구사항이 적다보니 1주차는 별 생각없이 구현을 했었는데 사람들을 보니 전부 MVC패턴으로 구현하고 있더라.. 그래서 2주차는 나도 좀 분리를 해서 작성했는데, 음 여전히 요구사항 자체가 별로 없다보니 굳이 잘게잘게 분리하는게 비효율적으로 느껴져서 적당한 크기로만 분리했었다. 그리고 이번 3주차 과제는 좀 더 본격적으로 분리를 하려고 했다. 분리를 하는김에 spring을 흉내내서 각각 객체들을 싱글톤으로 관리하고, 처음 프로젝트를 돌릴때 의존성 주입방식으로 생성해주면 더욱 효율성 좋고 유지보수가 편리하도록 만들 수 있을것 같아서, 이렇게 진행하려한다. 보통 싱글톤을 간단하게 구현하는 방식으로는 lazy initializat..

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

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

+ 내용 추가 프론트에서 카카오 로그인 - 인가코드를 받는 부분까지 처리하고 인가코드를 백엔드에게 넘겨준 후에 나머지 처리하는 로직이 일반적으로 프론트와 백엔드가 분리되어있을 때 사용하는 방식은 맞지만 몇가지 문제가 더있었다. 프론트에서 웹뷰를 사용한다면 이런 로직으로 구현하는데 전혀 문제가 없고 주로 사용하는 방법이다. 그런데 우리 프론트는 flutter를 사용하고 있었고, flutter에서 카카오가 제공해주는 로그인 api를 사용하기 위한 방법은 두가지가 있다. 웹뷰에서 사용할 수 있는 redirect방식 네이티브에서 사용할 수 있도록 기능을 제공하는 sdk 아래에 구현한 내용은 일반적으로 1번 방식에서 가능한 방식이다. 네이티브에서 사용하는 sdk는 인가코드만 달랑 받아와서 따로 서버에 전달할 수 ..

진행중인 프로젝트에서 처음 구현할때 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라이브러리가 옛날 버전이..

현재 프로젝트에서 구현하고자 하는 요구사항은 카카오톡처럼 클라이언트가 꺼져있을때 온 메시지도 받아야하고 내용을 유지시켜야하기 때문에 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를 사용해 통신을 구..