초콜릿 파워

@EntityGraph 어노테이션 자세한 설명1. @EntityGraph란? @EntityGraph는 JPA의 FetchType.LAZY로 인해 발생하는 N+1 문제를 해결하는 방법 중 하나이다.JPA에서 @ManyToOne, @OneToMany 등의 관계를 Lazy Loading으로 설정하면, 연관된 엔티티를 조회할 때 추가적인 SELECT 쿼리가 발생한다. @EntityGraph를 사용하면 JPQL이나 Native Query 없이도 한 번의 쿼리로 연관된 엔티티를 함께 조회할 수 있다. LEFT JOIN FETCH와 유사한 동작을 수행하는 것이 특징이다. 2. @EntityGraph의 사용 목적: N+1 문제를 해결하는 등 성능의 최적화에 도움이 된다. Fetch 전략을 지정할 수 있는데, 직접 JP..

로그인 관련하여 사용자 경험, 보안을 모두 고려해서 refresh token 을 설계하는 것은 매우 기본적이면서도 중요한 문제이다. 이번에는 frontend- backend 각각에서 refresh token 처리를 위한 논리 중 기본적인 뼈대를 정리해보았다. 각각의 구현 방법과 장/단점도 포함되어있다.  사용자가 로그인하면서버는 Access Token과 Refresh Token을 발급한다.Access Token은 메모리(React의 State, Redux, Vuex 등)에 저장한다. Refresh Token은 보안을 위해 HttpOnly Secure Cookie에 저장하거나, 로컬 스토리지에 저장(이 방식은 위험한 편)한다.API 요청 시프론트엔드는 Access Token을 Authorization: B..

프로그래밍을 할 때 Null 데이터를 잘 처리하는 것은 매우 중요하다.  프레임워크 혹은 라이브러리를 활용해 Null 을 허용하지 않음으로써 null에 접근하는 오류를 사전에 방지할 수 있다. 다음 라이브러리에서 어노테이션 활용이 가능하다. Null 처리를 돕는 몇가지 라이브러리에 대해 정리해보려고 한다. Javax Validation (JSR-303/JSR-380) @NotNull null을 허용하지 않음Lombok (lombok.NonNull)@NonNullnull이 들어오면 NullPointerException 발생Spring (org.springframework.lang)@NonNullnull을 허용하지 않음 (Spring 전용) 1. Javax Validation (javax.validation..

GZIP (Content-Encoding: gzip)gzip은 웹에서 데이터 전송 시 사용되는 압축 방식으로, 응답 데이터를 압축해 전송함으로써 전송 속도를 높이고 대역폭을 절약한다.텍스트 데이터 혹은 json 과 같은 웹 응답 데이터를 압축하면 성능을 올리는데 도움이 된다. 주로 HTTP 응답에서 사용되며, Content-Encoding 헤더에 명시된다.  1.  요청 헤더 (클라이언트 → 서버)GET /index.html HTTP/1.1 Host: example.com Accept-Encoding: gzip, deflategzip: GZIP 압축을 지원함deflate: DEFLATE 압축을 지원함. 2. 응답 헤더 (서버 → 클라이언트)HTTP/1.1 200 OK Content-Encoding: gz..

Java의 Optional은 null을 직접 다루지 않고 안전하게 값(객체)을 다룰 수 있도록 감싸는 컨테이너이다. 기본적으로 null을 방지하는 방법은 javax validation, spring validation, lombok 등에서 제공하는 어노테이션을 활용하는 방법을 통해 null이 아니어야 하는 데이터를 사전 방어 하는 방식이 있다.  이번에 알아보는 방법은, 그런 경우는 다 막더라도 null일 수 있는 데이터에 대해 어떻게 처리할 것인가, 이다.  JAVA SE 8부터 등장한 Optional 은, null이거나 , null이 아닐 수 있는 데이터를 안전하게 감싸고 있는 클래스이며 다양한 api를 제공한다.1. Optional 을 사용하지 않고 get() 을 사용하는 경우. (비추천)- 값이 ..

java 8부터는 default 키워드를 사용하면 인터페이스 내에서도 메서드의 구현을 포함할 수 있다. public interface ColorRepository { // 기존 방식 (쿼리 실행을 위한 선언) @Query(value = "SELECT ...", nativeQuery = true) Optional findByIdAndLangCd(@Param("id") Long id, @Param("language") String language); // default 메서드 사용하기 default Optional findById(Long id) { return findByIdAndLangCd(id, "en"); // 기본값 "en" 적용 }}default 키워드..

deleteAllInBatch() 함수란? org.springframework.data.jpa.repository.JpaRepository에서 정의되어 있다. 비교할 대상인 deleteAll()은 인터페이스 org.springframework.data.repository.CrudRepository에 정의 되어있다. 둘다 구현체인 org.springframework.data.jpa.repository.support.SimpleJpaRepository에 구현되어있다.  Spring Data JPA의 JpaRepository에서 제공하는 대량 삭제(Batch Delete) 메서드로, 모든 엔티티를 한 번의 SQL 쿼리로 즉시 삭제하는 기능을 한다. deleteAll 메서드는 조회후 삭제하는 반면 (SELECT..

SQL최적화를 수행하는 도중, 최적화를 수행한 쿼리의 내용은 다음과 같다.  table b를 table a에 left join 하는 과정에서 on 의 조건이 어차피 b의 PK 였던 경우. 예를 들면 이런 경우이다. select * frombleft join a on a.id = "1234" 이런식의 조인 쿼리는 서브쿼리로 조회하는 게 더 빠르지 않을까 싶어서 서브쿼리로 바꿨더니, explain analysis 분석결과는 sql 2배 가량 속도가 빨라졌다.그러나 막상 JPA 상에서 실행 결과를 확인할 때는 별로 시간 차이가 없었다.  (오히려 조금 더 느렸다.)이 과정에서 세운 여러 가설을 검증하다보니 SQL 엔진에서 join을 수행하는 원리에 대해서도 찾아보게 되었다. (이 문제를 해결한 내용은 추후 글..

우선 간단히 적으면 다음과 같다. 배포 전략 무중단 배포  롤백 가능성 인프라 비용 적용 용도Blue-Green✅✅높음대규모 서비스, 빠른 롤백 필요Canary✅✅중간점진적 배포, 성능 테스트 필요Rolling✅❌낮음인프라 비용 절감, 지속적 배포Recreate❌✅낮음단순한 서비스, 빠른 배포 필요A/B Testing✅✅높음사용자 반응 기반 배포Feature Toggle✅✅낮음코드 배포와 기능 배포 분리 여기서는 3가지 업데이트 방식만 보려고 한다 .   1. 롤링 업데이트 방식특정 비율로 조금씩 점진적으로 업데이트하는 방식이다. (예: 인스턴스 하나씩 새로 배포되는 )다운 타임 제로라는 장점을 갖고 있다.구글도 작은 서비스를 배포할 때 이방식을 사용하고 있다. 문제점동시에 서비스의 여러 버전이 존재한다..

DTO 전달하는 방식서비스 확장성이 높음새로운 필드가 추가될 경우, Service의 메서드 시그니처를 변경하지 않고 DTO만 수정하면 된다. 의미 전달이 명확함DTO 자체가 하나의 도메인 개념을 가지므로, 어떤 요청인지 쉽게 이해 가능하다.서비스 인터페이스가 명확함createUser(UserRequestDto requestDto)처럼 도메인 중심적인 메서드 시그니처를 유지할 수 있다.하지만 반대로 동일한 함수를 다른 곳에서도 사용하고 싶을 때 dto 를 만들어서 전달하는 과정이 추가될 수도 있다.   파라미터를 전달하는 방식 DTO 와 독립적: dto가 변경되어도 service 레이어가 변경될 필요는 없다. dto 는 controller 의 요청을 표현하는 역할, service 레이어는 비즈니스 레이어를..