Spring-boot

소개 배경 현재 진행중인 프로젝트에서 평소와 같이 필요한 기능을 구현하기 위해 Service Layer에서 CRUD를 제작하던 도중 항상 고정적으로 Import하게 되는 어노테이션들이 갑자기 거슬렸다. 설계되는 도메인에 따라 Service 클래스는 그만큼 증가되게 되는데 그에 따라 impot 문이 기하급수적으로 늘어나 클래스의 로딩시간이 지연되거나 코드의 전체적인 가독성이 떨어진다고 생각했다. 그래서 이를 줄이기위해 CustomAnnotation을 사용하는 방법을 생각했다. 기술 적용 CustomAnnotation을 제작하는 것은 생각보다 간단하다. 우선 @interface 타입의 클래스를 하나 생성한다. Custom Annotation(사용자 정의) 타입의 클래스를 생성하기 위해 사용된다. public..

최근 프로젝트를 진행하는 과정에서 겪었던 사소한 이슈인데 JPA의 기본이기도 하면서 절대 실수를 범하면 안되는 부분이기에 소개하려한다. 엔티티의 생명주기 우선 JPA에서는 엔티티의 생명주기를 크게 4가지로 관리한다. 비영속(new/transient) 영속(managed) 준영속(detached) 삭제(remove) 비영속 비영속 상태는 객체를 새로 생성하였을 때 시점으로 영속성 컨텍스트에 의해 관리되지 않는 상태를 뜻한다. JPA와는 관계없이 객체만 생성한 상태를 말한다. Timer timer=new Timer(1L,"11:06:48"); 영속상태가 아니므로 1차캐시에 포함되지 않으며, 변경감지등의 기능이 적용되지 않는다. 영속 영속성 컨테스트에 의해 관리되는 상태. 생성한 객체를EntityManager..

소개 배경 우리는 흔히 Spring 프로젝트를 공인 IP상에 띄우기 위해 EC2와 같은 환경을 이용하며 DB 또한 RDB를 사용한다는 가정하에 RDS와 같은 서비스를 이용하여 DB를 네트워크 상에 배포하게된다. 이때 네트워크를 통해 데이터베이스에 접근하는 시간 비용은 애플리케이션 서버에서 내부 메모리에 접근하는 시간 비용보다 수만에서 수십만 배 이상 비싸다. 따라서 조회한 데이터를 메모리에 캐시 해서 데이터베이스 접근 횟수를 줄이면 애플리케이션 성능을 획기적으로 개선할 수 있다. 1차캐시와 2차 캐시 우리는 Spring Data Jpa와 같은 작업을 통해 DB에 쿼리 작업을 수행할 경우 모든 작업은 영속성 컨텍스트에 엔티티를 저장하게된다. 이때 영속성 컨테스트 내부에 엔티티를 영구적으로 보관하는 장소를 ..

작성배경 이번 프로젝트에서 OAuth2.0을 사용하여 인가처리를 사용하였는데 Github의 경우 OAuth Developer 문서를 읽어보면 SpringSecurity에서 제공하는 OAuth API를 사용하기 보다는 직접 API를 호출하는 방식을 권고하고 있다. 물론 방식의 차이일뿐 같은 결과를 가져오지만 인가처리는 SpringSecurity의 Oauth2.0을 사용하였으나 logout을 구현하기 위해 외부 API를 호출해야하는 작업이 필요해졌다. Github의 logout주소는 아래와 같다 https://api.github.com/applications/{client_id}/token 이 API로 요청을 보내면서 Header에는 client_id와 client_secret을 Body에는 authToke..

현재 진행중인 프로젝트에서 인가 보안전략으로 JWT Token을 사용하던 도중만나게 된 에러로 분석을 해보자면 JWT 보안에 사용되는 서명이 일치하지 않을 경우에 발생하는 에러이다. 에러 분석 여기서 서명이 일치하지 않다는 것이 어떤 뜻인지 부터 설명을 해보자. 우리가 흔히알고 있는 JWT의 구조를 생각해보자 아마 위의 사진과 비슷한 구조를 많이 보았을 것이다. 여기서 서명부분은 우리가 SecretKey, 즉 암호화 키값을 가지고 HMA512 또는 BASE 64와 같은 알고리즘을 사용하여 암호화를 진행시킨다. 이는 서버의 인가 자원인 Token을 암호화하기 위해 반드시 거쳐야하는 작업으로 메세지가 조작되지 않았다는 무결성을 보장하기 위한 작업이기도 하다. 그렇기에 해당 에러를 맞닥뜨렸을 경우 이 서명 쪽..

N+1 이슈는 어떤 것일까? 개발자는 요청이 1개로 처리되길 원한 상태로 비즈니스 로직을 구현하였지만, N개의 추가 Query가 발생하게 되는 현상 연관 관계를 Mapping하는 과정에서 fetch Type을 Lazy 와 Eager 전략에서 각각 발생한다. Eager Loding에서 N+1이 발생하는 이유 즉시 로딩에서 이러한 이슈가 발생되는 이유는 JPQL 을 사용하는 경우 전체 조회를 했을 때 영속성 콘테스트가 아니라 데이터 베이스에서 데이터를 직접적으로 조회한 후 로딩전략이 동작하기 때문이다. 예를 들어 A라는 Entity가 존재하고, 그 A에 종속적인 엔티티의 데이터가 10개 존재한다고 하였을 때 A를 조회할경우 A에 종속적안 데이터들이 조회 row 만큼 쿼리가 호출된다. 정리하자면 , JPQL은..

스프링부트를 자바 Language로 사용해오던 나에게 Lombok 라이브러리의 @Getter @Setter 어노테이션은 혁신과도 같은 것이었다. 그 귀찮은 Getter와 Setter를 직접구현하지 않고도 어노테이션 하나만으로 구현이 가능하기 때문이다. 하지만 프로젝트의 크기가 커져갈 수록 어노테이션이 남발되게 되고 필요없는 상황에서도 습관적으로 사용하기 때문에 이렇게 무차별적 사용을 해도 괜찮은가? 에 대한 의문이 들게되어 해당 글을 작성하게 되었다. Setter는 왜 지양되어야 하는가? Entity에서의 경우에는 DB와 직접적으로 연결되는 클래스로 DB에 값이 직접적으로 수정이 되는 로직은 안정적이지 못하다. 유지보수적 측면에서 값을 변경한 의도를 파악하기 어려워져 코드를 역추적하여 해당 값의 변경의의..

아래 설명되는 코드는 해당링크의 Git 에 있다. 현재 스프링부트 개발자들이 사용하는 패키지 구조는 크게 레이어 계층형 구조와 도메인형 2가지의 유형이 존재한다고 생각한다. 각 유형에 대한 나의 개인적인 BP를 얘기하려고한다. 계층형 나는 이전까지의 모든 프로젝트에서 계층형 구조의 패키지관리를 시행해 왔었다. └── src ├── main │ ├── java │ │ └── learn │ │ └── jwt │ │ └── andsocket │ │ ├── AndSocketApplication.java │ │ ├── config │ │ ├── controller │ │ ├── exception │ │ ├── filter │ │ ├── handler │ │ ├── model │ │ ├── principal │ │..