본문 바로가기

Spring

 (183)
[Reactive Programming] Operators - Lambda & Reactor Spring WebFlux Series - 3 이전 장 에서는 reactivestreams의 Subscriber와 Publisher를 일반 클래스에서 구현하여 Operators를 구현해보았다. 이렇게 구현하는 과정에서 많은 클래스들이 생기는 불편함과 가독성이 떨어지는 불편함이 발생하였다. 이번 장에서는 람다 표현식을 사용하여 이러한 불편함을 해결해보고 Reactor의 Flux로 우리가 만든 기능을 똑같이 구현해보고 어떠한 차이가 있는지 살펴본다. 모든 코드는 깃허브 (링크)의 테스트 코드에 있으므로 필요하다면 참고하도록 한다. 람다 표현식으로 변환 기존에 일반 클래스로 작성되어 있던 코드를 전부 람다 표현식으로 변경하였다. getLambdaPublisher는 1 ~ 10을 출력하는 Subscription..
[Reactive Programming] Operators - Basic Spring WebFlux Series - 2 이전 장 에서는 Reactive Streams의 핵심 기술인 Observer 패턴과 Pub, Sub 구조에 대해서 알아보았다. 이번 장에서는 Reactive Streams의 Operators에 대해서 알아본다. 모든 코드는 깃허브 (링크)의 테스트 코드에 있으므로 필요하다면 참고하도록 한다. 개요 이전 장에서는 java.util.concurrent.Flow.Subscriber와 java.util.concurretn.Flow.Publisher를 사용하여 간단한 Pub, Sub 구조에 대해서 알아보았다. 이번 장에서는 일반 클래스로 java.reactivestreams의 Subscriber와 java reactivestreams의 Publisher를 구현하여 중..
[Spring Cloud] Multi Module - 라이브러리 이전 장(링크)에서는 멀티 모듈 프로젝트를 구성하는 방법에 대해서 알아보았다. 실제로 현업에서 프로젝트를 진행하다보면 생각보다 복잡한 의존관계를 많이 접하게 된다. 모듈에 라이브러리를 추가하고 의존관계를 어떻게 설정해야하는지 알아보도록 한다. 예시를 위해서 이전 장에는 없던 secret-util을 추가했고 module간의 관계는 아래와 같다. secret-util은 data-redis, data-mongodb 라이브러리의 의존성을 가지고 있다. util은 secret-util을 의존하고 있으며 data-jpa 라이브러리의 의존성을 가지고 있다. users는 util 모듈에 의존하고 있으며 spring-boot-starter 라이브러리의 의존성을 가지고 있다. 각 모듈들의 build.gradle은 아래와 ..
[Spring Cloud] Multi Module - 기본 Spring Cloud는 여러 Micro Service들이 합쳐져서 하나의 서비스로 작동한다. Spring Cloud를 알아보기 전에 이번 장에서는 여러 Micro Service들을 관리하기 위한 Multi Module을 설정하는 방법에 대해서 알아본다. Multi Module로 프로젝트를 생성하는 방법은 여러가지가 있으며 필자가 주로 사용했던 방법에 대해서 기록도 할겸 작성해본다. Project Structure 이번에 필자가 구현하고자 하는 Multi Module 프로젝트의 구조는 아래와 같다. 서비스 레이어 모듈들이 공통적으로 사용하는 도메인 정보를 가지고 있는 domain 모듈이 있다. 또한 공통 함수와 같은 공통 처리 로직을 가지고 있는 util 모듈이 있다. 새로운 서비스 레이어 모듈이 추가되..
[Spring MVC] PRG 이번 장에서는 PRG(Post/Redirect/Get)에 대해서 알아본다. 글의 하단부에 참고한 강의와 공식문서의 경로를 첨부하였으므로 자세한 내용은 강의나 공식문서에서 확인한다. 모든 코드는 깃허브(링크)에 올려두었다. PRG(Post/Redirect/Get) 상품을 등록하는 폼 화면이 있고 클라이언트가 저장을 누르면 상품을 저장하는 POST API를 호출한다고 가정해본다. 이러한 구조에서 상품을 등록하고 클라이언트가 새로고침을 누른다면 지속적으로 새로운 상품이 등록될 것이다. API를 요청하는 방식이 아니라 상품 상세 화면을 렌더링하면서 폼 데이터를 전송하고 전송된 데이터를 기반으로 새로운 아이템을 생성하기 때문이다. 클라이언트가 상품을 등록했으면 더 이상 상품을 등록하지 못하게 하도록 상품 상세 화..
[Spring MVC] Handler Adapter 이전 장(링크)에서는 HTTP 메시지 컨버터가 어떠한 역할을 하는지에 대해서 알아보았다. 이번 장에서는 HTTP 메시지 컨버터가 어떠한 방식으로 작동하는지에 대해서 알아본다. 글의 하단부에 참고한 강의와 공식문서의 경로를 첨부하였으므로 자세한 내용은 강의나 공식문서에서 확인한다. 모든 코드는 깃허브(링크)에 올려두었다. RequestMapping 핸들러 어댑터 우리는 이전에 스프링 MVC가 아래의 이미지와 같은 구조로 작동하는 것을 확인하였다. 그림에는 보이지 않는 듯 하지만 핸들러 어댑터, @RequestMapping 애노테이션 기반의 핸들러를 처리하는 RequestMappingHandlerAdapter가 처리한다. ArgumentResolver 애노테이션 기반의 컨트롤러는 HttpServletRequ..
[Spring MVC] HTTP Message Converter 이번 장에서는 스프링 MVC의 메시지 컨버터에 대해서 알아본다. 글의 하단부에 참고한 강의와 공식문서의 경로를 첨부하였으므로 자세한 내용은 강의나 공식문서에서 확인한다. 모든 코드는 깃허브(링크)에 올려두었다. HTTP 메시지 컨버터 우리는 지금까지 요청을 받았을 때 HTTP 메시지를 직접 받아서 파싱한 것이 아니라 HttpServletRequest나 우리가 만든 클래스의 객체를 전달받았다. 또한 데이터를 반환할 때 HTTP 메시지를 만들어서 클라이언트에게 반환한 것이 아니라 HttpServletResponse나 우리가 만든 객체를 반환했다. 그렇다면 결국 스프링이 우리가 모르는 사이에 HTTP 메시지를 컨버팅 해준다는 것이 된다. 바로 이러한 역할을 하는 것이 스프링의 HTTP 메시지 컨버터다. 클라이..
[Spring MVC] HTTP Response 이번 장에서는 스프링 MVC의 HTTP Reponse에 대해서 알아본다. 글의 하단부에 참고한 강의와 공식문서의 경로를 첨부하였으므로 자세한 내용은 강의나 공식문서에서 확인한다. 모든 코드는 깃허브(링크)에 올려두었다. 정적 리소스 스프링 부트는 클래스패스의 다음 디렉토리에 있는 정적 리소스를 반환한다. /static /public /resources /META-INF/resources src/main/resources는 리소스를 보관하는 곳이며 클래스패스의 시작 경로다. src/main/resources/static 디렉토리에 리소스를 넣으면 스프링 부트가 정적 리소스로 서비스를 제공한다. 뷰 템플릿 우리의 서비스는 뷰 템플릿을 사용하여 HTML 파일을 생성하여 클라이언트에게 전달한다. 스프링 부트는 ..

티스토리툴바