#1. 오늘의 학습 키워드 Reactive Streams의 4가지 Interface 및 Spring Webflux 의 반응형 타입 Mono 와 Flux 에 대해서 저번 post 에서 Spring WebFlux 의 개념적인 부분을 다뤘다. 다시 정리를 해보면, Spring Webflux 는 Non-Blocking, 비동기적 i/o 방식을 지원하여 높은 확장성과 성능을 자랑하는 반응형 웹 프레임워크이다. 반응형 프로그래밍, Reactive Streams 과 Reactor에 대한 개념도 다뤘었는데, 그 중 Reactive Streams의 interface 4가지와, 또 그 중 Publisher 에 해당하는 Mono와 Flux에 대해서, 좀 더 디테일하게 알아보자. #2. 공부한 내용 Reactive Strea..

#1. 오늘의 학습 키워드 Spring Webflux 에 대해서 기존에 많이 사용했던 Spring MVC 패턴은 blocking I/O 방식이다. 요청을 하고 응답이 올 때까지 대기. 그런데 몇몇 요건에 따르면 요청을 보내고 다른 일을 할 수 있도록 대기하지 않길 원한다. 예를 들면 시스템 알람과 같은 것. 실시간 어플리케이션 그러면 Non-blocking I/O 방식을 지원해주는 프레임워크는 무엇일까 #2. 공부한 내용 Spring Webflux 반응형 및 비동기적 웹 앱 개발을 지원하는 모듈 비동기 Non-Blocking I/O 방식을 제공 Reactive Streams 의 구현체 중 하나인 Reactor 에 의존하여 비동기 로직을 구성. 비동기적인 이벤트 지향 프로그래밍을 통해 얻을 수 있는 이점 ..

#1. 오늘의 학습 키워드 자바 스프링에서의 N+1 문제 에 대해서 JPA를 적용하는 과정에서, DB에 관련된 이모저모를 알아보는 과정에서 또 하나 재밌는 개념을 발견했다. 트랜잭션, MVC 패턴 등은 이미 백엔드 코드 구현 중에 체득되어있는 지식들이지만, 해당 문제에 대한 대비는 아직 백엔드 코드에서 이뤄지지 않은 것 같다. 혹은 눈치를 채지 못했거나. 또한 분명 대학교 수업 시간에 배웠던 기억이 있지만, 가물가물하기에 다시 한 번 상기시켜보도록 하자. #2. 공부한 내용 N+1 문제 연관 관계에서 발생하는 이슈 연관 관계가 설정된 Entity를 조회할 시, 조회된 데이터 개수 (N) 만큼 연관 관계가 있는 데이터를 추가로 조회하는 쿼리를 발생시키는 문제 쉽게 말하면 1번 쿼리로 조회하고자 하는데 N ..

#1. 오늘의 학습 키워드 자바 스프링에서의 Transaction 에 대해서 JPA, myBatis 동시 사용을 위한 multitransaction 을 구현하기 전 Transaction 자체에 대해서 알아보고 넘어가자. DB 수업 시간에 아주 중요한 파트를 차지했던 Transaction. 이렇게 수업시간에 배웠던 내용들을 실제 코드에서 구현하는 것은 재밌는 일이다. 트랜잭션의 구현은 복잡할 줄 알았는데, Spring에서는 굉장히 쉬운 방법을 제공하고 있었다. #2. 공부한 내용 Transaction 트랜잭션 더 이상 쪼갤 수 없는 업무 처리의 최소 단위. 예) A → B 에게 송금할 때: A는 돈을 지불하고 B는 돈을 받는 것. 이 작업들은 하나의 트랜잭션으로 쪼갤 수 없다. 트랜잭션의 특징: ACID ..

#1. 오늘의 학습 키워드 자바 스프링에서 MVC 의 개념 노드에서 자바 스프링부트로 리팩토링하는 과정에서, 개인적으로 언어 자체의 친숙도 문제 이외에는 크게 어려운 작업이 아니었던 이유는 코드 패턴이 흡사하였기 때문이다. Node Router (controller) → Service → DAO 패턴 Spring Controller → Service → Repository 패턴 여지껏 위 패턴으로 백엔드 개발을 진행해왔다 보니, 스프링을 사용하여 개발을 할 때는 MyBatis 를 사용하였기에 SQL 쿼리를 직접 구현하는 부분 제외하고는 처음엔 크게 익숙치 않은 구석은 없었다. 그럼 이쯤에서 질문을 할 수 있겠다. 이러한 패턴은 뭐라고 부르는 것일까? 이러한 패턴은 직접 사용해보니 직관적이고 구현하기 편리..

#1. 오늘의 학습 키워드 자바 스프링에서 AOP 의 개념 회사 내 백엔드 로직의 캐시를 도입하는 도중, 캐시 처리된 로직을 테스트 하던 중 redis 서버과의 연결이 안 된 상황에서 테스트가 된 적이 있었다. 그때 디비와의 연결은 문제가 없는데도, 캐시가 처리된 로직은 redis 서버만 다운되면 api 호출 시 에러가 났다. 개인적으로는 당연히 캐시 서버가 다운되면 디비로부터 정보를 가져와야 되는 게 아닌가라는 생각을 했다. 안타깝게도 그런 기능은 직접 구현해야됐던 상황이었다. 해당 기능을 구현하는 상황에서 모든 캐시 어노테이션 쪽에 디비와의 연결을 보장하는 로직을 공통적으로 적용되는 코드로 추출하고 싶었는데, 이러한 개념을 AOP 라고 한다는 것을 깨달았다. 사실 이미 공통적으로 사용되는 날짜, St..