Architecture Considerations

PubNub provides a high level of resilience and extremely low latency. The right architectural choice to use PubNub in the best possible way depends on your use case.

This document explains the wrong way and the right way to use PubNub. As you read through this document, you'll discover the most common mistakes a customer makes with PubNub.

Sending Messages

Sending messages on PubNub is easy. Call the Publish API. This is the starting point of your development adventure.

Inefficient Client-Server Passthrough Publish

Client brokers message to Server. This is inefficient. Your client should be using the PubNub Publish to net the full benefits of PubNub. By using PubNub incorrectly like the diagram above, the client may have multi-second latencies. It introduces your server and a single point of failure. Other nearby clients won't get sub-50ms round-trip performance This is the inefficient way to use PubNub.

Optimal Client Publish

The client publishes and subscribes to PubNub directly. The client receives a global average latency of 100ms. Nearby clients are likely to get sub-50ms latency. During connectivity duress, the client will be routed to the next accessible route. The client should use an Auth Key with granted access to Publish on a data channel.

Optimal Client Publish + Synchronous Server Logic

When you need to have your server involved for business logic reasons or data copy reasons. This pattern shows you the best approach for integrating server-side logic with PubNub.

Optimal Client Publish + Asynchronous Server Logic

Often you'll find the need to run business logic on your JSON messages, but without slowing the message delivery down. You can do this by creating an onAfter event handler. This handler type will allow you to execute server logic on a copy of your JSON message asynchronously while the original JSON message is on it's way to be delivered to the phone.

Optimal Client Publish + HTTP Call to Third-party API Server

You can integrate third-party APIs easily. Enable PubNub Functions onBefore or onAfter event handlers on your data channels and use the JavaScript code snippets to execute an HTTP call to the external API.

The payload returned from the API server can be used to augment and modify the original JSON message inline. Or you can save the original message to the third-party API using an onAfter event handler.

Optimal Server Sent Events

Server sent events are possible using PubNub. You can notify your users the completion status of a long-running task. If the event is client-initiated, the client must publish directly to PubNub. Sending events from your server should only be for asynchronous tasks like a timer/cron, system-level events or long-running task status.

Receiving Messages

Inefficient Proxy Connection

You may be considering a proxy in-the-middle solution. However this breaks down quickly when encryption and TCP connection duration policies conflict. Poor performance and the loss of reliability for the mobile app's connectivity.

Optimal TCP Connection to Nearest Point of Presence

You must subscribe to a data channel to receive messages using PubNub. This is done by calling the subscribe API using the PubNub SDK. When you invoke subscribe, the mobile app will open a TCP connection to the nearest PubNub data center. The connection is left open forever. When the mobile app is closed, the connection is cleared.

Message Data Copy

You may want to copy messages to your own database for indexing or backup purposes.

Inefficient Forking Messages Doubles Mobile Traffic

Sending data directly to your server from the client is an inefficient way to copy data from PubNub. The optimal way is to publish or fire your message directly to your local PubNub POP. PubNub provides multiple points of presence allowing your client device fast reliable connectivity.

Optimal Event Handler

Using PubNub Functions allows you to run the light-weight JavaScript code block directly inside PubNub Platform. You can issue an HTTP call directly inside JavaScript which POSTs the message body to your server. You can use onAfter event handlers to save the message to your database. Your server will receive the http payload and save the data as needed in your database.

Optimal Offline Backup with Storage and Playback

PubNub includes multi-datacenter replicated storage. Your messages are configurable to be indexed and stored across multiple PubNub PoPs. This allows you to fetch the history for a data channel on a periodic interval. You can download every message from your app via the storage and playback paging API. After you have fetched your messages, you can save them to your database and process the messages as you need.

Security

Key Exchange & Rotation

When providing the phone app with API keys (publish key, subscribe key, auth key, cipher key) you should never hard-code those keys directly in your production app. You should enable Access Manager to add security to your PubNub environment.

Using Access Manager, your mobile app should then authenticate itself by calling a secure endpoint with access credentials. Once authenticated, the endpoint will return an authKey that's not only more secure but also provides Role Based Access Control for each client.

You can program a PubNub Functions endpoint to authenticate the user and pass all the needed access keys including the authKey. Your business policies may also require key rotation periods and short session IDs.

Optimal Client Authenticates with your App Server returning Access Keys

To authenticate and provide access to PubNub's network for your users, you need to provide them API keys. The client is able to perform the permitted activities such as Read/Write/Admin/Manage.

The key exchange can occur after authentication. There are many authentication endpoints including your own. PubNub Functions endpoints offers this as well shown in the next example.

Optimal Client Authenticates with PubNub Functions Endpoint giving Access Keys

Using PubNub Functions endpoints, you can run your own lightweight JavaScript code on PubNub. This allows you to provide API keys to your client device programmatically.

Inefficient Client App has Hard-coded API Access Keys

When you hard code your API keys for access to PubNub, you'll put yourself in a security risk situation. You'll no longer have access to Key Rotation capabilities. It's not easy to implement your own Key Rotation. You'll be stuck in a multi-deploy multi-week work cycle in a process of Key Migration.

This is much more involved and it's better to avoid hard coding in general. If you don't have a web server, you can use PubNub Functions endpoints to store your access keys. The endpoint is accessible from your client device via HTTP POST. The endpoint will return access credentials to the client device including a Publish Key, Subscribe Key and an Auth Key generated via PubNub Grant method.

Inefficient Granting with Unlimited TTL

It's not recommended to offer unlimited TTL when creating an Auth Key for your users. Auth keys should be treated as temporary access tokens, similar to a session ID. There may be debugging/testing purposes where you may want to grant a one-time Unlimited TTL Auth Key. However, Unlimited TTLs shouldn't be given to your users.

Inefficient Client App with Secret Key Embedded

The secret key should only be used within a secure server and never exposed to client devices. If the secret key is ever compromised, it can be an extreme security risk to your PubNub account keys. If you suspect your secret key has been compromised, you have the ability to regenerate a new secret key for the existing PubNub keys set.

Regenerating the Secret Key

Please contact PubNub Support for guidance on best practices before you regenerate a secret key for a product PubNub key set. You'll be put in touch with a Solution Architect to determine the best path forward for your use case and requirements.

More Design Patterns

• Design Patterns for Server Message Aggregation
• Design Patterns for Friend Lists and Status Feeds