이 글은 당근마켓을 모티브로 한 프로젝트 Secondhand 구현시 이슈 사항을 정리한 글입니다. 2023.11.24 - [🌱 Spring] - Redis Cache를 적용하여 Read API 기능을 개선해보자 (1) 이론학습 앞서 기본적으로 Cache에 대해서 학습하고 어노테이션을 적용해서 캐시 저장을 해보았는데요. 여기까지 학습과정 중에 아쉬웠던 점은 캐시 추상화 어노테이션을 사용하는 것만으로는 팀원과 구현해보기로 한 `write-back` 을 구현하기 힘들었다는 것입니다. `write-through`는 이런 방식으로 구현할 수 있습니다. @Service public class MyService { @Cacheable(value = "myCache", key = "#id") public String ..

이 글은 당근마켓을 모티브로 한 프로젝트 Secondhand 구현시 이슈 사항을 정리한 글입니다. 사실 처음 시작은 조회수 구현을 어떻게 효율적으로 할 수 있을까에서 출발하였습니다. [조회수 관련해서 참고한 블로그 글] 세션별로 중복되지 않게 일정 시간동안 1회씩 카운팅하고 싶은 욕심이었습니다. 그런데 학습을 하다보니 레디스 Cache를 읽기 API에서도 사용해보고 싶더라고요🔥 API 성능을 개선해본 뒤 차근차근 조회수도 개선해보도록 하겠습니다. Cache에 대하여 캐시 Cache는 자주 사용하는 연산에 대하여 속도가 빠른 임시 공간에 저장해두어 애플리케이션 연산 속도를 높일 수 있습니다. 애플리케이션 연산 속도는 DB I/O작업을 얼마나 줄이느냐에 비례하는데요. 캐시를 사용해서 DB는 물론, 어플리케이..

이 글은 Secondhand 프로젝트를 하며 트러블 슈팅하고 학습한 내용을 정리한 글입니다. 시작하며 Secondhand에 글을 작성할 때는 최대 10장의 이미지를 업로드할 수 있습니다. 이 기능을 구현하고 나서 가장 마음에 걸렸던 부분이 있는데요, 바로 이 10장의 이미지가 하나의 스레드에서 동기적으로 처리된다는 것입니다. 꽤 고화질인 이미지를 10장 한번에 처리를 하면 3초정도 소요되기도 합니다 👀.... 계속 마음에 걸렸던 코드라 이참에 리팩토링을 해보기로 했습니다. 개선 해보자 기존 로직 및 문제점 분석 원래 코드와 시퀀스 다이어그램을 먼저 공유하자면 다음과 같습니다. @Override public List uploadItemDetailImages(List request) throws ImageH..

해당 글에서 구현 언급한 코드는 practice-member-api 에서 확인 가능합니다. 시작하며 초반 연습용 프로젝트에서 회원가입을 구현하며 그냥 일반 텍스트로 회원 비밀번호를 관리해왔습니다. 하지만 보안상 비밀번호를 이렇게 평문으로 저장하는 일은 반드시 지양되어야 합니다. 마침 회원가입과 Jwt 토큰을 사용하는 인증/인가는 매우 자주 쓰는 로직이라 나만의 라이브러리를 만들고 싶었는데요. 원티드 프리온보딩 백엔드 미션이 딱 기본 회원가입 + jwt 토큰 방식의 인증인가 + 게시판 REST API라서 이참에 이 비밀번호 암호화를 구현해보기로 했습니다💪 Spring Framework 는 Spring Security 라는 하위 프레임워크에서 이러한 보안 인증인가 를 편리하게 제공해주고 있지만 해당 암호화 ..

이 글은 당근마켓을 모티브로 한 프로젝트 Secondhand 구현시 이슈 사항을 정리한 글입니다. 들어가며 Secondhand 프로젝트를 진행할 때 가장 마지막에 구현했던 기능인 ‘아직 안 읽은 채팅’에 대해 백엔드 개발자 2명이 한 고민과 구현 과정을 정리해보았습니다. 채팅 시스템은 처음 이 프로젝트를 시작할 당시에 BE는 물론 FE, iOS에게도 굉장히 큰 과제였습니다. 유저간 실시간 채팅을 어떻게 구현할 것이며, 어떻게 DB에 저장할 것인가도 어려운 미션이었는데요. (이것에 대해서는 추후에 따로 글을 적어보기로…) 산넘어 산… “안 읽은 채팅을 어떻게 구현할 것인가”는 다른 의미로 어려웠던 미션이었습니다. 전자는 “새로운 기술을 어떻게 도입할 것인가”라는 고민에 가까웠다면 후자는 채팅 도메인에 대한..

이 글은 당근마켓을 모티브로 한 프로젝트 Secondhand 구현시 이슈 사항을 정리한 글입니다. 상황 Secondhand에는 실시간 채팅 어플리케이션이 있습니다. 웹소켓 통신을 기반으로 하며 STOMP와 Redis pub/sub 으로 구현하였는데요. 이 채팅에 대한 요구사항 중에 다른 도메인의 서비스를 참조하는 경우가 많아져 Facade가 비대해지고 각 도메인의 서비스 로직이 복잡하게 구성이 되며 의존성이 높아지는 우려가 생겼습니다. @Component @RequiredArgsConstructor public class ChatroomFacade { private final ChatroomService chatRoomService; private final ItemService itemService; ..