Spring Boot & JPA API 개발과 성능 최적화

API와 일반 화면은 공통 처리하는 부분이 많이 다름 일반 화면은 에러 발생시 공통 에러 HTML이 나와야 함 반면에 API는 공통 에러용 JSON API 스펙이 나와야 함 따라서 API 패키지를 따로 분리하여 작성

[ 회원 수정 API ] REST API PUT 전체 업데이트시 사용 PATCH, POST 부분 업데이트시 사용 회원 수정도 DTO를 요청 파라미터에 매핑 회원 등록과 수정의 입력 필드는 다를 수 있기 때문에 별도의 response, reque

회원조회 V1 : 응답 값으로 엔티티를 직접 외부에 노출 / 회원조회 V2 : 응답 값으로 엔티티가 아닌 별도의 DTO 사용

현업에서 성능이 나오지 않을 경우 튜닝이 필요함 등록과 수정에서는 성능 문제가 많이 발생하지 않음 조회시에 성능 문제가 크게 발생함

주문 + 배송정보 + 회원을 조회하는 API / 지연 로딩 때문에 발생하는 성능 문제를 단계적으로 해결

- 주문내역에서 추가로 주문한 상품 정보를 조회 Order 기준으로 컬렉션인 OrderItem과 Item이 필요함 Order 엔티티 OrderItem 엔티티 이전 섹션3의 경우 toOne(OneToOne, ManyToOne) 관계만 있었고, 이번 섹션4에는 컬렉션

1. 주문 조회 V3 개선 - 페이징과 한계 돌파 1) 컬렉션 fetch join 최적화시 페이징 한계 컬렉션을 fetch join하면 페이징이 불가능함 컬렉션을 페치조인하면 일대다 조인이 발생하므로 데이터가 예측할 수 없이 증가함 일대다에서 일(1)을 기준으로 페이징을 하는 것이 목적임 그런데 데이터는 다(N)를 기준으로 row가 생성됨 따라서 O...

1. 주문 조회 V4 : JPA에서 DTO 직접 조회 >단건 조회에서 많이 사용하는 방식 OrderApiController 코드 추가 OrderQueryRepository 새로 생성 특정 화면에 핏한 쿼리들은 해당 OrderQueryRepository에서 정의 핵

Open Session In View : 하이버네이트Open EntityManager In View : JPAspring.jpa.open-in-view: true 기본값애플리케이션 시작 시점에 아래와 같은 warn 로그가 남음open-in-view를 유의하여 사용해야한

Spring Data JPA를 사용하면 JPA 기반(Java Persistence API) 리포지토리를 쉽게 구현할 수 있음스프링 데이터 JPA는 JPA를 사용할 때 지루하게 반복하는 코드를 자동화 해줌참고 링크 : https://spring.io/projec

실무에서는 조건에 따라서 실행되는 쿼리가 달라지는 동적 쿼리를 많이 사용함주문 내역 검색을 Querydsl로 구현참고 링크 : http://querydsl.com/Querydsl은 SQL(JPQL)과 모양이 유사하면서 자바 코드로 동적 쿼리를 편리하게 생성할