생각하기
API 요청은 상품의 만료 기간이 "12:00"라고 가정 했을 때 "11:59 59.959"에 들어온 요청은 상품을 사용할 수 있도록 해주어야 하는 것일까? 사용자 입장에서는 정상적으로 상품 사용이 가능해야 한다. 회사 서비스에서는 저와 같은 상황을 연출하고 테스트 했을 때 상품을 사용할 수 없었다. 이유는 비교해야 하는 현재 시간을 API 호출 시점이 아닌 유효성을 검사할 때 생성해서 사용을 하고 있었기 때문이다. 유효성으로 가는 과정에서 "12:00"가 지나버린 것이다.
사용자를 중점으로 이루어져야 하는 것이 서비스이기에 위와 같은 경우 상품을 사용할 수 있도록 해주는 것이 맞는 것 같다. 그래서 문제가 되는 기능이라고 생각을 해 수정 요청을 했다.
생성 시점은 언제로?
생성 시점은 언제로 해야할까? 고민해본 결과 가장 정확하게 처리를 하려면, API를 호출하는 곳에서 호출 시점에 시간 값을 생성해서 보내주는 것이었다. 회사로 치면 앱에서 만들어서 API 요청을 해야하는 것이다. 하지만 회사에서는 앱은 심사 과정이 필요해 즉각적으로 적용하기가 어려운 상황이라고 판단을 했다. API 호출해서 서버로 들어온 시점에 만들어서 처리를 보기로 했다. 일반적인 네트워크 상황이면 API 호출 시점과 서버에 도달하는 시간이 큰 차이가 없다라고 가정을 했기 때문이다.
시간 저장하고 사용하기
백엔드에서 API 호출이 된 시점에서 시간 값을 생성하기 위해 Java Spring Filter 단을 사용하기로 했다. Filter에서 시간을 생성하고, 요청 끝날 때까지 사용할 수 있도록 ThreadLocal을 사용을 했다.
시간 값을 관리하는 클래스
public class ReqeustTimeUtil {
private static final ThreadLocal<LocalDateTime> requestTime = new ThreadLocal<>();
public static void setRequestTime(LocalDateTime time) {
requestTime.set(time);
}
public static LocalDateTime getRequestTime() {
return requestTime.get();
}
public static void clear() {
requestTime.remove();
}
}
Filter에 로직 적용
try{
LocalDateTime now = LocalDateTime.now();
RequestTimeUtil.setRequestTime(now);
} finally {
RequestTimeUtil.clear();
}
유효성 검사에서 사용하기
LocalDateTime apiCallTime = reqeustTimeUtil.getReqeustTime();
validateGoodsExpire(goodsExpireTime, apiCallTime)
결과
테스트 해 볼 수 있는 케이스 들에 대해서 기존에 있었던 문제는 발생하지 않았다. 하지만 위에서 언급했듯이 정확한 시간 값을 받기 위해 앱에서 요청을 보내줘야 할 것이다. 이후에 논의를 통해서 어떤 방식을 채택할 것인지 따라 추가 작업이 들어가면 될 것 같다.
'프로젝트' 카테고리의 다른 글
코틀린 Data Class와 Mybatis 같이 사용할 때 주의점 (1) | 2025.03.04 |
---|---|
Redis Scan으로 Key 삭제하기 (0) | 2024.12.07 |
불변 객체와 깊은 복사를 사용 해야 하는 이유 (0) | 2024.10.28 |
Github PR을 했을 때 Slack 알림 보내기 (0) | 2024.10.21 |
재화(크레딧, 투표권 등) 로그 데이터 정리 작업 (0) | 2024.09.02 |