개발자는 기록이 답이다

프로젝트를 진행하면서 상태코드를 반환할때 ResponseEntity와 @ResponseStatus 를 동시에 사용했었는데요. 아래와 같이 PR 리뷰를 받게 되어 자세히 알아보고자 포스팅하려고 합니다. 일반적으로 REST API를 만들 때 @RestController를 사용하여 JSON 형식으로 응답을 반환합니다. 이는 프론트엔드와 API가 연동될 때 상태 코드를 전달해야 하는 이유가 있습니다. 프론트엔드는 서버로부터 받은 상태 코드를 기반으로 다음 동작을 결정하기 때문입니다. 이러한 상황에서는 ResponseEntity나 @ResponseStatus를 사용하여 상태 코드를 반환할 수 있습니다. 이 둘 간의 차이를 이해하기 위해 먼저 각각의 개념을 살펴보고, 동시에 사용할때 어떤 문제가 발생하는지 알아보겠..

마이페이지에서 유저가 발급받은 쿠폰 이력을 조회하는 기능을 구현해야 했습니다 해당 기능 구현 시 쿼리 최적화를 고려했던 과정을 포스팅 해보고자 합니다. 📌 무조건 쿼리 속도가 빠르면 되는 걸까? 쿼리 최적화를 고려한 기능을 만들면서 궁금한 점이 생겼습니다. 어떤걸 기준으로 쿼리 최적화가 됐다 라고 하는 것일까? 레코드 건수가 제일 작은게 드라이빙 테이블로 되는 것 같은데, 각 테이블 당 레코드 건수를 몇개를 넣어야 하는 것일까? 실행 계획을 보면서 인덱스를 이것저것 설정해보니, 속도는 빠르지만 ALL인 상황, 속도는 느리지만 index인 상황, filtered가 높아지거나 낮아지거나 등 여러 가지 상황에 따라 실행 계획이 바뀌는 것 같습니다. 그래서 처음에는 어떤 걸 기준으로 쿼리가 최적화되었다라고 봐야..

Baeldung에 올라온 포스팅을 한글로 번역한 글입니다. Java의 throw 키워드는 사용자 정의 예외 혹은 내장 예외를 명시적으로 발생시키는데 사용됩니다. 하지만 때로는 catch블록에서 동일한 예외를 다시 발생시켜야 할때도 있고, 이로 인해 예외가 다시 발생합니다. 1. Rethrowing Exceptions 때로는 예외를 더 높은 수준으로 전파하기 전에 몇 가지 수행해야 할 것이 있습니다. 예를 들어 DB트랜잭션을 롤백하거나 예외를 기록하거나 이메일을 보낼 수 있습니다. catch블록에서 이러한 활동을 수행하고 예외를 다시 발생시킬 수 있습니다. 이러한 방식으로 시스템에서 예외가 발생했음을 상위레벨에 알립니다. 예시를 들어보면, 아래 코드에서는 동일한 예외가 다시 발생합니다. 그리고 오류 메세지..

프로젝트에서 비동기 쿠폰 발행시 유저에게 발급 완료 알림을 주는 기능을 구현했습니다. 실시간 알림 기능은 여러가지 방식으로 구현이 가능한데 그 중에서 제가 왜 SSE를 선택했는지 얘기해보고자 합니다. 비동기식으로 MQ를 활용해서 쿠폰 발급 기능을 구현하려고 하다보니, 쿠폰 발급이 즉시 이루어지지 않았습니다. 따라서 유저가 쿠폰을 발급받았는지 알림을 받으면 사용자 경험이 개선될 것이라 판단했습니다. 실시간 알림 방식에는 5가지 방법이 있습니다. polling Long polling Socket SSE FCM 1. Polling 가장 기본적인 데이터 처리 방식으로, 클라이언트가 특정 주기로 http request를 서버로 계속 날려서 이벤트 내용을 전달받습니다. 특징 가장 쉬운 방법이지만, 클라이언트가 계속..