프로젝트

현재 공유게시판을 들어가면 모든 공유 게시글을 가져오는데 이때 offset 기반의 페이지네이션을 채택했다. cursor 기반도 고민했었지만 페이지를 제공해야 한다는 점에서 offset을 채택할 수밖에 없었다. 그런데 가장 문제가 되는 것이 성능 저하의 문제가 발생하는 것. offset 기반으로 동작하면 offset과 limit이 주어지는데 offset까지 데이터를 풀스캔하고 그 데이터를 버리고 limit 만큼 찾아오기 때문에 불필요한 데이터 조회가 발생하게 되는 것이다. 아래는 현재 쿼리의 상태이다.List apiRecommendPostsResponseDTOS = queryFactory. select(Projections.constructor(ApiR..

추천받은 restapi를 공유한 게시글의 좋아요를 누르도록 설계를 진행했다. PostLike의 Entitypublic class PostLike extends BaseTimeEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "member_id") private Member member; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "post_id") private Post post;  좋아요 서비스// 좋아요 누르기..

이번에 정말 좋은 기회를 통해 보초님의 코드 리뷰를 받을 수 있었습니다. 해당 리뷰를 바탕으로 코드 개선을 진행하고 그 과정을 공유하려고 합니다.(조금 내용이 길어질 수 있다는 점) 1.generated 이그노어 처리QueryDSL을 사용하면서 큐클래스 파일이 그대로 깃에 올라가있는 문제 발생.깃 명령으로 캐시 삭제를 진행하고, 명시적으로 이그노어에 추가해서 반영 완료. 2. gradle 형식 통일기존에는 gradle을 추가하면서 형식이 제각각이었다. 어떤 건 short, 어떤건 그냥 gradle 등등..그래서 이번에 하나로 통일을 진행했다.   3. 사용하지 않는 import 제거 사실 크게 신경쓰지 않았던 부분이지만 이번에 코드 리뷰를 통해 optimize import 기능을 이용해서 사용하지 않는 ..

문제 상황 현재까지 만들어놓은 모든 API에 대해서 로그 파악을 진행하다가 질문 상세내역으로 들어가면 N+1 문제가 발생하는 걸 확인했다. 해결 과정 아래 로그는 해당 질문 상세내역으로 들어가는 건데 4개의 쿼리가 실행되고 있다.Hibernate: select m1_0.id, m1_0.banned_date, m1_0.create_date, m1_0.email, m1_0.login_last_date, mr1_0.member_id, mr1_0.id, mr1_0.role, m1_0.nickname, m1_0.password, m1_0.social_type, ..

문제 상황 관리자가 유저요청기록 페이지에 들어가면 전체 데이터를 가져와서 화면에 보여주게 된다.ApiRequesHistory에는 요청 기록이 담겨있고, Member와 1:1 관계를 가져서 누가 어떤 요청을 날렸고 어떤 응답을 받았는지 기록하게 된다. 조회 쿼리를 살펴보면 이렇게 쿼리가 날아가는데 실제 응답 DTO에서는 Member에 관한 데이터는 email 말고 사용하지 않는다.즉 9개의 데이터 중 1개만 필요한 상황인데 DB에서 과하게 부르고 있는 문제가 있다. 데이터가 하나라면 상관없지만 더미데이터를 75만 개 넣어뒀으니 불필요한 데이터 호출이 배로 늘어나고 있는 상황. 해결 방법 그래서 DB에 받는 데이터를 DTO에 직접 담아주려고 한다. 아래거 현재 작성된 쿼리문이다.List results = q..

문의 사항에 답변을 다는 로직을 진행하는데 문제가 발생했다.여기서 답변을 작성하고 답변하기를 누르면 작성까지 3~4초의 시간이 걸리게 된다.  그 이유는 컨트롤러의 로직이 아래처럼 작성되어 있기 때문이다.// 답변 등록 @PostMapping("answers") public ResponseEntity> createAns..

내 서비스는 소셜 로그인, 자체 로그인 2가지가 존재한다. 소셜 로그인의 경우 회원 탈퇴를 진행할 때 비밀번호 입력이 필요하지 않다.반면에 자체 로그인의 경우 비밀번호 입력이 필요하다. 그래서 로그인하면 유저 정보를 가져올 때 소셜 유저인지 판단해서 Pinia에 저장해 두었다.const social = computed(() => store.social); 그리고 먼저 소셜 유저면 true를 리턴하고 소셜 유저가 아니면 비밀번호 입력칸 체크부터 진행했다.// 비밀번호 입력 확인 -> 모달 띄우기const checkInput = () => { if (social.value) { showModal.value = true; return; } if (password.value.length ==..

대체 어디서부터 잘못됐을까download 폴더를 정리하다가 나도 모르게 pem 키를 삭제했나보다...프론트 다시 배포하려는데 파일질라 접속이 안 돼서 깨달았다. 그래서 다시 재발급을 진행하려고 한다.  pem key를 재발급해서 적용하는 방법에는 알려진 건 2가지 방법이 있다. 나는 그 중에서 인스턴스를 AMI 이미지로 만들고, AMI를 인스턴스로 새로 만들어 키페어로 등록하려고 한다. 우선 키페어에 가서 새로운 키를 발급받는다.  그리고 본인의 인스턴스 우클릭 후 이미지 생성을 눌러준다.  이미지를 하나 생성해 줍니다.  왼쪽에 AMI를 눌러서 사용 가능 상태로 변경되면 사용이 가능합니다. 인스턴스 시작을 눌러줍니다.   이름을 정해주고 OS 이미지 같은 경우는 기존의 EC2 인스턴스와 동일하게 설정해..