RequestBody의 값을 검증하기 위해서 @Valid를 사용합니다. 대부분의 예시를 보면, Validator 를 커스텀해서 어노테이션 형태로 사용합니다. 저는 ChannelTypeValidator 를 만들어서 사용했습니다. APP, PC, MOBILE 등 다양한 채널로 유저가 유입될 수 있습니다. 세가지의 채널을 모두 검사할 수도 있지만, 1~2 종류의 채널만 허용할 수도 있습니다. 그런 상황일 때 Validator 를 추가로 생성하지 않고 구현 클래스 안에서 분기 처리를 하도록 커스텀했습니다. 예시 Validator Interface @Retention(RetentionPolicy.RUNTIME) @Constraint(validatedBy = ChannelTypeValidator.class) pub..
Spring
@Valid Valid 어노테이션은 자바 표준 스펙입니다. Controller 계층에서 dto의 유효성을 검사할 때 사용합니다. @PostMapping public ApiResult createGroup(@CurrentUser User user, @Valid @RequestBody CreateGroupRequest createGroupRequest) { return ApiUtils.success(groupService.createGroup(user, createGroupRequest)); } 검증할 dto 앞에 사용함으로써 내부 로직을 수행하기 전에 dto를 검사합니다. public class CreateGroupRequest { @Size(min = 2, max = 20, message = "그룹명은 ..
⏰ 성능 이슈 발생 쿼리 메서드를 작성하고 의도한대로 작동했는지 확인하고 있었습니다. 엔티티에 존재하는 applicant, group, status 필드를 조건으로 하여 데이터를 조회하는 쿼리 메서드입니다. Repository import org.springframework.data.jpa.repository.JpaRepository; public interface SubscriptionRepository extends JpaRepository { Optional findByApplicantIdAndGroupIdAndStatus(UUID applicantId, Long groupId, SubscriptionStatus status); } Entity import jparest.practice.group...
⏰ 성능 이슈 발생 서비스 로직을 테스트 하는 중이었습니다. 1. 클라이언트는 api 호출 시, naver map api 로 부터 조회 받은 식당 ID 값과 서버로 보내준다. 2. 서버는 식당 ID 값과 추가 정보를 DB 에 저장한다. 간단한 로직이기에 문제는 없을 거라 생각했습니다. 그런데 식당 정보를 DB 에 저장할 때 select 쿼리가 호출됐습니다.. Insert 쿼리를 호출하기 전에 select 쿼리가 반복적으로 호출된다면, 클라이언트의 api 호출 수만큼 select 쿼리가 호출되는 것입니다. 서버에 불필요한 부하가 추가되는 로직이므로 수정이 필요했습니다. 🔍 성능 이슈 원인 save 엔티티를 저장하는 save 메서드는 아래 코드로 구현되어 있습니다. 저장될 엔티티가 새로운 엔티티인지 확인합니..
