개념적 차이 List와 Set은 모두 JCF이다. 당연히 차이도 존재한다. List에는 중복 데이터가 포함될 수 있지만, Set에는 중복 데이터가 포함될 수 없다. List는 삽입 순서를 유지하지만 Set은 유지할 수 있고, 유지하지 않을 수도 있다. Set은 삽입 순서가 유지되지 않을 수 있으므로 인덱스 기반 액세스를 허용하지 않는다. LinkedHashSet과 같이 순서를 유지하는 Set도 있다. List와 Set 성능 비교 JMH(Java Microbench Harness)를 사용해서 List, Set 데이터 구조의 성능을 비교해 보자. 먼저 ListAndSetAddBenchmark 및 ListAndSetContainBenchmark라는 두 개의 클래스를 만든다. 그다음 List 및 Set 데이터 ..

서론 JPA와 Querydsl을 사용하면서 DTO에 관해 느낀 것이 많다. 그래서 이번 글에는 JPA와 Querydsl으로 개발을 진행할 때 고려해 보면 좋을 몇 가지에 대해 소개하겠다. Repository에서 DTO를 반환해야 하는 이유 여러분들은 Querydsl에서 DTO를 반환해야 한다는 이야기를 자주 들어보았을 것이다. 다만, Querydsl에서 DTO를 아무 의미 없이 기계적으로 반환한다면 그건 옳지 않다고 생각한다. 필자가 Querydsl에서 DTO를 반환하는 이유는 다음과 같다. 엔티티 보호 엔티티를 사용자에게 노출하면 원하지 않는 상황에서 자원의 속성이 변경될 가능성이 있다. 그리고 엔티티를 프레젠테이션 계층에 노출하는 것은 테이블 설계와 화면을 공개하는 것이나 다름없기 때문에 보안상으로도..

서론 어제 4차 데모데이가 끝남과 동시에 우아한테크코스 레벨 3이 정말 끝났다. 데모데이 1차 회고 이후로 처음 쓰는 회고인데, 변명 같지만 그동안 너무 바빴던 것 같다. 회의, 개발, 기본적인 CS 공부 등 여태까지 이렇게 열심히 해본 적이 없다. 진짜로 과장을 조금 보태서 레벨3을 시작하고 머리카락 자르러 갈 시간도 애매할 정도였다. 그리고 우리 팀의 4차 데모데이 반응도 생각보다 많이 좋아서 이번 4차 데모데이(론칭 페스티벌) 회고는 꼭 써야겠다는 생각이 들었다. 1, 2차 데모데이 레벨 3의 데모데이는 총 4번으로 나뉘어져 있다. 이 중 마지막 데모데이는 론칭 페스티벌이라고 불린다. 사실 우리 팀은 1, 2차 데모데이 이전의 기능이 정말 적었다. 사용자가 할 수 있는 경험은 기껏 해봐야 버튼 하나..

서론 개발을 하면서 Application Code와 Database Query 둘 중 어느 것을 사용하여 비즈니스 로직을 처리해야 할지 고민했던 적이 있었는가. 그런 상황이 적지 않았을 것이라고 생각한다. 필자는 꽤나 궁금해서 과연 Application Code와 Database Query 사이의 패러다임을 어느정도 감안하고 Trade Off 해야 할지, 더 나아가선 성능은 얼마나 차이가 나는지 측정해보려고 한다. 구현 내용 우선 요구 사항은 필터링 기능이 주를 이룬다. 애플리케이션 코드로 처리하든, 쿼리로 처리하든 개발자에게는 꽤나 많은 리소스가 들 것이라고 예상되기 때문이다. 필터링 요구사항은 다음과 같다. 카테고리별 복수 선택이 가능하며, 같은 카테고리에서 복수 선택 시 or 조건 발생, 다른 카테..

집사의고민 프로젝트에서 JPA를 사용하면서 알아본 Fetch Join시 유의해야 하는 부분들에 대해서 기술해보려고 합니다. 특히나 자주 사용하는 fetch join + on절에 대한 이슈를 모르거나 잘 기억이 나지 않으신다면 이해하고 넘어가는게 좋습니다. 우선 쿼리가 정상적으로 동작하는지와 어떤 쿼리가 발생하는지를 알아보기 위해 간단한 테스트 코드를 작성해보았습니다. PetFoodRepositoryImplTest @DataJpaTest @Import(QueryDslTestConfig.class) @Sql(scripts = {"classpath:truncate.sql", "classpath:data.sql"}) @AutoConfigureTestDatabase(replace = AutoConfigureTes..

JPA를 "잘" 사용하려고 Query를 개선하다 보면 한 번쯤은 만날 수밖에 없는 문제가 있습니다. 바로 MultipleBagFetchException인데요. 해당 문제는 2개 이상의 xToMany 관계에 대해서 Fetch Join을 사용할 때 발생합니다. JPA fetch join 특징은 다음과 같습니다. OneToMany, ManyToMany : 하나의 fetch join만 사용 가능(Set을 사용하는 경우 제외) ManyToOne, OneToOne : 여러개의 fetch join 사용 가능 그리고 해결할 방법들도 당연히 존재하는데요, 아래 문제는 당연하게도 fetch type(EAGER, LAZY)로 인한 N+1 문제를 해결하기 위해 발생한 문제이기 때문에 아래와 같이 해결할 수 있습니다. LAZY..

서론 서비스를 개발하는 중 다른 서비스(구글, 네이버, 카카오, 깃허브..)의 소셜 로그인이 필요하거나 또는 일부 API를 필요로 하는 상황이 많았습니다. 특히 외부 서비스에서 제공하는 데이터들을 크롤링 할 수도 있지만, 법적인 문제가 발생할 수도 있고요. 하지만 꽤나 많이 사용되는 부분임에도 불구하고, 많은 게시글 중 스프링 부트에서 소셜 로그인 또는 API 사용법을 명확하게 기술해놓은 글이 없었습니다. 그래서 이번에 아무것도 없는 제로(0)의 상태에서 Github API를 사용해서 데이터를 가져와보도록 하겠습니다. 이 글을 토대로 개념을 이해한다면 깃허브가 아닌 서비스들에서도 충분한 정보를 제공받을 수 있습니다. OAuth 내부 동작 순서 및 개발 흐름 OAuth 동작 원리는 약간 복잡합니다. Res..

우아한테크코스 레벨 3을 시작하게 되었다. 레벨 3의 진행 방식은 팀별로 2주 동안 스프린트를 진행한 뒤, 진행된 상황과 앞으로의 방향성에 대해 공유하는 데모데이를 가진다. 그래서 회고도 매주 쓰는 주간회고가 아닌, 스프린트마다 진행하는 데모데이 회고로 방식을 변경하려고 한다. 스스로도 2주 동안 진행했던 부분에 대해서 돌아볼 수 있는 시간이 될 것 같다. 팀 배정은 랜덤이었고, 프론트엔드 크루들은 대부분 처음 봤다. 첫날에 다들 어색해할까 봐 좀 걱정했는데, 역시나 어색한 분위기를 지울래야 지울 수가 없었다. 그래도 지금은 팀원끼리 많이 친해져서 분위기도 많이 풀어진 것 같다. 앞으로도 좋은 협업과 팀워크를 보여주면 좋겠다. 팀 빌딩 미션 Who are you? 우리가 만나서 처음 만난 미션은 팀 빌딩..

들어가기 전 최근 프로젝트를 진행하면서, API 명세에 대한 이야기를 많이 나누었다. API가 점점 늘어나고, 프론트와의 협업이 다가오면서 점점 API 문서화의 필요성을 실감하게 된다. API를 사용하는 곳은 정말 많다. 로컬 환경 뿐만 아니라 개발(dev), 운영(prod) 환경에서 API 요청이 잘 되는지 확인을 해야할 때도 있다. 또한 API의 스펙자체를 문서화 해놓지 않는다면, 프론트엔드 개발자와의 협업이 정말 힘들어질 것이다. 이번 글에서는 현재 진행중인 프로젝트에서 어느 부분을 고려해서 어떤 API를 어떻게 문서화, 테스트했는지 소개하겠다. 나름 개발 좀 해봤다 하면 들어봤을 만한 툴들을 기준으로 많이 알아보자. 이 글은 어떤 API 문서와 테스트 툴을 사용할지에 대한 고민이 담긴 글이기 때문..

서론 이메일 발송 기능을 개발하고 있었다. 이메일 발송은 시간이 약간 걸리는 작업인지라 클라이언트에게 응답을 곧바로 반환하지 못하는 문제가 있었다. 그래서 이메일 발송 기능은 비동기(Async)로 처리했다. 특히 인증코드에 만료 시간(ttl)이 존재해야 했기에, 이메일 발송 로직에는 인증 코드를 레디스에 저장하는 태스크도 포함되어 있었다. SecurityContext가 Authentication을 가지고 있지 않은 건에 대하여 그런데 문제는 여기서 시작되었다. AuthorityCode(인증 코드) 객체를 만드려면 현재 로그인한 멤버의 아이디가 필요했고, 현재 로그인한 멤버의 정보를 가져오는 로직은 SecurityContextHolder에서 가져온다. 내가 짠 코드기도 했고 코드 퀄리티를 더 챙기다보니 제..