25G.story

Jpa를 사용하다 보면 update를 할 때 dto에 @Valid를 활용해서 밸리데이션 체크를 하기도 애매하고 api서버로써 클라이언트와 통신을 하다 보면 리 엑트에서 undifind로 필드조차도 보내지지 않거나 null값이 들어가는 것을 서버에서 체크해줄 필요가 있다. 그런데 문제는 너무 귀찮다는 것입니다. 필드마다 null체크를 해서 setter로 더티 체킹을 유도하는 작업이 update시에 굉장히 귀찮고 피곤했습니다. 그래서 다음과 같은 util class를 만들어 봤습니다./** * update시에 null과 field가 없는 것을 체크해서 dto에 데이터가 있는부분만 entity 객체에 입혀주는 util class */public class DtoFieldEmptyChecker { publ..

지연로딩(Lazy)? 즉시로딩(Eager)? entity의 연관관계가 매핑된 상황을 가정하고 지연로딩과 즉시로딩을 간단하게 설명하면 다음과같습니다. 지연로딩 : 연관된 엔티티를 프록시로 조회한다. 프록시를 실제사용할때 (예를들어 getter호출) 초기화하면서 데이터 베이스를 조회합니다. 즉시로딩 : 연관된 엔티티를 즉시 조회합니다. 하이버네이트는 가능하면 SQL JOIN을 통해서 한번에 조회합니다. 그렇다면 어느것이 더 좋은것을까? 처음부터 연관된 엔티티를 모두 영속성 컨텍스트에 올려두는것은 현실적이지 않습니다. 산에가는데 꼭 모든 장비가 있어야하는것은 아닙니다. 때로는 물통한통만 있어도 되는것과 같습니다. 그럼 지연로딩이라고 무조건 좋은것일까? 한다면 최적화 관점에서보면 꼭 좋지만은 않습니다. 대부분의..

동시성 문제? 동시성 문제란 여러 스레드가 동시에 같은 인스턴스의 필드 값을 변경하면서 발생하는 문제를 동시성 문제라 한다. 이런 동시성 문제는 여러 쓰레드가 같은 인스턴스의 필드에 접근해야 하기 때문에 트래픽이 적은 상황에서는 확률상 잘 나타나지 않고, 트래픽이 점점 많아질 수 록 자주 발생한다. 특히 스프링 빈처럼 싱글톤 객체의 필드를 변경하며 사용할 때 이러한 동시성 문제를 조심해야 한다. 예를 들어 1명의 유저가 2개의 카드만 생성할 수 있다고 시스템에서 정의를 해놓고 테스트도 다 해봤을 때 2개 이상 절대 들어갈 일이 없을 것이라 생각했다. 그리고 서비스 첫날 서비스가 대박 나서 트래픽이 막막 몰려왔고 서버에서 스레드가 꼬여서 어떠한 유저는 카드를 2개를 초과해서 받는 일이 생길 수도 있다. 그..

지금 현재 하고 있는 프로젝트에서 페이징 처리를 해 보려고 합니다. 위 어노테이션을 사용해서 spring에서 페이징처리를 할 수 있습니다. 다음과 같이 페이징 할 설정들을 어노테이션에 달아주고 해당 객체를 Service를 하는 곳으로 던져 준다. 이때 List가 아닌 Page타입으로! Service단에서 받아주고 repository를 사용해서 호출하는 메서드도 위 상황과 코드에 맞게 수정해 준다. 이렇게만 설정해 주면 내부적으로 Spring이 알아서 페이징 처리를 해 주는데 postman으로 테스트를 해보면 다음과 같은 데이터가 넘어온다. data내부에 content안에 있다. (데이터를 뿌려줄때 이 구조로 돼 있지 않으면 데이터가 view에서 보일 수 없다.) 그리고 데이터를 보다 보면 pageable..

API라고 하는 이유는 데이터만 리턴하는 컨트롤러만 만들 것이기 때문입니다. Service에서 받는 매개변수가 int이기때문에 오브젝트 타입인 fromUserId나 toUserId를 좀 더 편하게 받아내고 내 의도대로 insert와 delete를 해주기 위해서 native쿼리를 짜서 설계했습니다 예외 처리하기 똑같은 유저가 다시 구독하기를 똑같은 유저한테 하게 되면 예외가 발생한다. API주소 시큐리티 설정하기

연관관계 먼저 구독하기 API를 구현함에 앞서서 연관관계에 대해서 분석을 해야 한다. 기본적인 공식 제1 정규형인 원자성만 지켜지면 웬만해선 다 해결된다. - 1 : N의 연관관계에서는 폴인키(FK)를 Many가 가진다. - N : N 의 관계가 됐을 때는 테이블을 쪼개서 중간 테이블을 만들어 관리한다. -그리고 이 중간 테이블과의 관계는 중간 테이블이 1, 연관 테이블이 N이 된다. 구독하기는 유저끼리 서로가 해주는 것이기 때문에 N:N의 연관관계가 나온다. 그렇기 때문에 위 공식에 맞게 중간 테이블을 만들어서 관리를 해준다. 모델 만들기 @Table을 사용해서 fromUser와 toUser가 구독을 했을 때 한 번만 db에 등록되도록 Unique제약조건을 걸었다

클라이언트가 실수로 잘못된 데이터로 서버에 요청을 할 수도 있고 서버에서도 오류창을 리턴을하는데 이 오류창 또한 보안상, 그리고 사용자 ux 불만 등등 많은 안 좋은 영향을 끼친다. 전처리는 클라이언트가 데이터를 입력을 하기도 전에 오류가 날것같은 데이터를 입력하지 못하도록 막는 것이다. 즉 꼭 서버를 건들지 않더라도 앞단에서 처리를 할 수 있는 일들을 전처리라고 한다. 전처리를 흔히 Validation체크를 한다고 한다. 후처리를 꼭 서버에서 체크를 해 봐야 알 수 있는 것 들이다. (DB를 타야만 하는 로직들) 후처리를 흔히 exceptionhendler라고 한다. 그럼 위 그림처럼 어떤 요청을 처리할 때는 클라이언트가 어떤 데이터를 요청할지 모르기 때문에 재한 사항을 줘야 한다. 위 그림에서 처럼 ..

지금 만들고 있는 web에 공부하면서 알게된 로직들을 포스팅했습니다. build패턴 모델에 Builder어노테이션 dto에 다음과 같은 함수를 만들면 user에 잘 담겨진다. @Service AuthController에서 AuthService클래스 파일을 di(의존성 주입)을 시킨다. 스프링이 IOC컨테이너에 AuthController객체를 생성해서 메모리 로드를 할 때 조건이 생성자 실행이다. 스프링 입장에서 생성자를 실행하려 하는데 생성자 매개변수로 AuthService가 들어가 있으면 AuthService를 주입해 주기 위해 IOC컨테이너를 찾아다닌다 (IOC에 없으면 생성자 실행이 안돼서 오류남). 그래서 @Service를 사용해서 AuthService를 ioc에 등록해주고 의존성 주입을 해주는 ..

저번 포스팅과 연결돼 있습니다. 저번 포스팅에서 JWT을 만들어서 응답을 해주는 것까지 했었는데 response해더에 Authorization키에 벨류에 JWT토큰이 담겨져서 응답된 것을 확인할 수 있었습니다. 그럼 이제 클라이언트가 자신의 개인정보에 접근을 하기 위해서 다시 로그인을 하는 것이 아닌 JWT을 이용해서 해당 개인정보에 접근을 하게 되면 전자서명을 통해서 개인정보에 접근할 수 있게 구현을 하면 된다. 그러기 위해선 jwt필터를 만들어야 한다. 포스트맨으로 테스트를 해보면 해당 필터를 타고 header에 Authorization키의 벨류 값을 확인해 볼 수 있다. 그럼 여기에다가 jwtheader를 넘기면 된다. 그럼 필터를 등록해서 테스트해보자 포스트맨으로테스트하면 잘 나온다 그럼 그럼 이..

이번 포스팅은 저번 포스팅과 연결돼 있습니다. com.auth0 java-jwt 3.10.2 위 dependency는 JWT토큰을 만들어주는 라이브러리이다. pom.xml에서 설정해 주기!! 어번 포스팅에서 클라이언트가 로그인 요청이 왔을 때 JWT서버에서 해야 하는 설정을 해줬다면 이제 요청이 끝나고 응답을 해줄 때 JWT서버에서 해줘야 할 설정들을 포스팅해보겠습니다. 이전 포스팅에서 attemptAuthentication(요청) 함수가 끝이 나고 successfulAuthentication함수가 순차적으로 실행되는데 successfulAuthentication함수에서 JWT토큰을 만들어서 응답을 해주기 전까지 포스팅을 했습니다. 이번 포스팅에서 응답을 하는 것을 포스팅해보겠습니다. 주석에 주요 내용들..