# zzaksim

belljun3395

[Querydsl] 사례공부06 / 페이징 성능 개선하기 출처 : https://jojoldu.tistory.com/528 NoOffset 기존의 페이징 방식이 페이지 번호(offset)와 페이지 사이즈(limit)를 기반으로 한다면 NoOffset은 페이지 번호(offset)가 없는 더 보기 방식을 이야기한다. NoOffset은 기존 페이징 쿼리보다 빠르다. 왜 그럴까? 우선 기존 페이징 쿼리를 살펴보자. 위의 기존 쿼리에서 특히 페이징 쿼리가 뒤로 갈수록 느리다고 하는데 이는 앞에서 읽었던 행을 다시 읽기 때문이다. 뒤로 갈수록 버리지만 읽어야 하는 행의 개수가 많아져서 뒤로 갈수록 느려지는 것이다. 하지만 NoOffset 방식은 조회 시작 부분을

belljun3395

[Querydsl] 사례공부05 / Groupby 최적화하기 출처 : https://jojoldu.tistory.com/477 우선 MySQL에서는 Group by를 하면 file sort가 함께 수행된다고 한다. 인덱스에 있는 칼럼으로 Group by를 한다면 이미 인덱스로 인해 정렬된 상태이기에 큰 문제가 되지 않는다. 하지만 만약 정렬이 필요 없는 Group by라면 자동 정렬은 성능에 악영향을 줄 뿐이다. 자동으로 정렬이 되지 않게 하기 위해서 MySQL에서는 order by null을 사용한다. 하지만 Querydsl에서는 order by null 구문에 대해서는 아직 지원하지 않는다고 한다. 그래서 아래와 같이 별도의 Order 클래스를 생성하여

belljun3395

[Querydsl] 사례공부04 / select에서 상수 사용하기 출처 : https://jojoldu.tistory.com/523 우선 쿼리 성능을 개선 할 수 있는 아래와 같은 방법이 있다. check for indexes work with the smallest data set required remove unnecessary fields and tables and remove calculations in your JOIN and WHERE clauses. 이 중에서도 조회하는 컬럼의 수를 초소화하는 방법을 알아보자. 이는 Entity로 조회 결과를 가져오기 보다는 Dto로 필요한 필드만 가져오길 권장하는 이유기도 한다고 한다. 조회하는 컬럼의 수를 줄

belljun3395

[Querydsl] 사례공부03 / 다이나믹 쿼리 출처 : https://jojoldu.tistory.com/394 우선 다이나믹 쿼리란? 상황에 따라 조건문을 생성하는 것을 말한다. 다이나믹 쿼리를 사용하는 방법에는 BooleanBuilder와 BooleanExpression을 활용하는 방법이 있다. 우선 BooleanBuilder를 알아보자. BooleanBuilder는 공식문서 "General usage / Creating queries / Complex predicates" 에 설명되어 있다. 위의 분류를 기반으로 생각해본다면 BooleanBuilder는 **다이나믹 쿼리를 위해 사용하기 보다는 복잡한 쿼리 조건을 위해 사용하는 것이 좋아

belljun3395

[Querydsl] 사례공부02 / Cross Join 출처 : https://jojoldu.tistory.com/533 image 사진 출처 : https://www.tutorialgateway.org/sql-joins/ 위의 사진을 보면 Cross Join을 사용하면 많은 연산이 일어날 것을 예상할 수 있을 것이다. 하지만 "Hibernate의 경우 암묵적인 조인은 Cross Join을 사용하는 경향이 있습니다."고 한다. 그러한 경우에 Cross Join을 Inner Join과

belljun3395

[Querydsl] 사례공부01 / Left Outer Join 출처 : https://jojoldu.tistory.com/342 우선 OUTER JOIN과 INNER JOIN의 차이부터 알아보자. OUTER JOIN은 조건을 만족하지 않아도 기준이 되는 테이블에 해당하는 데이터는 모두 보여준다. 반면 INNER JOIN은 조건에 만족하는 데이터만 반환되는 차이를 볼 수 있다. 즉, LEFT OUTER JOIN이 필요한 경우는 조건을 만족하지 않는 왼쪽 테이블은 모두 보여야 한다는 뜻이다. 블로그에서는 Child, Parent 클래스를 제시하고 이를 하나로 묶는 Family 클래스를 만드는 예제를 소개한다. 이때 Family 클래스는 Child를 가지지 않는 Pa

belljun3395

[Oauth2.0] Apple 로그인 구현 PR 바로가기 Controller Controller를 구현하면서 들었던 팁은 Endpoint가 API의 경계선이라 생각할 수 있다는 것이다. 특히 현재 프로젝트의 구조에는 UseCase 방식이 사용되고 있기 때문에 Controller를 추가하거나 삭제하는 등 Controller에 관한 행위를 할 때는 API의 경계선이라는 생각을 하면 기준이 조금 선명해질 것이라는 팁을 얻었다. UseCase 역할 execute 메서드를 구현하며 좋은 역할 정의가 좋은 코드를 만든다는 것을 느낀 것 같다.

belljun3395

[Oauth2.0] Apple 로그인 구현 1차 피드백 초안과 변경 사항 우선 이전 초안과 달라진 부분 부터 먼저 살펴 보면 아래와 같다. 1차 피드백 후 변경된 것은 idToken 필드가 사라진 것이다. 처음 idToken 필드를 추가한 것은 최대한 Apple 로그인 API를 사용하였을 때 받는 값을 사용하고 싶었기 때문이다. 하지만 기존 SignMemberRequest에 socialToken이라는 필드가 있었고 이를 활용하는 것이 더 좋겠다는 피드백을 받았다. 이는 클라이언트에서도 큰 공수가 드는 작업이 아니기에 충분히 받아들여 줄 것 같은데.. 이는 추후 회의에 다시 한번 협의를 부탁해야겠다. 추가된 것도 메서드도 있는데 getIdToken()이다. 없

belljun3395

[Querydsl] 공식문서03 General usage Creating queries Querydsl의 쿼리 구성에는 표현식 인수를 사용하여 쿼리 메서드를 호출하는 작업이 포함된다. 표현식은 일반적으로 도메인 모듈의 생성된 표현식 유형에서 필드에 액세스하고 메서드를 호출하여 구성된다. 코드 생성이 적용되지 않는 경우에는 일반적인 표현식 구성 방법을 대신 사용할 수 있다. Complex predicates 복잡한 boolean 표현식을 만들리면 com.querydsl.core.BooleanBuilder 클래스를 사용하면된다. 이 클래스는 Predicate를 구현하고 cascaded 형식으로 사용 가능하다. BooleanBuilder는

belljun3395

[Querydsl] 공식문서02 Tutorials Querying JPA Querydsl은 일반적으로 도메인 모델 데이터를 질의하기 위한 정적 타입의 문법으로 정의한다. JDO 그리고 JPA는 Querydsl을 위한 주요 통합 기술이다. JPA용 Querydsl은 JPQL 및 Criteria 쿼리의 대안이다. Querydsl은 Criteria 쿼리의 동적 특성과 JPA의 표현력, 그리고 이 모든 것을 타입 세이프한 방식으로 결합한다. Using query types Querydsl은 Customer라는 간단한 이름의 쿼리 유형을 Customer와 동일한 패키지로 생성한다. QCustomer는 Customer 타입에 대한 대표로

belljun3395

[Querydsl] 공식문서01 Background Querydsl은 HQL 쿼리를 타입 세이프한 방식으로 유지 관리할 필요성에 의해 탄생하였다. HQL 쿼리는 문자열 연결이 필요하므로 읽기 어려운 코드가 생성된다. 문자열을 통한 도메인 유형 및 속성에 대해 안전하지 않은 참조는 문자열 기반 HQL 구성의 문제 중 하나이다. Querydsl을 통해 도메인 모델 타입 세이프하게 변화함에 따라 소프트웨어 개발에서 안정성이라는 큰 이점이 생겼다. 그리고 도메인 변경 사항이 쿼리에 직접 반영되고 쿼리 구성 시 자동완성 기능이 쿼리 구성을 더욱 빠르고 안전하게 만들어 준다. Principles 타입 세이프가 Querydsl의 가장 중요한 요소이다. **쿼

belljun3395

[Oauth2.0] Apple 로그인 구현 초안 깃허브 바로가기 ID 토큰 주요 클레임 값 의미 iss Apple이 해당 토큰을 발급하였기에 iss 값은 https://appleid.apple.com이다. sub 주체(subject) 등록 클레임의 경우 ID 토큰의 주체를 식별한다. 이 토큰은 앱용으로 이 값은 사용자에 대한 고유 식별자(사용자 식별자)가 된다. aud 대상(audience) 등록 클레임은 ID 토큰 수신자를 식별한다. **이 토큰은 앱용으로 값은 개발자 계정의 cl

belljun3395

[Oauth2.0] Apple 로그인 구현 논의사항2 팀 전체 회의 전 백엔드 회의에서 논의한 내용과 공식 문서를 다시 한번 확인한 내용을 바탕으로 정리해보려 한다. Apple 로그인 구현 논의사항1 복기 1-1. 어떤 토큰을 받아야 할까?, 1-2. client secret 1-1 중 "refresh 토큰을 프런트로부터 로그인을 위해 받는 것이 좋을 것 같다는 생각이다."의 경우 공식 문서를 다시 살펴본 결과 잘못된 판단이었다. 공식 문서에서 제공하는 유저 검증 시퀀스 다이어그램을 다시 한번 살펴보자. <img width="441" alt="sign-in-with-apple-3_dark@2x" src="https://user-images.githubuserc

belljun3395

[Oauth2.0] Apple 로그인 구현 논의사항1 구현에 앞서 살펴본 공식 문서와 기존 코드 파악을 통해 구현 전 논의사항을 정리해보려 한다. 우선 기존 코드는 로그인 시 어떤 토큰을 받고 있는지 우선 알아보자. 우선 위의 SignMemberRequest를 통해 인증 제공자(CertificationSubject) 그리고 토큰(socialToken)에 대한 정보를 받고 있다. 그리고 해당 정보를 바탕으로 아래와 같이 멤버의 정보를 조회해 온다. ` 1-1. 어떤 토큰을 받아야 할까? 애플 로그인에서는 세 가지 토큰을 제공한다. 우선 Apple ID 서버를 통해 로그인하였을 때 받을 수 있는 ID 토큰이 있다. 그리고 이때 받은 ID

belljun3395

[Oauth2.0] Apple 로그인 공식문서 Authenticating users with Sign in with Apple 위 사진은 Apple에서 제공하는 로그인 과정에 대한 시퀀스 다이어그램이다. Authenticate the user and request information 앱 서버와 인증 세션을 초기화하고 *클라이언트 세션을 ID 토큰 그리고 nonce 값을 통해 연결

belljun3395

[Oauth2.0] 기존 코드 파악 앞서는 Oauth2.0 공식 문서를 통해 Oauth2.0에 대해서 알아보았다. 공식 문서를 통해서는 Oauth2.0가 어떤 것이고 해당 서비스를 제공하려면 어떻게 할 수 있는지 알 수 있었다. 하지만 내가 알아야 하는 것은 zzaksim에서 Oauth2.0 어떻게 사용할 것인가?이다. 그렇기에 이번에는 기존 코드를 파악해보려 한다. [Git] Three-days-server https://github.com/depromeet12th/three-days-server MemberEntity MemberEntity는 위와 같이 구성된다. 코드를 처음 보면서 익숙하지 않았던 속성은 certificationId 그리고 `Ce

belljun3395

[Oauth 2.0] 공식문서 Introduction Roles resourse owner 보호된 리소스에 대한 액세스 권한을 부여할 수 있는 엔티티다. Ex) 유저 resource server 보호된 리소스를 호스팅하는 서버로, access token을 사용하여 보호된 리소스 요청을 수락하고 응답할 수 있는 서버다. authorization server resource owner을 성공적으로 인증하고 권한을 획득한 후 액세스 토큰을 발급하는 서버이다. 이때 authorization server는 resource server와 동일한 서버이거나 분리된 엔티티일 수 있다. Ex) Apple, Google, Naver, ... **c