안녕하세요. 백엔드팀 손유진입니다.테이블링은 테이블에서 QR/NFC 를 태그하여 메뉴를 확인하고 주문할 수 있는 테이블오더 서비스를 제공하고 있습니다. 테이블오더로 주문한 내역은 POS 에 자동으로 전달되어 매장은 관리 리소스를 효율적으로 활용할 수 있는 장점을 가지고 있습니다.여기서 우리는 POS Agent 와 테이블링 내부 서버의 안정적인 통신을 위해 MQTT 적용을 고민하고 있습니다. 이에 따라 이 글에서는 MQTT 에 대해 학습한 내용과 테스트 과정을 공유하고자 합니다.MQTT 는 낮은 대역폭과 리소스가 제한된 환경에서 안정적으로 통신을 할 수 있는 경량 메시지 프로토콜입니다. 작은 데이터 패킷을 전송하여 효율성이 높고 오버헤드와 전력 소비가 작아 IoT와 M2M 통신에 많이 사용되고 있습니다.MQTT 의 이해Publisher/Subscriber 모델MQTT 는 클라이언트와 브로커로 구성되어 있으며, 클라이언트가 Topic 에 메시지를 발행하면 해당 Topic 을 구독 중인 클라이언트가 메시지를 수신할 수 있습니다.클라이언트는 여러 Topic 을 구독할 수 있고 모든 클라이언트가 발행과 구독을 할 수 있어 Publisher 와 Subscriber 의 구분이 따로 없습니다.Publish-Subscribe 방식Topic은 브로커가 연결된 클라이언트에 대한 메시지를 필터링 하기 위해 사용되며 슬래시(/) 로 구분하는 계층적인 구조를 가집니다.Topic 예시 (출처: https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/)QoS 제어다양한 QoS(Quality Of Service) 레벨을 지원하여 메시지 전달의 보장을 제어할 수 있습니다.QoS 0Fire and forget.Publisher 가 메시지를 보내고, 이상이 없으면 바로 완료.더 이상 관여하지 않음.QoS 1At least once.Publisher 가 메시지를 보내면 Subscriber 가 메시지 확인 응답할 때까지 여러 번 전송.메시지 중복이 허용되는 상황에서 사용.QoS 2Exactly once.가장 안정적인 메시지 전송이 필요할 때 사용.메시지가 브로커에 정확히 한 번 전달됨.지속성과 안정성영구 세션(Persistent Session)을 통해 클라이언트에 전송되었지만 수신이 확인되지 않은 메시지를 다시 전달할 수 있습니다.영구 세션을 활성화 하기 위해서는 MQTT 버전에 따라 클라이언트 옵션에 차이가 있지만 공통적으로 클린 세션(Clean Session)을 비활성화 하고 메시지의 QoS 레벨을 1이상으로 전송할 때 메시지가 다시 전달됩니다.MQTT 버전 별 CleanSession 설정 (출처: https://www.emqx.com/en/blog/mqtt5-new-feature-clean-start-and-session-expiry-interval)MQTT 활용 예시MQTT 활용 예시 (출처: https://www.hivemq.com/blog/mqtt-essentials-part-1-i

안녕하세요. 인프랩 백엔드 개발자 인트입니다.현대의 웹 애플리케이션은 API를 통해 다양한 데이터와 서비스를 연동하는 것이 일상이 되었습니다. 이러한 API를 사용하기 위해 다양한 통신방법이 존재하는데, HTTP를 가장 보편적으로 사용합니다. 우리는 이러한 HTTP 통신을 위해 다양한 외부 라이브러리를 사용하고 있습니다.이번 포스트에는 Nest.js 환경에서 외부 라이브러리에 종속되지 않고 쉽게 테스트할 수 있는 HTTP 클라이언트를 만든 경험을 공유하고자 합니다. 인터페이스 분리, 추상화 등 지금은 당연하게 사용하는 개념들에 대한 이야기가 될 것 같습니다. 후반부에는 더 나아가 선언적 HTTP 클라이언트에 대한 이야기와 이를 구현한 라이브러리를 소개하고자 합니다.본격적인 내용에 앞서 Nest.js에서 제공하는 에 대한 이야기를 나누고자 합니다. Nest.js를 사용하신다면 이 모듈의 도입을 한 번쯤 고민해 보셨을 것입니다. 공식 문서를 보면 다음과 같은 예제가 있습니다.짧은 코드이지만 이 모듈의 사용법과 제공하는 인터페이스를 파악할 수 있습니다. 저희도 이 모듈의 적용을 고려해 봤지만, 다음과 같은 이유로 사용하지 않았습니다.이 제공하는 의 모든 HTTP 요청 메서드는 Observable을 반환합니다. Observable은 여러 비동기 작업이 발생하는 상황에서 에서 제공하는 연산자를 활용해 쉽게 체이닝을 할 수 있는 장점이 있습니다. 하지만 저희는 대부분 일회성 HTTP 요청을 받아 처리하는 경우가 많았기에 Promise를 반환하는 것이 더 유용하다고 생각합니다.아니면 공식 문서에서 안내하는 Promise를 반환하는 방법을 사용할 수 있지만, 이는 내부적으로 로 변환하는 불필요한 과정이 추가됩니다.가 Observable을 반환하는 것을 넘어 내부에 AxiosResponse를 반환하는 것도 문제였습니다. AxiosResponse는 axios 라이브러리에서 제공하는 타입으로, HttpService에 의존하는 서비스는 결국 axios에 의존하게 됩니다.를 오랜 기간 사용하신 분들은 request라는 라이브러리를 사용해 보셨을 것입니다. 한때 커뮤니티에서 가장 인기 있는 HTTP 클라이언트 라이브러리였고 널리 사용되었습니다. 하지만 callback api의 한계로 지금은 완전히 deprecated된 상태이며 axios, got, node-fetch 등 다양한 라이브러리를 사용하고 있습니다.사실상 표준이라고 할 만한 HTTP 클라이언트 라이브러리는 없는 상황에서, axios도 언젠가 deprecated될 가능성이 있습니다. 만약 이러한 일이 발생해 새로운 라이브러리로 교체하는 상황이라고 가정해봅시다.라는 생각이 들 수도 있지만, 생각만큼 쉽지 않을 수 있습니다.먼저 에 의존한 서비스는 높은 확률로 AxiosResponse를 import 하고 있을 것이기에 이를 모두 새로운 라이브러리가 반환하는 항목으로 교체해야 합니다. 물론 텍스트 치환 기능을 사용해 쉽게 교체할 수 있지만, 서비스 내에서 AxiosResponse에만 존재하는 속성을 사용하고

Introduction이번 글은 Superb AI가 NestJS Interceptor를 어떻게 쓰고 있고, 사용하면서 겪었던 이슈들에 대해 공유하려고 합니다. NestJS를 도입을 결정하고 나서, 어떻게 하면 Logger를 구현할 때 코드 중복을 최소화하고 유지보수가 쉽도록 할 수 있을지에 대한 고민을 많이 했는데요. 그러던 중 Interceptor라는 기능에 대해 알게 되었고, 이를 적극 활용하여 Logger를 구현해 코드 중복을 최소화했습니다.NestJS Interceptor를 이해하기 위해서는 먼저 RxJS에 대해 살펴봐야 합니다.What is RxJS?RxJS는 이벤트 스트림을 다루는 라이브러리입니다. 유저의 액션에 따른 이벤트 값, API 응답 결과 등 비동기적 값들이 들어올 수 있고, 이를 operator를 이용해 변환합니다. RxJS는 함수형, 이벤트 그리고 비동기 프로그래밍에 영향을 받아 만들어졌습니다.RxJSRxJS는 여러 개념들을 가지고 있지만, 이 글에서는 크게 4가지만 설명하려고 합니다.ObservableObservable은 event가 흐르는 stream입니다. Observable은 누군가 구독(subscribe)을 해야 event를 발행(publish) 합니다. Observer가 Observable을 구독하면서 next, error, complete 키워드를 사용해 Observable에 흐르는 event를 처리합니다.아래는 실제 Observable의 예시입니다.observable에 1초에 한 번씩 4번 event를 발생 시킴Observable 변수에 붙은 $(달러) 표시는 Observable을 나타내는 코드 컨벤션입니다. interval()은 정의된 시간마다 증가하는 연속값을 스트림에 발생시키고, pipe() operator를 사용하여 Observable stream 내부에서 적용할 operator를 처리하게 됩니다. take는 발생시킨 이벤트 중 처음부터 n개까지의 이벤트만 받습니다.OperatorOperator는 Observable에서 각 이벤트들에 대해 연산을 할 수 있는 pure function입니다. 앞서 언급한 것처럼, RxJS는 함수형 프로그래밍에 영향을 많이 받아 이러한 pure function들이 많이 존재합니다. 대표적으로 tap(), filter(), min(), max()와 같은 operator가 존재합니다. 여기서 tab()은 Observable 중간의 값을 가져오는 함수입니다.ObserverObserver는 Observable을 구독하는 대상입니다. Observer를 정의하고 next, error, complete 세 가지를 정의해 주고 Observable에 구독을 하면 완성입니다. next는 Observable에 들어오는 event를 처리합니다. error는 Observable에서 error가 발생했을 때 event를 처리해 줍니다. complete는 없어도 되는 옵션인데요. Observable이 종료되면 complete가 호출되게 됩니다. 마지막으로 Observable을 Observe

Introduction이번 글은 Superb AI가 NestJS Interceptor를 어떻게 쓰고 있고, 사용하면서 겪었던 이슈들에 대해 공유하려고 합니다. NestJS를 도입을 결정하고 나서, 어떻게 하면 Logger를 구현할 때 코드 중복을 최소화하고 유지보수가 쉽도록 할 수 있을지에 대한 고민을 많이 했는데요. 그러던 중 Interceptor라는 기능에 대해 알게 되었고, 이를 적극 활용하여 Logger를 구현해 코드 중복을 최소화했습니다.NestJS Interceptor를 이해하기 위해서는 먼저 RxJS에 대해 살펴봐야 합니다.What is RxJS?RxJS는 이벤트 스트림을 다루는 라이브러리입니다. 유저의 액션에 따른 이벤트 값, API 응답 결과 등 비동기적 값들이 들어올 수 있고, 이를 operator를 이용해 변환합니다. RxJS는 함수형, 이벤트 그리고 비동기 프로그래밍에 영향을 받아 만들어졌습니다.RxJSRxJS는 여러 개념들을 가지고 있지만, 이 글에서는 크게 4가지만 설명하려고 합니다.ObservableObservable은 event가 흐르는 stream입니다. Observable은 누군가 구독(subscribe)을 해야 event를 발행(publish) 합니다. Observer가 Observable을 구독하면서 next, error, complete 키워드를 사용해 Observable에 흐르는 event를 처리합니다.아래는 실제 Observable의 예시입니다.observable에 1초에 한 번씩 4번 event를 발생 시킴Observable 변수에 붙은 $(달러) 표시는 Observable을 나타내는 코드 컨벤션입니다. interval()은 정의된 시간마다 증가하는 연속값을 스트림에 발생시키고, pipe() operator를 사용하여 Observable stream 내부에서 적용할 operator를 처리하게 됩니다. take는 발생시킨 이벤트 중 처음부터 n개까지의 이벤트만 받습니다.OperatorOperator는 Observable에서 각 이벤트들에 대해 연산을 할 수 있는 pure function입니다. 앞서 언급한 것처럼, RxJS는 함수형 프로그래밍에 영향을 많이 받아 이러한 pure function들이 많이 존재합니다. 대표적으로 tap(), filter(), min(), max()와 같은 operator가 존재합니다. 여기서 tab()은 Observable 중간의 값을 가져오는 함수입니다.ObserverObserver는 Observable을 구독하는 대상입니다. Observer를 정의하고 next, error, complete 세 가지를 정의해 주고 Observable에 구독을 하면 완성입니다. next는 Observable에 들어오는 event를 처리합니다. error는 Observable에서 error가 발생했을 때 event를 처리해 줍니다. complete는 없어도 되는 옵션인데요. Observable이 종료되면 complete가 호출되게 됩니다. 마지막으로 Observable을 Observe