개요일반적으로 클라이언트가 서버로부터 데이터를 전달받기 위해서는 HTTP 프로토콜을 이용하여 전달받습니다. 클라이언트-서버 구조에서 일반적으로 HTTP 요청은 클라이언트에서 부터 시작하게 됩니다. 그러나 몇몇 상황에서는 클라이언트가 아닌 서버에서 먼저 데이터를 전달해야 하는 경우가 있습니다. 대표적인 예시로 알림이나 실시간 채팅과 같은 사례가 있습니다. 이번 글에서는 클라이언트에게 데이터를 전송하는 4가지 방법을 알아봅니다.PollingPolling은 무엇인가?Polling 방식은 클라이언트가 먼저 HTTP Request를 서버에게 전송하여 응답을 받는 방식입니다. 이 방식은 우리가 아는 일반적인 클라이언트-서버 구조에서 HTTP 프로토콜을 이용하여 데이터를 주고받는 방식입니다.위 그림을 보면 클라이언트..

CaffeineCache는 무엇인가?CaffeineCache는 Java 기반의 고성능 캐시 라이브러리인 Caffeine을 사용하여 데이터를 메모리에 캐시하는 기능입니다. Spring Boot CaffeineCache 설정의존성 라이브러리 추가implementation 'org.springframework.boot:spring-boot-starter-cache'implementation 'com.github.ben-manes.caffeine:caffeine' Cache 설정 클래스 추가다음과 같이 설정 클래스를 구현하여 CaffeineCacheManager 스프링 빈을 정의합니다. 저 같은 경우 weatherCache 캐시를 10분으로 설정하기 위해서 다음과 같이 인스턴스 생성시 "weatherCache"..

Synchronous 방식Synchronous 방식은 스레드가 어떤 함수 작업을 수행할 때 함수 작업 안에 다른 여러가지 작은 작업들을 전체적인 관점에서 순차적으로 완료하는 방식입니다. 예를 들어 다음 그림과 같이 스레드#1 가 함수를 호출 시 함수 안에는 A,B,C I/O 작업이 존재합니다. 스레드#1이 실행하는 함수가 Synchronous 방식으로 작동한다면 전체적으로 볼때 작업들은 순차적으로 완료되어 A -> B -> C 작업 순으로 완료될 것입니다.다음 그림에서 A, C I/O 작업은 블로킹(Blocking) 방식이기 때문에 A, C 작업을 호출한 스레드는 작업이 완료될 때까지 대기하는 것을 볼수 있습니다. 반면에 B 작업은 논블로킹(Non-Blocking) 방식이기 때문에 B 작업이 끝날때까지..

@EventListener@EventListener는 스프링 이벤트 리스너를 등록하는데 사용되는 애노테이션입니다. 이 애노테이션을 적용한 메서드는 특정한 이벤트가 발생했을 때 수신하여 애노테이션을 적용한 메서드를 실행시킵니다. @EventListener 애노테이션을 적용한 리스너 메서드는 다음과 같은 특징을 가지고 있습니다. 앞으로의 설명에서 @EventListener 애노테이션을 적용한 메서드를 리스너 메서드라고 표현합니다.기본적인 동기적 처리 : 리스너 메서드는 기본적으로 이벤트를 동기적으로 처리합니다. 이벤트를 동기적으로 처리하게 되면 이벤트를 발생시킨 곳에서 이벤트를 호출하고나서 이벤트를 처리한 다음에 그 이후의 코드를 실행하게 됩니다.비동기 처리 가능 : @Async 애노테이션을 리스너 메서드에..

단일 책임 원칙(SRP, Single Responsibility Principle)단일 책임 원칙은 클래스가 하나의 책임만을 가져야 하며, 클래스는 그 책임을 완전히 캡슐화해야 한다는 원칙입니다. 하나의 책임만을 가져야 한다는 의미는 클래스가 변경할 이유가 오직 하나여야 한다는 의미입니다. 하나의 클래스가 여러 책임을 가지게 되면 각 책임이 변경될 때마다 클래스가 변경되어야 하므로 클래스가 변경에 취약해집니다.즉, 단일 책임 원칙은 클래스가 여러개의 책임을 가진 상태에서 책임이 변경될 때마다 클래스가 수정의 영향을 받게 되기 때문에 하나의 책임만을 가져야 한다는 의미입니다.다음 예제는 단일 책임 원칙이 적용되지 않은 예제입니다. User 클래스는 사용자의 데이터를 저장하면서, 동시에 데이터베이스와 통신하..

1. 문제 배경주식 포트폴리오 가상 관리 웹 애플리케이션을 구현하던 중 포트폴리오에 있는 어떤 한 종목에 등록되어 있는 매입 이력을 삭제하는 서비스를 구현하고 있었습니다. 이때 포트폴리오, 포트폴리오 종목, 매입 이력 도메인의 관계는 다음과 같습니다. 하나의 포트폴리오에는 0개 이상의 포트폴리오 종목을 가질 수 있고, 하나의 포트폴리오 종목에는 0개 이상의 매입 이력을 가질수 있습니다. 위와 같은 관계를 기반으로 매입 이력을 삭제하는 서비스 구현 자체에는 문제가 없었습니다. 그러나 매입 이력 삭제 서비스에 알람 이벤트를 추가하였을 때 문제가 발생하였습니다. 다음 코드는 매입 이력 삭제 서비스에 대한 코드입니다. 매입 이력을 삭제하기 위해서 어떤 한 매입 이력의 식별번호(purchaseHistoryId)..