We’ve created a ton of training tutorials and extensive documentation on building real-time apps with PubNub using our 70+ SDKs. Important to us is ensuring that you’re building your app in the most efficient way possible.
That’s why we’re happy to announce our new PubNub Best Practices Playbook, which explains the right way (and the wrong way) to use PubNub. As you read through this playbook, we’ll show you the most common mistakes made, and how to avoid them, including a number of design patterns for implementing PubNub best practices in your architecture.
For a high-level overview of each pattern, see below. Otherwise, you can access the direct links to each pattern above.
This is an overview on how to best use PubNub, and how to not use PubNub, including optimal ways of publishing, subscribing, configuring security, and storing messages. We share some common mistakes we’ve encountered our customers doing, in hopes that you won’t!
Fan-in refers to an architecture with a high ingress, a many-to-one topology where there are a large number of inputs or publishers relative to the number of subscribers. For example, in an IoT application, you may want your backend server consume sensor data being streamed by thousands of sensors out in the field. This design pattern is aimed at best practices for architecting such fan-in use cases.
If you’d like to really understand how Stream Controller and Presence work, or if you’d like to create a Status Feed or a Friends List (complete with online/offline status), then this is the guide for you!
This is arguably the most fundamental pattern to understand! Optimal channel architectures for designing 1-1 and group chats, as well as the most efficient way to store messages from those chats.
PubNub’s Storage & Playback feature enables you to persist messages to disk, and have them retained anywhere from one day to forever. However, Storage & Playback does not expose the ability to update or delete messages. This design pattern outlines two different ways of simulating the updating or deletion messages.
This design pattern shows how to keep message & notification state in sync across multiple devices (e.g. tablet, laptop, mobile). This is especially useful when implementing read receipts.
For further support, please check out our learning resources.