코딩 하는 가든

Spring Webflux에서는 엔드포인트를 매핑 하는 방식으로 기존에 사용하던 어노테이션 방식(@Controller, @RestController)이외에도 Router를 이용한 함수형 방식을 지원 합니다. 이번 글 에서는 웹플럭스에서 Functional Endpoints를 어떻게 사용하는지 알아봅니다. 당연한 이야기지만 우선 웹플럭스 의존성이 필요 합니다. dependencies { implementation 'org.springframework.boot:spring-boot-starter-webflux' } Functional Endpoint를 사용 하기 위해서는 함수형 인터페이스인 RouterFunction의 구현체를 만들어서 스프링 빈으로 등록 시켜야 합니다. import org.springfra..

이번 글에선 실제로 코드를 보며 어떻게 서킷브레이커를 구현 하는지 알아 보겠습니다. 예제에 사용된 코드는 여기에서 확인 가능 합니다. 우선 Resilience4j는 Spring MVC와 Spring Webflux 환경에서 모두 사용 가능 합니다. 이번 예제에서 Webflux를 선택 한 이유는 MSA환경에서 많은 api 호출이 일어나는 환경에서는 Webflux가 많이 유리 할 수 있고, 개인적으로 느끼기에 점점 Webflux를 이용하여 개발을 많이 해 가고 있다고 생각 하기 때문 입니다. 물론 Webflux가 만능은 아니며 토비의 스프링의 저자이신 토비님 께서는 if kakao에서 MVC 환경 에서 문제 없이 애플리케이션이 돌아 간다면 굳이 Webflux를 선택 할 이유가 없다고 하셨습니다. 물론 서킷브레..

이번 글에서는 실제 구현은 없고 서킷 브레이커 패턴에 대한 설명을 합니다. 마이크로 서비스 아키텍처라는 단어가 세상에 나온지도 10년이 지났습니다. 비대해지는 모놀로틱 아키텍처에서는 여러가지 문제(유지 보수의 어려움, 오래 걸리는 컴파일 및 빌드 시간 등)가 발생 하였고, 이 문제들에서 벗어날 수 있는 방법 중에서 마이크로 서비스 라는 아키텍처가 대세로 떠오르게 되었습니다. 마이크로 서비스는 하나의 거대한 애플리케이션을 작은 기능을 하는 여러개의 애플리케이션으로 나누어 각각의 서비스가 따로 구동 되고 배포 될 수 있는 환경을 갖추게 됩니다. 마이크로 서비스 아키텍처에 대한 글은 아니므로 자세한 설명은 잘 작성된 다른 블로그의 글로 대체 합니다.[마이크로 서비스 아키텍처에 대해 잘 설명된 글] 하지만 마이..

Validation을 해보자 웹 개발을 하다 보면 서버에 들어온 요청이 서버에서 요구하는 스펙에 잘 맞게 들어왔는지 검사해야 할 필요가 있습니다. 예를 들어 회원가입을 할 때 이름은 필수로 들어와야 한다던지, 나이는 0보다 커야 한다던지 같은 것 입니다. 물론 이런 식으로 들어온 요청에 대해 검사를 할 수도 있을 것입니다. //이름이 비어있으면 exception을 던진다. if (request.getName() == null) { throw Exception; } // 나이가 0보다 작으면 exception을 던진다. if (request.getAge() < 0) { throw Exception; } 하지만 점점 커지는 웹 어플리케이션 에서 위처럼 요청에 대한 검사를 하다 보면 필드가 늘어남에 따라 코드..

블로그에서 사용한 소스코드는 https://github.com/97e57e/BLOG 에서 보실 수 있습니다. Filter 란? 사실 필터는 스프링의 독자적인 기능이 아닌 자바 서블릿에서 제공하는 기능입니다. 스프링 프레임워크에서 필터로 인증 등 다양한 작업을 하는 데 사용하니 스프링 프레임워크에서의 필터에 대해 기록 해 보고자 합니다. 아마 스프링 필터와 연관지어 검색을 하면 많이 보는 그림 중 하나 일 것입니다. 위 그림은 스프링 프레임워크에서 요청에 대한 라이프 사이클을 나타낸 그림입니다. 스프링 프레임워크는 들어온 요청이 DispatcherServlet에 의해 컨트롤러에 매핑됩니다. Filter는 요청이 DispatcherServlet에 의해 다뤄지기 전, 후에 동작합니다. 또한 Filter는 Fi..

의존성 주입을 받는 여러 가지 방법 스프링 프레임워크에서는 IoC 컨테이너를 통해 의존성 주입을 받는다는 것을 이전 글에서 알아보았습니다. 앞선 글에서는 컨테이너에서 꺼낸 배터리 빈을 Toy의 생성자로 넣어 주었습니다. 이는 의존성 주입의 한 종류라고 볼 수 있겠습니다. 스프링 프레임워크에서 의존성을 주입 받는 방법은 크게 3가지 정도가 있습니다. 1. 생성자를 통한 주입 2. Setter를 통한 주입 3. 필드를 통한 주입 각각의 방법에 차근차근 알아보겠습니다. 우선 세 방법에 대해 보기 전에 @Autowired 어노테이션에 대해 알아야 합니다. 이전 글에서 우리는 Battery Bean을 찾아 Toy 객체에 직접 넘겨주는 작업을 했습니다. 프로젝트에는 무수히 많은 Bean과 그들의 의존 관계가 있을 ..

이전 글에서 DI의 개념과 Spring에서의 DI가 어떻게 이루어지는지 살펴보았습니다. 대략 아래와 같은 구조로 이루어 진 객체들이 어떻게 의존성 주입이 일어나는지 코드를 통해 알아보겠습니다. 먼저 객체가 IoC컨테이너에 의해 관리되려면 스프링 Bean 등록을 해야 합니다. Bean으로 등록하는 방법은 xml 설정과 자바 코드로 등록하는 방법이 있는데 여기서는 자바 코드로 등록을 해보겠습니다. 다음과 같은 Battery 클래스가 있습니다. 이 Battery 클래스를 스프링 빈으로 등록해보겠습니다. (간단한 예시여서 따로 게터, 세터로 관리하지 않았습니다.) 스프링 Bean으로 등록을 하기 위해선 먼저 @Configuration 어노테이션을 가진 클래스를 하나 생성합니다. 그리고 @Bean 어노테이션을 가..

DI란? DI는 Dependency injection(의존성 주입)의 줄임 말로 어떤 객체가 다른 객체의 의존성을 제공 하는 것입니다. 어떤 장난감이 있고, 그 장난감이 작동 하기 위해서는 건전지가 필요하다고 가정 해 보겠습니다. 위의 상황을 소스 코드로 표현 하면 다음과 같을것 입니다 Toy toy = new Toy(); Battery batteryA = new Battery(); // 배터리 A를 주입 toy.setBattery(batteryA); 위처럼 Toy가 정상 작동 하기 위해서는 Battery가 필요합니다. 다시 생각해 보면 Toy는 Battery에 의존적임을 알 수 있습니다. 이 상황을 그림으로 나타내보면 다음과 같습니다. 하지만 이같은 상황에는 문제점이 있는데, A 건전지를 B 건전지로 ..