프로젝트 회고

사이드 프로젝트를 진행하면서 채팅 기능을 담당하게 되었다.채팅 기능에 대한 요구사항1:1 채팅 서비스채팅방 별 채팅 기록 저장프로젝트에서 사용할 기술에 대해 회의를 진행하면서 외부 브로커를 사용하기로 결정하였다. 왜냐하면, 프로젝트의 인프라 환경은 단일 서버이지만, 채

성능 테스트 진행 중 커버링 인덱스를 통해 성능을 개선한 사례를 정리해보려고한다. 성능 개선에 대한 내용을 정리하기 전, 테스트 진행 할 기능에 대한 설명을 작성해보려고한다.해당 프로젝트는 투표형 커뮤니티로 게시글 생성 시, 게시글의 내용과 투표에 대한 설명글을 따로

이번 글은 게임 전적 사이트 프로젝트를 진행하면서 성능 최적화하를 위해서 SQL 튜닝한 내용을 정리하기 위해 작성해보려고한다.SQL을 튜닝한 부분은 방명록을 조회하는 기능이었다. 서비스 요구사항에는 유저를 검색하거나 유저의 전적을 확인하면 방명록을 보여주어야한다. 아래

프로젝트를 진행하는데 있어서 회원가입 시 이메일 인증 기능을 구현하게 되었다.이메일 인증을 구현하기 위해서 구글 SMTP를 이용하여 구현하였다. 이처럼 구글 SMTP는 구글 서버에서 제공되는 서비스이기 때문에 외부 API를 호출하는 것과 같다. 또한 구글 SMTP 서비

프로젝트를 진행하면서 UX경험을 향상 시키기 위해서 무한 스크롤 방식을 도입하였습니다.하지만, 백엔드 API는 Offset 기반의 페이지네이션으로 구현되어 있었습니다. 하지만 Offset기반의 페이지네이션은 데이터 중복 문제가 발생한다는 것을 알게 되었다.

데이터 중복 문제로 UX가 저하되는 오프셋 기반 페이지네이션을 커서 기반 페이지네이션으로 리팩토링했습니다.UX측면 뿐 아니라, 성능적인 측면에서는 얼마나 차이가 나는지 성능 테스트를 진행해보려고합니다.

이전에 프로젝트를 진행할 때는, 구현 코드를 작성하고 테스트 코드를 작성하지 않았었습니다.하지만 이번 프로젝트에서는 Controller, Service, Repository, Entity 모든 계층에서 단위 테스트를 진행하였습니다. 그리고 단위 테스트 코드를 작성하면서

이전의 무한 스크롤 방식에서 데이터 조회 시, 중복 현상 이슈를 해결하기 커서 기반 페이지네이션을 도입하였습니다. 이러한 커서 기반 페이지네이션을 적용하여 데이터 중복 이슈 뿐 아니라, 기존의 오프셋 기반 페이지네이션의 한계점인 오프셋이 값이 커질 경우에도 빠른 성능을