Dev_Henry

현재 deal은 image를 oneToMany로 가지고있음. public abstract class Deal { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private long id; @CreatedDate private LocalDateTime createTime; @LastModifiedDate private LocalDateTime updateTime; private String title; private String content; @ManyToOne(fetch = FetchType.LAZY) private Member writer; @Enumerated(EnumType.STRING) private Category category; @El..

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의 테스트 코드 작성법을 공부하고 조금씩 ..

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

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