PubNub Design Patterns

PubNub Design Patterns

-부제 : Real Time Platform에서 디자인 패턴

Inbound Channel Pattern

PubNub는 채널마다 모든 메시지를 저장하고 저장 공간과 재생 기능을 갖는다.

히스토리 정보의 요청을 하는 것은 연결 단절로 놓친 부분의 메시지를 조회하기 위함이다.

이런 공통 패턴을 사용하면, 수백의 채널을 갖고 있다면 어떻게 되는가?

모든 각 채널의 히스토리를 호출하는 것은 덜 효율적이다. 채널 사용 하는 방법이

히스토리 호출의 회수를 줄여주도록 어떻게 변경을 해야 하나?

1) 1-1 Chat

(1) Channel Per Chat

내(a)가  4명의 사람과 개인대화를 한다면, 4개의 채널을 갖고, publish/subscribe를 한다.

- 몇시간정도 연결이 끊긴후에 재시작하면, 4개의 히스토리를 요청한다.

- 몇개월이 지난다면, 축적이 되어서 40명 정도의 친구가 있다면, 40개의 히스토리를 요청해야 한다.

- 이렇게 누적이 되기 시작하면 비효율적으로 변경 된다.

아주 많은 히스토리 api호출을 하는 것은 필요하지 않으며, 어떻게 하면 이것을 바꿀까?

이것을 재검토 - 가능한 만큼 적게 히스토리 호출을 감소시키는 것으로 원한다.

히스토리 호출을 하는것으로 내게 보내진 어떤 메시지던지 그 시점에 갖고 오도록 시도하는것이 무엇인가? 이는 내가 보낸 메시지를 항상 갖고 있기 떄문이다.

일대일 chat을 다른 누군 인지를 함께 구분하는 것이 무엇일까?

자료 자체만으로는 여기까지, 다른 이들과 한개의 chat채널은 구조상에 다른 차이점은  없다.

(2) Chat Inbound Channels

채팅 메시지가 전달 되는 것을 재설계 하면,

각 유저는 inbound channel를 갖고, 어떤 유저나 채팅의 메시지를 보내기 위해 사용한다.

- User B나 User C는 User A의 inbound channel로 메시지를 보낸다.

- 반대로, User A가 답장을 할때, 각 User에게 대응되는 inbound channel로 답신한다.

이 뜻은 User A의 놓친 모든 메시지를 갖고 오기 위해서는, 오직 inbound 채널에 히스토리 요청만이 필요하다. 이것은 email주소와 inbox를 갖는 것과 매우 유사하다.

-내가 많은 대화를 갖고 있지만, 모두 한 장소로 들어 온다.

-내 UI는 그것들을 논리적으로 분리하고, 그것은 체계화 하기 위해 metadata(to/from/subject)를 이용하여 그것을 이해하고 대화를 분리하는 방법이다.

보이는 것과 같이, User들(B,C,D,E)은 보내는 모든 메시지는 분리되는 일대일chat으로 User A의 inbound 채널로 보내진다.

- 마치 4명이 나에게 이메일 주소로 이메일을 보내는것과 같다.

- 시각적으로 그것들은 UI에서 분리가 될것이지만, data는 옮겨지고, 체계화되어지고,

단일 채널(User A의 inbound 채널)을 통해 들어오는 모든것들이다.

2) Group Chat

그룹chat의 경우에는, User A가 그룹으로 메시지를 전송하면, User는 다중으로 전송이 가능하고, 그룹내의 각각의 User의 inbound채널로 전송한다.

만약 그룹이 아주 큰(사용자가 많은)경우, 예를 들어 10명이 넘게 그룹chat이라면, 원래 시나리오와 같이 채널을 분리해서 특정한 chat으로 분리하기를 원한다.

이런 경우에 나는 history call이 상당하게 줄였다.

JSON Structure

원래 시나리오에서, 각 쳇은 분리된 채널이지만, 메시지는 아래처럼 생긴것을 받는다.

- From User A t o User B , sent to channel_1111

{

  message_id:10001,

  author: "user_a",

  content: "What are you doing this weekend?", 

  timestamp:1425244035

}

수신 채널 시나리오에서, 구조는 약간 다르게 좀 더 metadata가 UI를 위해 추가된다.

- From User A to User B, send to channel_user_b

{

  message_id:10001,

  chat_id:"user_a_user_b",

  author: "user_a",

  content: "What are you doing this weekend?", 

  timestamp:1425244035

}

물론, 좀 더 정보를 추가할 수 있으며, UI정보는 시각적,정렬,검색,tag등을 체계적으로

사용할 수 있다. 보낼수 있는 어떤것도 제한은 없다. chat_id key는 쳇에 포함되어 UI식별을 돕는다.

마지막으로, 그룹쳇을 위한 수신 방법으로 어떻게 보이지는지, 간단한 예제를 정리한다.

- From User A to Group Chat, sent to channel_user_b and channel_user_c

{

  message_id:10001,

  chat_id:"group_chat_1234",

  author: "user_a",

  content: "What are you doing this weekend?", 

  timestamp:1425244035

}

3) Hybrid Pattern

하나 작은 팁은 위의 패턴에 추가를 할 수 있고, 이로인새 PubNub의 흥미로운 사용을 가능하게 한다. 2가지 패턴을 조합할 수 있다. 이로 인해 좀 더 특정한 방법이고 쉽게 과거 기록을 볼 수 있다.

먼저, 수신채널을 사용할 수 있고, 또한 유저들 각각의 관계 사이에 복합적인 단독 채널을 사용할 수 있다.

메시지를 보내려고 할때, 2중 퍼블리싱 된다 : 각 사용자는 수신 채널로 퍼블리싱하고, 또한 둘 사이의 복합 채널로 퍼블리싱한다.

복합채널을 구독할 필요는 없다, 물론 히스토리를 메시지를 받기 위해 복합 채널을 통해 호출하지 않아도 된다. 

단지, 히스토리를 복합(채널)에서 호출할떄는 둘 사이의 메시지를 보기 원하거나

특정 시점으로 돌아가고자 할때 히스토리를 호출하면 된다.

이 (방식은) 좀 더 쉽게 둘사이의 메시지 히스토리를 얻는것을 가능하게 하고, 왜냐면 수신 채널은 모든 주고받는 쳇 메시지가 섞여 있기 떄문이다. 그것은 특정 시점으로 돌아가는 것이 어렵다.

http://scalabl3.github.io/pubnub-design-patterns/2015/03/05/Inbound-Channel-Pattern.html

Advanced Channel Groups

- Friend Lists, Status Feed and Presence

http://scalabl3.github.io/pubnub-design-patterns/2015/08/11/Advanced-Channel-Groups-Friend-Lists-Status-Feed-And-Presence.html