Spring WebFlux가 큰 틀에서 어떤 방식으로 동작하는지 알아보고자 한다. Spring MVC 의 경우에는 DispatcherServlet 기반으로 요청을 받아 뒷단의 처리가 이루어진다. Spring WebFlux의 경우에도 DispatcherServlet과 같이 front controller 의 역할을 해주는 친구가 존재한다. 일단 결론부터 말하면 대충 분석해본 것들을 요약했을 때 아래 같은 그림이다. (간단하게 표현해서 생략이 많을 수 있다.) DispatcherHandler (WebHandler의 구현체) DispatcherHandler 는 WebHandler 인터페이스의 구현체로 Spring Webflux에서의 front controller 역할을 한다. 아래는 DispatchHandler..

Spring Data 란? Spring 프레임워크의 하위 프로젝트 중 하나로 모델을 기반으로 다양한 데이터 접근 기술을 지원한다. Repository 인터페이스를 통해 객체 매핑을 추상화 형태로 지원하기 때문에 좀 더 쉽게 데이터에 접근 및 사용이 가능하다. Main Module Spring Data Commons : 모든 Spring Module을 뒷받침하는 핵심 Spring 개념 CrudRepository, PagingAndSortingRepository Spring Data JDBC : spring-jdbc에 대한 Spring Data 추상화를 제공하는 모듈 CrudRepository를 구현하는 SimpleJdbcRepository 클래스 Spring Data JPA : JPA를 위한 스프링 데이터..

MDC 란? MDC 는 Mapped Diagnostic Context 의 약자로 key와 value를 저장하는 Map 형식으로 slf4j, logback, log4j 등 로깅 프레임워크에서 필요한 정보를 저장하고 싶을 때 사용한다. ThreadLocal 을 기반으로 컨텍스트 정보를 저장하기 때문에 멀티 쓰레드 환경에서 유용하게 사용이 가능하다. (멀티 쓰레드 환경에서는 로그 메시지에 각 쓰레드에 대한 로그가 섞이기 때문) 요청이 어떤 사용자로부터 들어온 것인지 저장하거나 요청별로 식별자를 만들어 특정 요청에 대한 로그만 추적할 수 있다. 참고: 로그시스템 #4-MDC를 이용하여 쓰레드별로 로그 분류하기 MDC 적용하기 Spring Framework를 사용하고 있다면 AOP를 이용해 쉽게 적용이 가능하다...

Programming Models 1. Annotated Controller Spring MVC에서 사용하던 방식을 WebFlux 에서 그대로 사용이 가능하다. @RequestMapping, @PathVariable, @RestController, @GetMapping 등 2. Functional Endpoints Java8의 lambda style routing과 handling 방식 (함수형 모델) RouterFunction: 어떤 핸들러가 요청을 처리할 지 결정 HandlerFunction: 바인딩 부터 HTTP 요청 응답처리 ServerRequest와 ServerResponse로 응답을 하며 서블릿 제약이 없고 리액티브 타입을 지원한다. Spring WebFlux의 경우 다음과 같은 2개의 개발 ..

Spring Actuator란? 애플리케이션의 상태를 모니터링, Metric 수집을 위한 Http Endpoint를 제공해주는 모듈이다. (요약하면 애플리케이션의 상태를 전체적으로 알 수 있도록 도와주는 기능!) // https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-actuator implementation 'org.springframework.boot:spring-boot-starter-actuator:3.0.1' 다음과 같이 dependency만 추가해주면 사용이 가능하다. Ex) spring 설정 yaml 파일에 아래와 같이 어떤 endpoint들을 포함할지 명시해주면 된다. management: endp..

기존에 하던 것 처럼 http.requestMatchers("/h2-console/**").permitAll() 로 h2-console에 대한 접근을 허용해주려고 했지만 계속해서 403(forbidden) 에러가 났다. 구글링을 통해 해결한 결과 @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests() .requestMatchers("/users/**").permitAll() .and() .authorizeHttpRequests(auth -> auth .requestMatchers(AntPathRequestMatcher.antMatcher("/h2-console/..

Kotest에는 전후처리를 위한 여러개의 인터페이스 함수들이 존재하는데 대표적으로 @beforeSpec @beforeContainer @beforeTest @beforeEach .. 등이 존재한다. 테스트 생명주기에 어떠한 전후 세팅을 해주어야 하는경우 사용한다. 예를 들면 테스트 컨테이너 실행, 데이터 삽입 등등! 어떤 function을 사용하냐에 따라 테스트 과정과 결과가 달라질 수 있기 때문에 필요에 맞게 골라 사용하면 될 것 같다. Function Description @beforeEach 각 testcase 마다 호출된다. @beforeTest 각 testcase 마다 호출된다. @beforeContainer 걱 context마다 호출된다. @beforeSpec 하나의 테스트 spec (FunS..

연관된 엔티티에 대해 지연로딩으로 설정을 해주면 일반적인 조회 쿼리에서는 연관된 엔티티까지 조회해오지 않고 연관된 엔티티는 가짜 프록시 객체로 설정이 된다. 이렇게 되면 연관된 엔티티의 값에 접근해야할 때 데이터마다 쿼리가 한번씩 더 실행되어 N+1 문제가 발생하게 된다. 이를 해결하기 위한 것이 Fetch Join 이다. 연관된 것들을 한번에 다 가져오는 것으로 가짜 프록시 객체가 아니라 연관된 엔티티까지 실제 값으로 전부 채워준다. (즉, 조인만 하는 것이 아니라 select 절에 있는 값들도 전부 넣어주는 것) EntityGraph - data jpa를 사용할 경우 fetch join 을 jpql 없이 간단하게 사용하는 방법이다. JpaRepository를 상속받는 repository가 있을 때 @..

Typically, stubbing argument mismatch indicates user mistake when writing tests. Mockito fails early so that you can debug potential problem easily. However, there are legit scenarios when this exception generates false negative signal: - stubbing the same method multiple times using 'given().will()' or 'when().then()' API Please use 'will().given()' or 'doReturn().when()' API for stubbing. - st..

detached entity passed to persist 관련 에러가 뜨는 경우 이미 생성되어 있는 객체의 부분에 다시 한번 더 설정을 해주거나 저장을 해주려고 할 때 생기는 것! 즉, 엔티티 종속성 문제거나 객체 생성할 때 문제가 있는 것 !! 예를 들면 1) id 필드에 @GeneratedValue를 사용해서 자동으로 만들어지도록 해놓고 테스트할 때 id 값을 설정해줬다던가.. 2) 엔티티들의 연관관계가 존재할 때 클래스A 의 a1, a2 에 연관된 클래스B에 b1 이 있을 때 (a1 + b1) 저장하고 (a2 + b1) 저장되어 중복으로 저장되는 경우 (이런 경우에는 cascade 관련해서 설정을 제거해주던가 독립적으로 실행되게 해주면 될 듯!)

JWT란? Json Web Token 의 약자로 json 객체에 사용자의 일부 정보를 담는다. 세션과 달리 클라이언트가 서버가 준 토큰을 가지고 있다가 헤더에 실어서 보내는 방식 (단순하게 말하면 토큰 기반 인증 방식) Header : Signature를 해싱하기 위한 알고리즘 정보들 담겨있음 Payload : 서버와 클라이언트가 주고받는, 시스템에서 실제로 사용될 정보들에 대한 내용 담고 있음 Signature : 토큰의 유효성 검증을 위한 문자열 (유효한 토큰인지 검증) 세션은? 서버의 메모리에 인증한 유저의 정보를 저장해둠! 그리고 서버와 클라이언트가 인증정보를 가지고 통신하는 방식 stateful service란 세션 정보를 서버에 저장하고 세션 상태에 따른 응답을 주는 서비스! -> EX) 세션..

** 기본적으로 security 설정과 swagger 설정이 다 되어있음을 바탕으로 한다. SwaggerConfig.java @Configuration @EnableSwagger2 public class SwaggerConfig { @Bean public Docket api() { return new Docket(DocumentationType.SWAGGER_2) .useDefaultResponseMessages(false) .select() .apis(RequestHandlerSelectors.basePackage("com.cherishpet.backend")) .paths(PathSelectors.ant("/api/**")) .build() .apiInfo(metaData()) .securityCon..