저희는 모든 SDK가 일관되게 작동하고 PubNub 개발자에게 최상의 경험을 제공하기 위해 노력하고 있습니다. 최근 "이벤트 엔진" 업데이트로 통칭되는 여러 가지 변경 사항과 PubNub 이벤트 수신 방식을 더 잘 제어할 수 있는 새로운 "이벤트 리스너" API 세트를 도입했습니다.

이 글에서는 이러한 다양한 업데이트가 무엇인지 설명하고 새로운 "이벤트 리스너"에 대한 개요를 설명합니다.

SDK 지원

이 글을 작성하는 시점에 최신 버전의 Java, Swift, Javascript, Kotlin및 Rust SDK는 새로운 이벤트 엔진 및 이벤트 리스너를 지원하며, 곧 추가 SDK에서 지원될 예정입니다.

무엇이 변경되나요?

크게 보면 다음과 같이 SDK가 변경됩니다:

• 이벤트 리스너 API를 재작업하여 더 이상 전체 애플리케이션에 하나의 글로벌 PubNub 객체를 전달할 필요가 없도록 합니다. 이 목록의 네 가지 항목 중 새로운 이벤트 리스너 API가 PubNub 개발자에게 가장 큰 혜택을 제공할 것이므로 이 글의 대부분은 이에 대한 내용입니다.

• 메시지나 프레즌스 등의 이벤트를 수신하여 PubNub 백엔드와의 통신을 관리하는 로직을 업데이트하고 조율하는 것. 이것이 바로 '이벤트 엔진'입니다.

• '프레즌스 상태' 관리 개선. '이벤트 엔진'의 개선을 통해 가능해졌습니다.

• 재시도 정책을 모든 SDK에 일관성 있게 적용하기 위해 '이벤트 엔진'을 개선했습니다.

변경 사항 #1: 이벤트 리스너 API 재작업

보다 세분화된 이벤트 리스너를 제공하도록 SDK를 개선하여 수신하고자 하는 이벤트를 특정 엔티티로 범위를 지정할 수 있도록 개선하고 있습니다.

엔티티란무엇인가요 ? 엔티티는 '채널', '채널 그룹', '사용자 메타데이터', '채널 메타데이터' 중 하나가 될 수 있습니다.

여기서 이벤트란 무엇인가 요? '메시지', '현재 상태 이벤트', '신호', '개체 이벤트', '메시지 작업' 또는 '파일' 중 하나입니다.

이러한 개선 사항을 통해 여러 채널에 대해 별도의 메시지 핸들러를 지정할 수 있으므로 더 이상 애플리케이션의 전역 상태를 추적할 필요가 없고 모든 PubNub 이벤트에 대해 단일 리스너를 유지할 필요가 없다는 점이 가장 큰 장점입니다.

이 글을 쓰는 현재에도 다양한 SDK에 이러한 업데이트를 적용하고 있습니다. 다음 섹션의 코드 샘플에는 JavaScript를 사용했지만 이 글 상단에 나열한 각 SDK에서 동일한 기능을 구현한 것을 확인할 수 있습니다.

이벤트 리스너의 변화는 무엇인가요?

최근까지 모든 SDK에는 일반적으로 PubNub라고 하는 단일 모놀리식 객체가 SDK 중앙에 포함되어 구독, 구독 취소, 게시 등 가능한 모든 상호 작용의 진입점을 제공했습니다. 앱의 특정 화면에서 특정 채널을 구독하는 등의 작업을 수행하려면 앱 전체에서 이 전역 PubNub 객체에 대한 참조를 전달해야 했습니다.

PubNub 객체는 작업을 시작하는 것 외에도 사용자가 addListener() 및 removeListener( ) 메서드를 통해 상태 업데이트(주로 구독 연결 상태와 관련됨)와 메시지, 신호, 프레즌스 이벤트, 개체, 파일 및 작업 등 PN 네트워크에서 오는 실시간 이벤트를 수신할 수 있습니다. 이 addListener() 코드는 일반적으로 모든 이벤트 유형과 소스를 처리하기 위해 많은 수의 조건 블록 때문에 부풀어 오르게 됩니다 - 다음을 살펴보시기만 하면 됩니다. 데모 앱 중 하나의 코드 의 코드를 살펴보시기 바랍니다(!).

또한 모든 일이 PubNub 객체의 전역 범위에서 발생한다는 점을 이해하는 것이 중요합니다:

• 채널/채널그룹 구독 목록은 글로벌(즉, PubNub 객체로 범위 지정)이며, 구독/구독 취소 호출을 통해 글로벌 목록이 영향을 받습니다.

• 상태 및 이벤트 리스너는 글로벌이며 현재 구독 중인 모든 채널/채널그룹과 관련된 이벤트를 내보냅니다.

따라서 애플리케이션에 여러 개의 화면이 있고 각각 다른 PubNub 채널에 연결해야 하는 경우 사용자가 앱을 탐색할 때 어떤 연결이 필요한지 수동으로 추적해야 합니다. 더 이상 필요하지 않은 채널을 구독 취소할 때 이 과정에서 오류가 발생하기 쉽습니다.

이벤트 리스너를 위한 새로운 아키텍처

현재 다양한 SDK에 적용되고 있는 새로운 아키텍처는 구독을 처리하고 이벤트를 수신하는 보다 좁은 범위의 새로운 방법을 도입합니다. 이러한 업데이트된 SDK는 현재 이전 버전과 호환되지만 지원 중단은 이 글의 뒷부분에서 설명합니다. 새로운 아키텍처는 '엔티티' 객체를 생성하는 추가 메서드를 제공합니다:

• 채널

• 채널 그룹

• 사용자 메타데이터

• 채널 메타데이터

이러한 엔티티에는 구독 객체를 반환하는 구독 () 메서드가 포함되어 있습니다. 예를 들어, 자바스크립트 API는 다음과 같이 호출할 수 있습니다:

const channel = pubnub.channel('channel_1');
const channelSubscription = channel.subscription({receivePresenceEvents: true});
channelSubscription.subscribe()
channelSubscription.onMessage = function (message) {
    console.log(message);
}
channelSubscription.onPresence = function (presenceEvent) {
    console.log(presenceEvent);
}

반환된 구독 객체는 상위 엔터티에 대한 구독을 활성화하거나 중지하는 subscribe() 및 unsubscribe( ) 메서드를 포함하는 보다 좁은 범위의 PubNub 클라이언트라고 생각할 수 있습니다. 구독에서 이벤트를 수신하는 방법에는 두 가지가 있습니다:

1. 위의 코드 스니펫에 표시된 onMessage 및 onPresence에 대한 on[Event] 핸들러. 신호, 객체, 파일 및 메시지 작업에 대한 다른 핸들러도 존재합니다.

2. addListener 메서드는 단일 함수 내에서 모든 이벤트를 수신하며, 이전 API에서 업그레이드하는 경우 이 구문이 더 익숙할 것입니다. addListener 메서드를 사용하여 메시지 및 프레즌스 이벤트를 수신하는 JavaScript의 해당 코드는 다음과 같습니다:

channelSubscription.addListener({
    //  Messages
    message: (message) => {console.log(message)},
    //  Presence event
    presence: (presenceEvent) => {console.log(presenceEvent)}, 
    //  Other event handlers for signals, objects, files, message actions
});

새로운 이벤트 리스너의 장점은 무엇인가요?

어떤 엔터티(예: 채널)에 대해 여러 개의 구독 개체를 만들 수 있으며, 이러한 모든 구독 개체는 동일한 엔터티에 대해 만들어진 경우에도 서로 독립적입니다. 즉, 다른 구독에 영향을 주지 않고 각 구독을 활성화(subscribe())하거나 중지(unsubscribe())할 수 있으며 단일 PubNub 개체를 통해 전역 상태를 관리하는 것보다 훨씬 더 유연한 클라이언트 애플리케이션 구조화를 가능하게 해줍니다.

참고: 여러 개의 구독 개체를 만들면 SDK가 단일 서버 연결을 통해 모든 구독을 다중화하므로 리소스 측면에서 저렴합니다. 여러 개의 PubNub 개체를 만들면 각각 별도의 서버 연결을 유지해야 하는 '이전' 접근 방식과 대조해 보세요.

마지막으로, SDK는 PubNub 객체에서 글로벌 addListener() 메서드를 계속 지원하지만, 이 메서드는 오직 상태 이벤트를 수신할 때만 사용해야 합니다.

pubnub.addListener({
    status: (s) => {console.log('Status', s.category) }
});

다양한 주식의 가치를 보여주는 간단한 애플리케이션을 예로 들어 보겠습니다. 사용자가 애플리케이션을 처음 실행하면 몇 가지 인기 주식의 가치가 표시되지만 사용자가 로그인하면 좋아하는 주식 기호를 선택할 수 있고 해당 주식의 현재 가격도 수신할 수 있습니다.

PubNub에서 이 애플리케이션을 구현하려면 "commonStock" 채널과 "favoriteStock" 채널의 두 가지 채널을 선택할 수 있습니다.

이제 사용자 여정과 어떤 채널에서 주식 업데이트를 수신할지 추적하는 방법을 고려해 보겠습니다:

글로벌 개체에 의존하는 채널 구독에 대한 이전 아키텍처에서는 다음과 같이 했습니다.

1. 사용자가 애플리케이션을 실행합니다.

애플리케이션이 "commonStock" 채널을 구독합니다.

2. 사용자가 로그인합니다.

애플리케이션이 "favoriteStock" 채널을 구독합니다.

이제 애플리케이션이 두 개의 채널에 구독됩니다: "commonStock" 및 "favoriteStock"

3. 사용자가 로그아웃합니다.

이제 애플리케이션은 구독을 취소할 채널(이 경우 "favoriteStock")을 결정해야 합니다. 애플리케이션은 이제 단일 채널에만 구독됩니다: "commonStock"

이 예에서는 사소하지만 화면과 채널 수가 증가함에 따라 대규모 앱의 관리가 점점 더 복잡해지는 것을 알 수 있습니다. 애플리케이션에 구독 채널 목록을 전체적으로 볼 수 있고 사용자가 애플리케이션을 탐색할 때 해당 목록에 어떤 일이 발생해야 하는지 이해하는 일부 구성 요소가 필요합니다.

이제 새로운 이벤트 리스너를 사용하여 동일한 시나리오를 살펴 보겠습니다.

1. 사용자가 애플리케이션을 실행합니다.

애플리케이션이 이전과 마찬가지로 "commonStock" 채널을 구독합니다.

2. 사용자가 로그인합니다.

보통주와 관심 종목 주가를 수신하고 싶기 때문에 로그인한 사용자에 대해 두 개의 구독을 생성합니다. 사용자가 'commonStock' 채널을 구독했다는 사전 지식은 필요하지 않습니다.

stocksSub2 = PN.channel(“commonStock”).subscription() 
stocksSub2.subscribe()
favoritesSub = PN.channel(“favoriteStock”).subscription() 
favoritesSub.subscribe()

이제 애플리케이션이 두 개의 채널을 구독하게 됩니다: "사용자가 stocksSub1과 stocksSub2를 모두 구독하더라도 추가 리소스를 사용하지 않으며 중복 메시지를 수신하지 않습니다.

3. 사용자가 로그아웃합니다.

사용자 로그아웃 로직의 일부로 "commonStock" 및 "favoriteStock" 채널 모두에서 구독을 취소합니다. 로그아웃한 사용자가 어떤 채널에 액세스할 수 있는지는 우리의 범위를 벗어나므로 고려할 필요가 없습니다.

stocksSub2.unsubscribe()
favoritesSub.unsubscribe()

이제 애플리케이션이 단일 채널에 구독됩니다: 기존 stocksSub1 구독으로 인해 "commonStockPrices"라는 단일 채널을 구독하게 됩니다.

여기서 중요한 차이점은 애플리케이션의 여러 화면에서 각자의 범위 내에서 발생한 일만 처리하면 되므로 "commonStock"을 계속 구독해야 하는지 여부에 대한 글로벌 뷰를 유지할 필요가 없으며, 새로운 이벤트 핸들러가 이를 모두 처리한다는 것입니다.

구독을 구독 집합으로 결합하기

지금까지의 예에서는 개별 채널만 고려했지만, 구독 개체는 단일 채널 또는 채널 그룹에 국한되지 않으며, 이러한 모든 채널의 이벤트를 함께 처리하기 위해 구독 집합으로 결합할 수 있습니다.

이전 예제를 확장하여 로그인한 두 채널을 단일 이벤트 핸들러를 사용하여 단일 구독 집합으로 처리할 수도 있습니다.

subscriptionSet = pubnub.subscriptionSet({channels: ['commonStock', 'favoriteStock’]})
subscriptionSet.onMessage = function (message) {console.log(message.channel)}
subscriptionSet.subscribe()

구독이 생성된 것은 엔티티엔티티에서 구독이 생성되었지만, SubscriptionSet은 전역 PubNub 객체에서 호출됩니다.

PubNub 범위 구독은 언제 더 이상 사용되지 않나요?

이벤트 리스너를 위한 새로운 아키텍처를 도입함에 따라 이전 API는 SDK별로 더 이상 사용되지 않습니다. Javascript SDK를 예로 들어보면 "이전" pubnub.subscribe() 와 pubnub.unsubscribe() 메서드는 더 이상 사용되지 않는 것으로 표시되었습니다. 저희는 개발자들이 업그레이드 프로세스를 최대한 마찰 없이 진행할 수 있도록 하기 위해 각 SDK는 긴 수명 종료(EOL) 기간을 지원합니다. 특정 SDK에 대한 문서화된 EOL 기간은 문서에서 SDK의 기능 목록 하단에 있는 SDK 기능 목록 하단.

변경 사항 #2: 이벤트 엔진 업데이트

SDK의 핵심에는 메시지나 프레즌스 업데이트와 같은 이벤트를 수신하기 위해 PubNub 인프라와의 연결을 처리하는 로직 루프가 있으며, 이를 이벤트 엔진이라고 부릅니다. 일반적으로 이 기능은 SDK를 사용할 때 구성하는 것이 아니며 99%의 고객에게는 '바로' 작동합니다.9%의 고객에게 '즉시 작동'하지만, 모든 소프트웨어 엔지니어링 프로젝트와 마찬가지로 수년에 걸쳐 SDK 제품군을 개발하면서 기술 부채가 쌓이게 됩니다. 모든 SDK가 사용자에게 일관된 경험을 제공했지만, 그 이면에는 이벤트 엔진 내 구현상의 문제점이 있어 새로운 기능을 추가하고 드문 에지 케이스를 추적하는 데 어려움을 겪기도 했습니다.

저희는 예측 가능하고 일관된 방식으로 상태 전환을 처리하도록 각 SDK의 이벤트 엔진을 업데이트하고 있으며, 이를 통해 고객이 경험하게 될 엣지 케이스의 수를 줄이면서 추가 기능을 제공하는 개선 사항을 추가할 수 있게 될 것입니다.

새로운 이벤트 엔진에는 어떤 코드 변경이 필요하나요?

SDK 구성에 새로운 구성 옵션이 추가되었는데, 문서에 따르면 "구독 및 프레즌스에 표준화된 워크플로우를 사용"한다고 명시되어 있습니다. 여기서 '표준화'란 이전 섹션에서 설명한 모든 SDK에서 엔진 구현을 표준화하려는 노력을 반영한 것입니다.

이 옵션은 비파괴적 변경이므로 이 옵션을 true로 설정하면 별도의 문서화가 없는 한 애플리케이션을 변경할 필요가 없습니다. 지금까지 문서화된 유일한 예는 구독에 대한 Kotlin 구독에 대한 상태 이벤트 의 상태 이벤트가 다른 SDK와 일관성을 갖도록 업데이트되었다는 것입니다(자세한 내용은 일반 연결 워크플로)에 자세히 설명되어 있습니다. 이러한 업데이트된 상태는 Kotlin에서 연결 상태 리스너새 이벤트 엔진을 활성화할 때 추가 예외 및 필수 변경 사항은 SDK 설명서를 참조하세요.

변경 사항 #3: 프레즌스 상태 관리 업데이트

프레즌스 상태는 사용자 지정 사용자 상태 설정할 수 있지만 사용자가 채널에 구독하는 동안에만 유지됩니다. 프레즌스 상태의 일반적인 사용 사례로는 플레이어 점수, 게임 상태 또는 위치 유지 등이 있습니다. 저희의 협업(화이트보드) 데모에서 '현재 상태'를 사용하여 사용자의 커서 위치를 등록하고 업데이트하는 데 익숙하실 것입니다.

저희는 프레즌스 상태 업데이트를 다르게 처리함으로써 이점을 얻을 수 있는 특정 고객을 대상으로 몇 가지 엣지 사례를 확인했습니다. 그러나 이는 사례별로 적용되며 대부분의 고객은 변경 없이 기존 프레즌스 상태 로직을 계속 사용할 수 있습니다. 구체적으로 '기존' 프레즌스 상태 로직은 다음과 같습니다. setPresenceState, getPresenceState를 호출하고 'state-change' 프레즌스 이벤트를 수신합니다.

새로운 프레즌스 상태 관리에는 어떤 코드 변경이 필요하나요?

SDK 구성에 새로운 구성 옵션인 maintainPresenceState가 추가되었습니다. 별도의 안내가 없는 한 대부분의 고객은 이 매개 변수의 기본값인 'true'를 유지해야 합니다. 이 값을 'true'로 설정하면 위에서 설명한 대로 현재 동작이 유지됩니다.

변경 사항 #4: SDK 재시도 정책의 조화

클라이언트가 PubNub에서 연결이 끊어진 경우, 자동 재연결 정책은 그동안 서로 다른 SDK 간에 일관성이 없었습니다.

대부분의 SDK는 연결 문제에서 복구하는 방법을 구성하는 방법을 제공하는데, 가장 일반적으로 '재시도 정책' 구성을 노출하고 개발자가 '없음', '선형' 또는 '지수' 중에서 선택할 수 있도록 하는 방식입니다. 그러나 각 정책과 관련된 시간 초과 값은 하드코딩되어 SDK에 특정됩니다.

재시도 정책은 개선되고 사용자 지정할 수 있도록 개선되고 있습니다. 연결 관리 재접속 정책 페이지에 설명된 대로 SDK 전반에 걸쳐 이러한 변경 사항이 계속 적용됨에 따라 재시도 정책이 조화를 이루게 될 것입니다. 이제 구성할 수 있습니다:

• 선형 재시도 정책을 사용자 지정 가능한 지연 간격과 구성 가능한 최대 재시도 횟수로 설정할 수 있습니다.

• 지수 재시도 정책최소 및 최대 지연 간격과 최대 재시도 횟수를 사용자 지정할 수 있는 지수 재시도 정책.

• 재시도 정책에서제외해야하는 엔드포인트 , 예를 들어 데이터가 시간에 민감하여 재시도하는 것이 적절하지 않은 경우 제외할 수 있습니다. 많은 오디언스가 많은 메시지에 반응하는 실시간 이벤트를 예로 들면 'message_reaction' 이벤트 유형을 제외하도록 선택할 수 있습니다.

새로운 글로벌 retryConfiguration 옵션 및 SDK별 제한 사항은 SDK의 구성 섹션을 참조하세요.

추가 리소스:

이 문서에 설명된 변경 사항, 특히 이벤트 리스너에 대한 변경 사항은 개발자가 Facebook API와 상호 작용하는 방식에 근본적인 변화를 의미합니다. 하지만 장기적인 이점이 초기 학습 곡선보다 크다고 믿습니다. 새로운 이벤트 리스너 API로 최대한 쉽게 전환할 수 있도록 지원하고자 하니 도움이나 지원이 필요하면 언제든지 전담 지원팀 또는 개발자 지원팀에 이메일을 보내주세요. devrel@pubnub.com.

또한 여러분의 피드백에도 관심이 있습니다. 더 쉽게 업그레이드할 수 있도록 저희가 할 수 있는 일이나 제공할 수 있는 것이 있나요? 알려주세요.

펍넙이 어떤 도움을 드릴 수 있나요?

이 문서는 원래 PubNub.com에 게시되었습니다.

저희 플랫폼은 개발자가 웹 앱, 모바일 앱 및 IoT 디바이스를 위한 실시간 인터랙티브를 구축, 제공 및 관리할 수 있도록 지원합니다.

저희 플랫폼의 기반은 업계에서 가장 크고 확장성이 뛰어난 실시간 에지 메시징 네트워크입니다. 전 세계 15개 이상의 PoP가 월간 8억 명의 활성 사용자를 지원하고 99.999%의 안정성을 제공하므로 중단, 동시 접속자 수 제한 또는 트래픽 폭증으로 인한 지연 문제를 걱정할 필요가 없습니다.

PubNub 체험하기

라이브 투어를 통해 5분 이내에 모든 PubNub 기반 앱의 필수 개념을 이해하세요.

설정하기

PubNub 계정에 가입하여 PubNub 키에 무료로 즉시 액세스하세요.

시작하기

사용 사례나 SDK에 관계없이 PubNub 문서를 통해 바로 시작하고 실행할 수 있습니다.