땍땍 블로그

프로젝트를 진행하던 중, 기존 페이징 처리가 되어있던 부분이 무한스크롤 방식으로 변경이 되었다.때문에 사용자에게 페이지 번호를 전달 받을 필요가 없었고 Jpa의 Pageable을 사용할 이유가 없었기에 다른 방법을 모색하게 되었다.Jpa Pageable 의 가장 큰 문제는 페이지 번호가 증가함에 따라 반환 시간이 증가한다는 점이다.이는 Pageable이 Offset 방식으로 동작하기 때문인데, 페이지 번호가 증가할 수록 앞선 페이지의 데이터를 스캔하고 버려야하기에 일정한 반환 시간을 보장할 수 없게 된다.아래는 Mysql 8.0 환경에 저장된 1100만 개의 데이터를 활용해 페이지 별 반환 시간을 테스트 해본 결과이다.데이터는 페이지당 10개 씩 읽어오도록 하였다.// 테스트 엔티티@Entity@Gett..

공식 문서https://naver.github.io/fixture-monkey/v1-0-0-kor/docs/plugins/jakarta-validation-plugin/features/fixtureMonkey를 사용하여 실제 테스트 코드를 작성하다보면 무조건 한 번씩 발생하는 오류 중 하나가 필드별 제약 조건이다.분명 닉네임 값은 필수 값이며, 최대 20자 까지 밖에 입력이 되지 않아야하지만, fixtureMonkey는 이를 무시하고 null 값을 반환하거나 최대 자리수를 초과하는 값을 생성하곤 한다.이러한 문제는 JakartaValidationPlugin 를 사용하여 해결할 수 있다.사용 가능한 어노테이션은 해당 글 하단에 작성해두었다. 공식 문서에서 가져온 내용이니 시간이 여유롭다면 공식 문서를 참고..

공식 문서https://naver.github.io/fixture-monkey/v1-0-0-kor/테스트 코드를 작성하다보면 객체, 보통 엔티티에 무작위한 값을 넣고 이를 테스트해야하는 경우가 많다.다만 이러한 과정을 위해 시간을 소요하고 동일한 과정을 반복하는 것이 번거롭기에 이를 간단하게 해결 하기 위해 나온 것이 Fixture Monkey이다.사용법은 정말 간단하다.의존성// GradletestRuntimeOnly("org.junit.platform:junit-platform-launcher:{version}")testImplementation("com.navercorp.fixturemonkey:fixture-monkey-starter:1.0.23")// Maven com.navercorp.f..

service , controller 등에서는 mock 을 이용해 로직이 잘 동작하는지를 주목적으로 테스트 코드를 작성 하지만, Repository Test는 실제로 데이터가 DB에 잘 이동하는지 확인하기 위해서 하는 목적이 큰 만큼 mock을 사용하는 것이 아닌 실제 DB를 이용하는 것을 추천한다.실제 DB는 사용 중인 개발/운영 서버의 DB에 테스트 후에 Transaction을 하는 방법도 있겠지만, 데이터가 많거나 실제 운영 중인 서버라면 속도 지연의 원인이 될 수 있기에 테스트 DB는 따로 설정하는 것이 좋다.이를 위해 휘발성 DB인 H2를 이용하도록 하겠다.testRuntimeOnly 'com.h2database:h2'테스트를 진행할 테이블은 Members 테이블이며, 아래와 같은 구조를 가지고..

프로젝트의 규모가 크지 않거나, 시작 단계일 경우 하나의 Repository에서 모든 쿼리를 관리하는 경우를 종종 볼 수 있을 것이다.public interface MemberRepository extends JpaRepository { Optional findByEmailAndNickname(String email, String nickname); List findByRole(Role role); ... 등등}위의 코드는 아직 정의된 메소드가 두 가지 밖에 없기에 잘 와닿지 않겠지만, 관련 쿼리가 몇 십,백개가 넘어가거나현재는 Jpa만 사용하지만 jpsql 혹은 querydsl 등으로 직접 쿼리문을 작성하는 경우 하나에 파일에서 관리하게 되면 코드가 복잡해져 유지보수에 있어 어려움을 느낄 ..

https://start.spring.io/ 에서 생성된 프로젝트를 그대로 실행하였을 경우 springboot가 실행과 동시에 종료가 된다.다양한 이유가 있겠지만, 로그에 Tomcat 관련 내역이 없다면 의존성을 추가하지 않아 발생하는 오류일 가능성이 높다.해결 방법 → 의존성 추가implementation 'org.springframework.boot:spring-boot-starter-web'자칫 org.springframework.boot:spring-boot-starter 과 동일한 의존성인 줄 아는 분들도 계시지만, 다른 의존성이기에 별개로 추가해주어야 한다.

응답 공통 포맷은 협업에 있어 일관성 있는 형식으로 값을 제공함으로 효율적인 작업을 위해 설정하곤 한다.이러한 포맷은 어디까지나 편의를 위해 설정하는 만큼 서비스에 따라 설정 값은 다르지만,응답 상태 값 ( error code , message 등의 상태를 확인할 수 있는 값 )반환 데이터 값위 두 가지는 많은 곳에서 활용하는 것같다.아래 코드는 기본적인 코드이다.@Getterpublic class ApiResult { private final String code; private final String message; private final T data; public ApiResult(String code, String message, T data) { this.code = code; ..

코드를 작성하고 테스트를 하거나 디버깅을 하는 과정에서 로그를 봐야하는 상황은 정말 많이 존재한다.하지만 이러한 로그에는 구분을 위한 ID 값이 존재하지 않기에 특정 로그를 찾는데 어렵다는 문제점이 존재하였다.이러한 사항 과정의 불편함을 줄이기 위해 각 로그 별로 특정 ID를 생성해 함께 출력하도록 하려 한다.로그에 ID 값을 출력하기 위해서는 로그 포맷을 변경해주어야 하는데, 기본 설정의 경우 아래와 같은 형식으로 로그가 출력되고 있을 것이다. 포맷 변경을 위해서는 application.yml 에서 간단하게 처리할 수 있으나, 세부적인 설정이 불가하기에 이번에는 logback-spring.xml 을 통해 변경해보도록 하겠다.logback-spring.xml 파일은 resources 아래에 생성해주면 된..

서버를 두고 작업하는 경우 보통 로컬에서 사용하는 환경과, 서버에서 사용하는 환경을 분리해서 사용하는 경우가 있을 것이다.대표적으로 로컬에서는 h2를, 서버에서는 mysql과 같이 사용을 하거나, mysql을 사용하더라도 로컬에서는 localhost 를, 서버는 주소를 입력하여 사용하곤 할텐데 이를 간단하게 구분할 수 있는 방법이 있다.이는 application를 여러개 만들어 사용하는 방법인데, 보통은 아래와 같이 생성하여 사용하지만 필요한 만큼 생성하고 제거하면 된다.application , application-local , application-dev , application-prodapplication.yml 에는 어떤 환경에서든 공통적으로 사용하는 사항들 ( 스웨거, 변수,, 등등 )local..

개발을 진행함에 있어 작성한 코드를 기록하고 누구나 이해하기 쉽게 남기는 것은 너무나 중요한 사항이다.이러한 것들을 직접 손으로 기록하여 메신저를 통해 다른 사람에게 전달하는 방식도 물론 있으나 이러한 과정 없이 자동으로 내가 만들어낸 API를 문서화 시켜주는 도구들이 여럿 존재한다. ( swagger, postman, spring rest docs 등등 .. )그중 이번에는 스웨거 ( sawgger ) 에 대해 소개하고 사용하는 방법을 작성하려 한다.스프링부트에서 스웨거를 사용함에 있어 선택할 수 있는 사항이 크게 2가지가 있는데 Springfox와 Springdoc이다.사실 사용함에 있어 큰 차이점이 있는 것은 아니지만 Springfox는 2020년을 기준으로 업데이트를 중단했기 때문에 특별한 이유가..