Back End/리팩토링 보고서
-
[리팩토링 보고서] JPA 쿼리 성능 최적화Back End/리팩토링 보고서 2022. 3. 5. 02:27
이 포스팅은 삽질 경험을 바탕으로 정리하였습니다. 더 나은 옵션이 있을 시 계속 업데이트 됩니다. 목차 1. Query(Read) Rule 2. 성능개선 내역 Query RULE. 1. xToMany 변수를 가지지 않은 엔티티 JPA QueryMethod(Interface-Projection, UnderScore Join)로 Query한다. API 스펙변화가 Repository까지 전파되지 않아 코드 재사용성이 좋아진다. 원하는 필드만 select하여 네트워크 비용을 소폭 감소시킨다. 2. xToMany 변수를 가진 엔티티 JPA의 Fetch Join 기능을 이용한다. (QueryDSL, @EntityGraph, @BatchSize) 2-1. xToMany 변수가 2개이상 일때 xToOne 을 먼저 모두..
-
[리팩토링 보고서] 서버과부하 방지를 위한 Batch 처리Back End/리팩토링 보고서 2022. 3. 5. 00:26
이 포스팅은 리팩토링 될 때마다 업데이트 됩니다. 북마크 추가/변경/삭제와 같은 많은 가벼운 I/O 의 발생을 효율적으로 처리하고 싶었다. 당시에는 Spring Batch 도 ServerSide Global Caching 전략도 몰랐었다. (그저 서버에서 많은 데이터를 들고 있으면 OOM이 일어나겠지라고 생각했었다.) 그래서 생각해낸게 브라우저(React)단에서 5분간 이벤트 발생을 기록해두었다가 한번에 서버에 요청 하는 방식이었다. 회고록에서도 언급했었지만, 너무 비효율적인 방식이었다. (그리고 책임회피였다..) 일단 하나의 브라우저에서 발생된 이벤트밖에 처리를 못해 모아둔 이벤트의 양이 적을 뿐더러, 여러 유저에 대한 Batch 처리를 못한다는 단점이 있었고 두번째로 브라우저에게 책임을 돌렸기 때문에..
-
[리팩토링 보고서] 일급 컬렉션의 적용Back End/리팩토링 보고서 2022. 3. 4. 21:07
> 일급컬렉션의 필요성 (이동욱님의 블로그) 일급 컬렉션은 Collection을 Wrapping 하며 그 외 다른 멤버변수가 없는 클래스를 말한다. 일급컬렉션의 이점 1. Collection 의 불변성을 보장 2. 상태와 행위를 한 곳에서 관리 3. 비즈니스에 종속적인 자료구조로 코드흐름을 더욱 쉽게 파악가능 따라서 일급컬렉션을 적용하면 유지보수가 용이하며 용도를 분리하게 되어 더욱 객체지향적이게 된다. 프로젝트로의 적용 Summary. 코드 분리로 유지보수가 편리할 뿐만 아니라 불변성으로 인해 사이드이펙트를 최소화하여 협업에 용이 Item Domain @Entity @Getter public class Item extends BaseEntity implements Persistable{ /* field..
-
[리팩토링 보고서] API와 Repository 의존성 제거하기 (DTO-Repository 의존성 제거)Back End/리팩토링 보고서 2022. 3. 4. 17:06
리팩토링 진행마다 계속 업데이트 됩니다. * 버전 표기는 프로젝트 실제 버전이 아닌 의존성의 변화과정을 담기 위해 편의상 표기하였습니다. * v1.0 은 배포된 버전 입니다. (PocketMark) API 변경 시 DTO 만 수정해도 되도록 리팩토링 완료했습니다. API -> DTO -> Repository 에서 API -> DTO 로의 리팩토링 여행기입니다. > v1.0 바로가기 v1.0 의 장점 1. DTO->Repository 의존성 이 제거되어 API 스펙변경에도 끄떡없다. (코드 재사용성 매우 우수) 2. Spring Data JPA가 제공하는 Query Method 를 마음껏 편리하게 사용할 수 있어 신속한 쿼리작성이 가능하다. 3. Projection 이기 때문에 성능적으로도 우수 하다. 4..
-
[리팩토링 보고서] 레이어간 의존성 개선Back End/리팩토링 보고서 2022. 3. 4. 16:56
리팩토링 진행시 계속 업데이트 되는 포스팅입니다. > 레이어간 의존성 감소의 필요성 PocketMark v0.1 레이어 아키텍처 문제점 1(R). API 스펙변경시 엔티티 스펙도 변경해야한다. 엔티티 스펙변경시 API 스펙도 변경해야한다. (API-Entity 의존관계가 있다.) 2(P). API 스펙 확장성을 저해시킨다. 리팩토링 방향 1(R). 데이터 전송만을 담당하는 객체를 만들어 API-DTO, DTO-Entity 로 의존관계를 분리한다. 2.(P). Response 객체를 만들어 멤버변수로 컬렉션을 사용할 수 있게 끔 한다. PocketMark v0.2 레이어 아키텍처 문제점 컨트롤러 단에서 DTO 변경로직이 있다면 서비스 단까지 전파된다. 리팩토링 방향 컨트롤러와 서비스레이어 간 DTO를 새로..
-
[개발노트] PocketMark 개발노트Back End/리팩토링 보고서 2022. 3. 3. 22:50
PocketMark 개발노트 1. 의존관계 줄이기 1-1) 레이어간 의존관계 개선 1-2) 일급컬렉션 적용 1-3) API와 Repository 간 의존성 제거 (DTO->Repository 의존성 제거) 2. 상속을 이용하여 재사용성 높이기 2-1) MappedSuperClass 2-2) @Inheritance (도메인 정규화, @OneToMany -> @OneToOne) 2-3) Spring Data Interface-Based DTO Projection (+불변성) 3. 쿼리성능 최적화 4-1) Query RULE 4-2) OneToMany 에서 fetchJoin(BatchSize) VS 같은로직 직접구현 4-3) Spring Data JPA Repository 반환형 Slice VS Page 4-..