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 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-100 ms 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 100 ms. Nearby clients are likely to get sub-100 ms latency. During connectivity duress, the client will be routed to the next accessible route. The client should use an authorization token 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 Functions
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.
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
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 Message Persistence
PubNub includes multi-datacenter replicated message persistence. 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 Message Persistence paging API. After you have fetched your messages, you can save them to your database and process the messages as you need.
Key Exchange & Rotation
When providing the phone app with API keys (
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 needs to authenticate itself by calling a secure endpoint with access credentials. To get them, the server needs to first make a grant call to PubNub and request a time-limited token with embedded permissions for the app. The app needs to include the received token in any subsequent request made to PubNub to access various resources (channels, channel groups, or User ID metadata) and perform operations at the access level defined in the token. For more details, read about the authentication flow in Access Manager.
User ID / UUID
User ID is also referred to as
uuid in some APIs and server responses but holds the value of the
userId parameter you set during initialization.