HappyScrolls 개발기

기능이 완성되면 Postman으로 확인하는 방식을 사용했다. 그러다보니 소셜 로그인이 연결되어 있는 경우, 클라이언트 어플리케이션도 작동시켜서 로그인을 진행하고, 작성한 기능까지 도달하기 위한 선행작업을 진행했다. (예를들어 댓글 쓰기 기능이면 게시글이 선행되어야 함)

많은 SNS에서 댓글을 먼저 보여주고 대댓글을 나중에 보여주는 데에는 이유가 있다고 생각되고, 심지어는 댓글만 띄워도 페이징을 사용하는데, 댓글과 대댓글을 한 번에 불러올 생각을 했다는게 쪼끔 성급했던 것 같습니다...그리고 댓글과 대댓글을 합치는 것이 둘이 같은 기능

전체 쿼리이다. 메소드 하나에서 출력되는 쿼리인데, 너무 많은 쿼리가 날라가는것 같아서 개선해보고자 한다.먼저 맨 위의 두 줄을 해결해보려 했다.맨 위의 두 줄은 인증시에 날아가는 쿼리이고, 인증시에 이렇게 쿼리가 두번씩 나가는 이슈가 있었다.왜 두 번 실행 되는지 궁

페이징 해주는 메소드를 실행했다. 실행되는 쿼리는 다음과 같다. (아직 N+1 문제를 해결하지 않은 상태이다.)첫번째 줄은 이전 포스팅에서 알아본 인증 관련된 쿼리이다.두번째 줄인는 페이징을 위해 나간 쿼리이고마지막 줄인도 페이징에 필요한 카운트 쿼리이다.그 사이의 1

Article을 살펴보면이렇게 ManyToOne으로 Member를 갖고 있다.게다가 페이지 당 10건의 Article을 가져오기 때문에 페이징에 필요한 쿼리에다 추가로 10개의 쿼리를 날리는 것으로 보인다.N+1 문제는 예전 글에서 살펴봤던 것 처럼 페치 조인을 사용하

엔티티간의 어노테이션을 통한 연관관계를 지우고 외래키를 지정해주었다.쿼리는 다음과 같이 작성했다.테이블의 모든 정보를 가져오는게 아닐 때에는 이렇게 인터페이스로 가져와야 한다고 한다.(키워드: 프로젝션)결과는 이렇게 속도도 개선되고, 쿼리도 원하는 만큼만(인증, 조회

작성한 코드는 다음과 같고응답시간은 네이티브 쿼리를 사용했을 때와 비슷하게 가용한 수준으로 나온 것을 알 수 있다.실제 실행된 쿼리는 위와 같다.네이티브 쿼리와 비교해보겠다.네이티브 쿼리를 이용하였을 때QueryDsl을 사용했을 때거의 동일한 쿼리가 나갔음을 알 수 있

현재 서비스 레이어에서 중복되는 코드가 있어서 고쳐보려고 한다.고치는 김에 조금 불편함을 느꼈던 부분들도 같이 고쳐보고자 한다.중복되는 코드는 아래 두개이다.두 메소드 모두 id를 기준으로 Product를 찾아오는 기능을 한다. 다만 하나는 컨트롤러에서 호출하기 때문에

테스트 코드를 작성하다가 기존 코드가 잘못되었음을 알았다.위 코드는 게시글을 수정하는 메소드이다.헌데 수정을 하고 ArticleDTO를 반환하는 과정에서 ArticleDTO.Response.builder()의 인자가 수정된 게시글이 아니라 기존에 수정하고 싶은 게시물을

내 어플리케이션이 얼마나 뛰어난 성능을 갖고 있는지, 혹은 얼마나 안좋은 성능을 갖고 있는지 알기 위해 그라파나 + 프로메테우스 + Jmeter 구성을 갖고 실험해보았다.클라우드 상에서 테스트를 하면 N백만원이 과금될수도 있기 때문에 로컬상에서 진행했다.적당..하다고

처음에 구상한 아케텍처는 다음과 같았다.쿠버네티스를 이용하고, hpa를 통해 트래픽이 늘어나면 pod를 증가시키는 식으로 부하를 분산하고 싶었다.그래서 미니쿠베로 쿠버네티스도 공부해보고,eks로 클러스터도 구성해봤는데 생각보다 많이 어려웠다.구글링해가면서 하면 어찌저찌

.

.

2차 스프린트에 앞서 간단하게 리팩토링을 진행했다.기존의 코드는 다음과 같이 Raw 타입으로 반환하고 있었다. ResponseEntity에 들어갈 body가 어떤 타입이든 상관이 없었는데, 이것이 문제가 될 것 같아 수정해주었다. 이와 비슷한 경험은 이전에 NOTODO

buyCreate가 실행되면 다른 서비스에서 실행되어야할 로직들이 실행된다.1\. CartService에서 cart를 불러온다.2\. ProductSevice에서 Product를 불러온다.3\. CartService에서 cart를 삭제4\. MemberService에서

위와 같은 코드가 있다.현재 프로젝트에는 수량을 확인하고 0개보다 많이 있으면 물건을 구매하고 수량을 1개 줄이는 코드가 있다.아래의 테스트코드를 실행하면 코드가 제대로 동작하지 않음을 알 수 있다.총 수량이 100개인 물건이 있고, 100개의 쓰레드를 동작시켜서 수량

기존 배치 코드는 다음과 같았다. notificationJob setBatchStep customerItemReader articleWriter 여기서 눈여겨 볼 코드는

문제 레디스를 이용하여 캐시서버를 구성하고 있는 상황인데, 만약 레디스 서버가 다운되면, 레디스 캐시를 이용하는 api를 호출했을 때 오류가 나는 상황이 발생했다. 레디스는 캐시이기 때문에, 레디스에서 오류가 나면 원래 실행되어야 할 쿼리를 날려 DB에서 값을 받아

최종적으로 수정된 아키텍처는 다음과 같다.지난글지난 글에서 의존하는 방향을 통일하고, 코드의 중복을 줄이고 재활용할 수 있도록 코드 아키텍처를 수정했었다.따라서 현재 아키텍처는 대략적으로 아래의 사진과 같다.문제는 컨트롤러, 서비스, 리포지토리 모두가 엔티티에 의존하고

부하 테스트 지난번에 진행했던 부하테스트는 처음이었기도 하고, 객관적인 분석을 하기가 여러모로 힘든 결과 데이터 같아서 다시 진행해보려 한다. 다음과 같은 설정으로 컨테이너에 1메모리를 할당하였고, 1코어의 CPU를 할당하여서 리소스를 제한시켰다. docker ru

개요 복제 DB를 이용한 성능 개선을 공부하고자 한다. 실험 환경 docker mysql 8.x 1ro ![](https://velog.velcdn.com/images/chs9

검색 기능은 다음과 같이 구현되어 있습니다.위 코드는 mysql로 치면와 같은 쿼리가 실행됩니다.뒤쪽에 있는 article.id > listindex 부분은 offset을 사용하지 않는 페이징을 위해 적용한 것입니다.검색을 위한 부분은 like %param% 인데, t

이 전 글에서 mysql like 쿼리로 작성했던 검색기능을 엘라스틱 서치로 바꾸는 과정을 회고했습니다.엘라스틱 서치를 이용한 검색 기능 성능 개선 (1)엘라스틱 서치를 적용하기 전 검색 기능은 제목을 기반으로 한 기능이었습니다.queryDsl을 이용해서 like쿼리를