고양이 두 잔

목차 한 달쯤 전에 올렸던 글에서, 야심 차게 MSK를 도입하겠노라고 선언을 했었다. [Cloud]Java 17 + WebFlux 환경에 AWS MSK 도입하기(1) - MSK? [Cloud]Java 17 + WebFlux 환경에 AWS MSK 도입하기(1) - MSK? 목차 Apache Kafka 아파치 카프카는 그 유명한 링크드인에서 개발해 11년에 공개한 오픈소스 메시지 브로커 프로젝트이다. Message Broker 오픈소스는 그렇다 치고 메시지 브로커라는 단어를 처음 보니 gnidinger.tistory.com 그 이후 이리 구르고 저리 구르다가 알게 된 사실은, 로컬 환경에서 MSK로 접근하는 건 불가능한 것은 아니지만 쉽지 않다는 것. 가장 쉽게 MSK에 접근하는 방법은 같은 VPC안에 EC..

[WebFlux]자주 사용하는 연산자 정리(1) [WebFlux]자주 사용하는 연산자 정리(2) - buffer [WebFlux]자주 사용하는 연산자 정리(3), 그리고 [WebFlux]자주 사용하는 연산자 정리(4) + 목차 마지막으로 연산자를 정리한 게 벌써 거의 세 달 전이다. 회사에 들어와 웹플럭스로 개발을 하며 정리하고 싶은 건 산더미 같았지만 다른 공부할 것이 너무 많고 바쁜 데다가 프로젝트까지 겹쳐 전혀 정리를 하지 못했다. 그래서 오랜만에 돌아온 연산자 정리 시간. 웹플럭스 연산자 사전이라도 있으면 좋겠다. defer() defer 연산자는 Mono와 Flux 둘 모두에서 사용가능한 연산자이다. 이 연산자는 리액티브 프로그래밍에서 지연 평가(Lazy Evaluation)를 수행하기 위한 연..

목차 Apache Kafka 아파치 카프카는 그 유명한 링크드인에서 개발해 11년에 공개한 오픈소스 메시지 브로커 프로젝트이다. Message Broker 오픈소스는 그렇다 치고 메시지 브로커라는 단어를 처음 보니 정리하고 지나가자면, 브로커라는 단어 뜻 그대로 프로그램 간의 메시지를 전달하는 중개인 역할을 하는 앱이라고 생각하면 된다. 출처: https://www.g2.com/articles/message-broker 특히 카프카는 복잡한 시스템에서 컴포넌트 간의 통신을 담당하며, 이 과정에서 컴포넌트들이 직접 통신하는 대신 카프카를 통해 메시지, 즉 요청과 응답을 주고받는다. 이를 통해 시스템은 컴포넌트 사이의 결합도를 낮추는 동시에, 확장성과 유연성을 동시에 높일 수 있게 된다. Key Featur..

[WebFlux]자주 사용하는 연산자 정리(1) [WebFlux]자주 사용하는 연산자 정리(2) - buffer [WebFlux]자주 사용하는 연산자 정리(3), 그리고 목차 WebFlux Operators [WebFlux]자주 사용하는 연산자 정리(1) [WebFlux]자주 사용하는 연산자 정리(2) - buffer [WebFlux]자주 사용하는 연산자 정리(3), 그리고 글의 순서는 연산자의 중요도나 로직의 흐름과는 아무 관련이 없다. 그저 내가 코드를 읽다가 마주친 순서를 마구잡이로 적어놓은 메모장에 근거할 뿐. 글 제목에 '+'가 붙어있는 이유는 연산자가 아니더라도 처음 봤거나 알아야 할 것 같은 경우라 판단이 들면 이 글에 같이 추가해 버렸기 때문이다. 굳이 연산자와 그 외 클래스를 나누어야 할..

[WebFlux]자주 사용하는 연산자 정리(1) [WebFlux]자주 사용하는 연산자 정리(2) - buffer [WebFlux]자주 사용하는 연산자 정리(4) + 목차 flatMapMany() Mono를 받아 Flux를 반환하는 연산자이다. 하나의 값에서 시작해 여러 개의 값을 리턴한다는 점에서 reduce()와 반대되는 기능을 하는 것처럼 보이기도 한다. 사용 예시는 아래와 같다. public class Example { public static void main(String[] args) { Mono numbers = Mono.just(3); Flux result = numbers.flatMapMany(num -> Flux.just( num, num + 2, num * 2, num * num ) )..

목차 한동안 WebFlux로 개발을 하면서 제목에 쓰인 것들에 대해 몸으로 배울 수 있었다. 그러나 여전히 막연한 부분이 있고, 비동기와 논블로킹이 헷갈릴 때도 있어서 오랜만에 최대한 간결하게 핵심만 정리하고 넘어가기. Synchronous execution, Asynchronous 요약부터 하고 들어가자면, 둘의 차이는 결괏값 리턴 순서가 요청 순서를 지키느냐(동기) 아니냐(비동기) 하는 것이다. 조금 덜 직관적으로 말하자면 둘의 차이는 호출된 요청의 결과를 어느 쪽에서 처리하느냐 하는 데 있다고 볼 수도 있다. 결과는 당연히 호출한 쪽에서 신경 써야 하는 거 아닌가? 싶지만 아니다. 위 그림을 보면 알 수 있듯이, 동기 처리의 경우 B메서드를 호출한 A가 작업 완료 여부를 처리한다. 따라서 여러 작업..

처음 써보는 웹플럭스에 처음 써보는 리액티브 몽고+레디스를 사용해 마이그레이션을 시도할 때 가장 먼저 당황한 부분이 바로 이 부분이다. MVC패턴에선 당연히, 아주 손쉽게 이루어졌던 이 함수형 엔드포인트를 사용하는 웹플럭스에서는 작동하지 않았던 것. 물론 내 경험의 산물이라 100% 확신할 수는 없지만, 여태까지 내가 알기론 함수형 엔드포인트에서 기존의 방식대로 간편하게 유효성 검증을 하는 방법은 없다, 혹은 다른 라이브러리를 불러서 사용해야 한다. 아이 그럼 어쩌라고? 에 대해 헤매면서 얻은 답을 정리한다. Validator 결론부터 말하자면, 웹플럭스에서는 검증이 필요한 클래스(DTO와 같은)마다 개별 검증 클래스를 구현해야 한다. 따라서 CRUD에 따라 검증 로직이 다르고 복잡하다면, 패키지 안에 ..

목차 웹플럭스로 개발을 하는 방법은 크게 두 가지로 나뉜다. 기존의 엔드포인트 패턴 활용 함수형 엔드포인트 사용 물론 두 가지 방법 다 비동기 처리를 구현할 수 있고, 초심자 입장에선 뭐가 더 나은 방식이라고 말할 수 없다. 그래도 이왕 웹플럭스를 사용하는 김에 함수형 엔드포인트를 적용해 보자! 하고 한 달 정도 삽질을 한 뒤에 느낀 점을 정리하기 위해 이 글을 적는다. 결론부터 말하면 일단 적응하고 나면 일반 엔드포인트보다 훨씬 직관적인 코드 작성이 가능하다. Router 함수형 엔드포인트를 사용하려면 라우터 클래스의 작성이 필수적이다. 라우터는 이름 그대로 매핑하는 역할을 하는데, 여기서 매핑이란 URL 패턴과 핸들러메서드의 매핑을 가리킨다. 즉 사용자의 요청이 라우터를 거쳐 해당 엔드포인트의 핸들러..

JWT를 이용한 로그인 자체는 쉽게 구현했으나, 로그인 한 정보를 핸들러메서드에서 불러오는 방법을 몰라 며칠을 고민했던 기억이 있다. 어쨌거나 결국 찾긴 찾았고, 더 좋은 방법을 지금도 틈틈히 찾고 있지만 아직까진 발견할 수가 없다. 로그인 구현은 시간이 나면 정리하기로 하고, 웹플럭스에서 사용자 정보를 가져오는 코드는 아래와 같다. public Mono getCurrentUser() { return ReactiveSecurityContextHolder.getContext() .map(SecurityContext::getAuthentication) .map(Principal::getName) .switchIfEmpty(Mono.error(new UserNotFoundException())) .flatMa..

목차 앞으로 쓰게 될 모든 웹플럭스 실습 글에 굳이 강조하겠지만, 아래의 코드는 그야말로 내 마음대로 공식문서와 각종 레퍼런스를 짜깁기해서 만들어낸 결과물이다. 당연히 Best Choice와는 거리가 멀 수밖에 없지만, 이거라도 잊지 않으려고 하나씩 적어본다. 우선 리액티브 몽고 템플릿에 대한 소개로 시작하자. Reactive Mongo Template 아직 한 번도 적지 않은 것 같은데, 리액티브 몽고디비를 사용하려면 그래들에 아래와 같은 의존성을 추가해야 한다. implementation 'org.springframework.boot:spring-boot-starter-data-mongodb-reactive' 우선 여기서 알아갈 수 있는 사실은, 리액티브 몽고디비 역시 스프링 데이터의 일원이라는 사실..