Easily build complete, trusted realtime functionality.
Take our APIs for a spinDisclaimer: All information is as accurate as possible as of publishing, September 2019. It’s worth noting that the information presented in this article has been gathered based on documentation and resources freely available online from Fanout and Pusher. Be sure to double-check anything before you make any decisions. If you do find anything incorrect or out of date then please let us know.
That said, the aim is to help you make a more informed decision when it comes to choosing a realtime data streaming or messaging platform. We’ll cover a set of questions we think are essential to ask of any realtime data streaming platform.
Fanout and Pusher are realtime messaging platforms offering high-throughput and realtime data delivery between online networks of users and services. Like all platforms there are pros and cons of each.
Contents
- Is it fast, reliable, and redundant?
- What’s the level of platform interoperability?
- How easy is it to get started and then scale up?
- How does the platform handle realtime connectivity?
- How mature is the feature set?
- Does the platform offer realtime API Management tools?
- How secure is the platform and the way it does things?
- How responsive and helpful is support?
- How clear, flexible, and scalable is the pricing structure?
To help you answer the questions above in relation to Fanout and Pusher we’ve done our best to perform an unbiased, high-level comparative analysis of both platforms.
Is it globally fast, reliable, and redundant?
Before considering anything else you need to trust your realtime provider can deliver a stable and reliable service that’s easy to implement.
Information provided is from publicly available sources and is intended as a starting point for further investigation. See full disclaimer.
| Reliability | Fanout | Pusher |
|---|---|---|
| Latency of response times | No data available. | No data available. |
| Uptime SLA | 99.999% uptime SLAs. | 99.9% uptime SLAs for Enterprise plans. |
| How many globally distributed datacenters? | Four globally-distributed datacenters The datacenter network comprises three Point of Presence locations in addition to a single Central location. |
Six datacenters across six Amazon geographical regions in Europe, USA, Asia Pacific. However, you must choose a single datacenter to host your app. |
| Latency based routing that ensures users connect to the closest datacenter | Supports latency based routing. | Supports latency based routing. |
| Mesh architecture with no central point of failure | Unknown. | No. |
| Data replicated in multiple regions | Unknown. | No. Application data is stored in a single datacenter, making it more susceptible to data loss. |
| Quality of Service and message delivery guarantee (never lose data during brief disconnections) | Shaky. With Fanout, if a message is published whilst a client is briefly disconnected (if they are going through a tunnel, for example), then the message may never arrive to that client. |
No. If a message is published whilst a client is briefly disconnected (such as going through a tunnel or changing networks), then the message will never arrive to that client. |
The comparisons presented here are: (i) derived from public information and open sources available as of September 2019, and thus may be outdated; (ii) intended as a starting point for further investigation; and (iii) not guaranteed to be 100% accurate or complete. The reader is encouraged to conduct an independent evaluation and to not rely solely on the information presented here. Please contact us if you believe the information here is inaccurate or incomplete.
What’s the level of platform interoperability?
The modern internet is a web of different languages, platforms, open and proprietary protocols, and services built on top of other services. This isn’t likely to change anytime soon so a platform that supports widespread interoperability is essential in the long-term. There are three questions to help assess how interoperable a platform is:
- How extensively does the platform support different languages, frameworks, and protocols?
- How easy is it to migrate to or move away from the platform?
- Are there protocols for streaming data into third party platforms?
Information provided is from publicly available sources and is intended as a starting point for further investigation. See full disclaimer.
| Interoperability | Fanout | Pusher |
|---|---|---|
| Support for native client libraries/SDKs | 6 SDKs. | Wide support with ~30 SDKs. |
| Support for open source and proprietary protocols (e.g. MQTT, AMQP, STOMP) | Limited. | No support. |
| Migration and lock-in | Does not support proprietary realtime vendor protocols, making it harder to migrate in and away. | Does not support proprietary realtime vendor protocols, making it harder to migrate in and away. |
| Coverage of various languages, frameworks, protocols and transports, including MQTT | Limited. Fanout supports a few server environments; Python, Ruby, Php, Node, Golang, and .NET. HTTP stream is offered for languages they do not support. |
No support. |
The comparisons presented here are: (i) derived from public information and open sources available as of September 2019, and thus may be outdated; (ii) intended as a starting point for further investigation; and (iii) not guaranteed to be 100% accurate or complete. The reader is encouraged to conduct an independent evaluation and to not rely solely on the information presented here. Please contact us if you believe the information here is inaccurate or incomplete.
How easy is it to get started and scale up?
The user-friendliness of the API and the available documentation are good ways to understand ease of operation. A deeper understanding comes through using the product – something outside the scope of this comparison page.
Is the API easy to use: Getting set up with Fanout
Looking at the official Node.js Client here is how to publish a message using Fanout:
var grippub = new grip.GripPubControl({
'control_uri': 'https://api.fanout.io/realm/<myrealm>',
'control_iss': '<myrealm>',
'key': new Buffer('<myrealmkey>', 'base64')});
// Add new endpoints by applying an endpoint configuration:
grippub.applyGripConfig([{'control_uri': '<myendpoint_uri_1>'},
{'control_uri': '<myendpoint_uri_2>'}]);
// Publish across all configured endpoints:
grippub.publishHttpResponse('<channel>', 'Test Publish!', callback);
grippub.publishHttpStream('<channel>', 'Test Publish!', callback);Is the API easy to use: Getting set up with Pusher
Here we use JavaScript to get going with Pusher.
var pusher = new Pusher('APP_KEY', {
cluster: 'APP_CLUSTER'
});
// Subscribe to a Pusher channel
var channel = pusher.subscribe('my-channel');
// Listen for events on the channel
channel.bind('my-event', function(data) {
alert('An event was triggered with message: ' + data.message);
});
// Trigger events/send messages from your server using Node.js
var Pusher = require('pusher');
var pusher = new Pusher({
appId: 'APP_ID',
key: 'APP_KEY',
secret: 'APP_SECRET',
cluster: 'APP_CLUSTER'
});
pusher.trigger('my-channel', 'my-event', {"message": "hello world"});Which API is best?
Looking at the code-blocks above, both API’s are easy to use.
Is the documentation any good?
Documentation is the bedrock of understanding and using software, especially for such complicated and essential functionality as realtime messaging. Nowadays this is a really low bar but far too many services still have minimal, incomplete, or no documentation at all. Clear and succinct documentation is usually a good indication that the service is well-designed and you’ll be able to find the information you need. And if they’re using the OpenAPI Specification then that’s a good sign too.
Do Fanout and Pusher make the grade? Both do well with fairly extensive documentation across quickstart guides, SDKs, and docs explaining core features of their respective platforms, along with some concepts around streaming data in general.
As an aside, Fanout’s documentation has a good step-by-step flow for each language and functionality. Pusher also provides tutorials that covers a lot of use-cases across designs and implementation of apps you might want to build.
How does the platform handle connectivity and transport?
How your data/messages are transported changes the speed of delivery and fundamentally impacts your product or service. A realtime platform provider should always choose the best transport available based on the browser and connection available. The client library should prioritize transports in this order:
- Websockets
- XHR streaming
- XHR polling
- JSONP polling
Fanout provides WebSocket support, with fallback to XHR and Long Polling for older browsers. It also offers HTTP streaming. Pusher provide first-class WebSocket support with fallbacks for older clients.
The general consensus in the realtime industry is that the WebSocket protocol is a faster, more efficient transport option than HTTP. And while, at the moment, HTTP is more widely supported (although as of early 2019 the difference is small and rapidly shrinking) many believe WebSockets will become the universally-accepted standard for streaming data in the near future.
How mature is the feature set?
It takes non-trivial engineering effort to adopt a realtime data streaming platform and integrate into your application or service. It’s natural you’ll want to make sure the platform you choose has a mature and full feature set that provides the basic the functionality you’d expect from a realtime platform, provides the features you need right now, and has the functionality to support you as you grow and your needs change.
Below is a feature matrix with a set of standard features you’d expect to see on offer from an established realtime data streaming platform. Fanout and Pusher are compared side by side against these features.
Information provided is from publicly available sources and is intended as a starting point for further investigation. See full disclaimer.
| Features | Fanout | Pusher | Why does it matter? |
|---|---|---|---|
| Realtime data streaming | Yes. | Yes. | |
| Message and worker queues | No. Fanout does not offer any message queuing features or ways to distribute data using once-only pattern to your server workers. |
No. Pusher does not offer any message queuing features or ways to distribute data using once-only pattern to your server workers. |
Message queues that provide a reliable and straightforward mechanism to consume, process, store, augment or reroute data efficiently from a realtime platform. |
| Webhooks | Yes. | Yes. | Webhooks provide a means to get messages, channel lifecycle and present events pushed to your servers over HTTP. |
| Serverless cloud function invocation | Limited. | No. | Trigger serverless functions on third platforms like Amazon Lambda, Microsoft Azure or Google Function. |
| Presence | No. | Yes. Pusher supports a maximum of 100 members per channel. |
Subscribe to events when users or devices enter or leave channels/topics. |
| Message history | No. | No. | Dictates whether clients can access historical activity, catching up on missed messages. |
| Realtime data firehose | No. | No. | Stream your realtime data published within a realtime platform directly to another streaming or queueing service such as Amazon Kinesis, Apache Storm or Kafka. |
| Native push notifications | No. | Yes. | Send notifications and updates to users even when they are offline. |
| Custom domain endpoint (CNAME) | Yes. | No. | Custom domains allowing you to connect using a CNAME such as “realtime.your-company.com”. |
The comparisons presented here are: (i) derived from public information and open sources available as of September 2019, and thus may be outdated; (ii) intended as a starting point for further investigation; and (iii) not guaranteed to be 100% accurate or complete. The reader is encouraged to conduct an independent evaluation and to not rely solely on the information presented here. Please contact us if you believe the information here is inaccurate or incomplete.
As the matrix shows, both providers offer a good level of realtime messaging functionality. They also offer some additional help for developers when it comes to doing the technical heavy lifting. Yet both could offer more on that front as features like serverless functions, reliable message ordering, and message queues are missing or proprietary. With serverless compute and event-driven architecture becoming more integrated into our software design these omissions should weigh heavily in your decision.
Pusher has wider feature coverage, beating Fanout on push notifications and providing presence channels. That said, the two have similar levels of service and both provide solid options. So, as stated before, using this feature matrix as a guide, check the platform functionality in relation to your own specific requirements and preferences.
Both fall short when it comes to features that would allow you to substantially scale your realtime offering – though again Pusher fares marginally better with its push notification and presence features. Notable here on both counts is a lack of realtime data firehose, lack of reliable messaging ordering and lack of message and worker queues – omissions that are worth preemptively bearing in mind if you plan to scale your offering.
Does the platform offer realtime API Management tools?
Current realtime data streaming providers can give you the much-needed core transfer infrastructure for realtime data, but the burden of managing realtime APIs is still with you – REST API management tools are popular for a reason. Some headache-busting questions to ask:
- In addition to realtime streaming infrastructure, does the DSN come with operational tools to deploy and manage streaming APIs? (Think hosted endpoints, analytics, developer portals, and rate-limiting tools.)
- Is end-to-end data delivery supported (i.e. from source to destination) for your streaming APIs? Can you send data straight from IoT sensor to smartphone, without needing to pass through your own servers first?
Pusher offers little in this regard, compensating to some extent by readymade realtime SDKs such as chatkits. Fanout is significantly ahead of the curve here, offering to ‘make realtime push CDN delegable’. It allows users to link to its open-source realtime proxy, Pushpin, with established REST API management systems (Kong, Apigee and so on), to ‘turn your flat API endpoints into dynamic push’. The complexity of realtime streaming make end-to-end integration modules an extremely handy tool, that will help you overcome a number of engineering obstacles. Although Fanout’s realtime service uses REST API management tools, and won’t offer a seamless or native streaming experience, this is still a useful tool to have.
How secure is the platform and the way it does things?
Security and encryption are front of mind and any realtime platform will have robust security built into their design and delivery. A good general checklist for security is:
- TLS connection to ensure all data in transit are encrypted
- Token-based authentication (including JWT support), which ensures your private key is never shared and instead a short-lived token is used to authenticate
- Configurable private key permissions to restrict channels/topics or operations
- Encrypted message payloads to enhance security and privacy of all messages
Information provided is from publicly available sources and is intended as a starting point for further investigation. See full disclaimer.
| Security | Fanout | Pusher |
|---|---|---|
| TLS connection | Yes. | Yes. |
| Token-based authentication | Yes. | Yes. Pusher requires a separate authentication request for every channel. The recent Authorized Connections feature, introduced in December 2018, improved this by adding more granular channel permissions. |
| JSON Web Token (JWT) | Yes. Fanout uses Runscope JWT authentication. |
Partial. Pusher only supports JWT in certain products. |
| Configurable private key permissions | No. | No. |
| Configurable channel permissions | No. | Partial. Pusher provides a ‘private-’ and ‘presence-’ namespace for channels that require authentication. No other channel configuration is available. |
| Encrypted message payloads | No. | Yes. PubNub include AES encryption in its client library SDKs. |
The comparisons presented here are: (i) derived from public information and open sources available as of September 2019, and thus may be outdated; (ii) intended as a starting point for further investigation; and (iii) not guaranteed to be 100% accurate or complete. The reader is encouraged to conduct an independent evaluation and to not rely solely on the information presented here. Please contact us if you believe the information here is inaccurate or incomplete.
How responsive and helpful is support?
Reassuringly perhaps, there are some questions – particularly when it comes to complex software and infrastructure – that only humans can answer. With questions to do with bugs, pricing, implementation you need to be able to rely on responsive, helpful support.
Indications of a good support infrastructure are short response times on live-chat and email, people who understand the platform’s ins and outs, and up-to-date support portals for docs. An active community with forums or a group chat can also be a good sign.
Fanout’s support
Fanout base support on the plan you’ve subscribed to. For free plans, Fanout’s user community can offer advice, while for business plans, the team itself offer email support.
Pusher’s support
A breakdown of what we found of Pusher’s support offering:
- Ticket-based support with no live chat – most software providers today offer some sort of live chat or support and it’s often a quick two minute chat can point you to the right bit of documentation, saving you time searching yourself
- The help centre is solid with the expected FAQ style
- Most of the pricing tiers have target response times:
- Startup and pro pricing: target response within 72 hours
- Business and premium: target responses within 48 hours
- Enterprise: standard for the industry but quite the bump compared to Pusher’s other tiers with 24/7 support, phone support, and a dedicated Slack Channel
It’s clear that Pusher offer robust support as long as you’re willing to pay for it.
How clear, flexible, and scalable is the pricing structure?
Both Fanout and Pusher offer free and paid plans.
What do you get for free?
Fanout’s free ‘Hacker’ plan offers a maximum concurrent client count of 20, 500 minutes per day connected client time, 500 received and delivered messages per day with no SLA. If you’re using Fanout’s free plan you have to rely on its community for your support needs. For small-scale users Fanout offers an open source proxy Pushpin. While it’s beyond the scope of this review to evaluate Pushpin’s pros and cons, it is worth also bearing this option in mind.
Pusher offers 100 Max Connections, Unlimited Channels, 200k Messages / Day, Limited Support and SSL Protection on their channels product. 1,000 Uniquely Identified Users, 200,000 Messages, 2 Custom Roles and Standard Support of the ChatKit product.
What do you get for your money?
Fanout
For the paid plan, Fanout offers a $25 monthly plan, where you pay $4 per million messages sent and delivered and $4 per million minutes connected. The diagram below, taken from Fanout’s pricing page, details the benefits of its paid vs free plans.
It is worth noting Fanout’s paid accounts are $25 plus usage costs. You pay for extra minutes and/ or connections during peak moments. You also pay extra if you exceed your messaging limits.
Fanout operate a usage-based pricing scheme but charge customers based on the connected client time rather than peak connections. If clients are connected with idle connections for long periods of time then costs can quickly add up.
Pusher
Pusher prices its three products – Channels, Pusher Beams (aka push notifications), and Pusher ChatKit – separately and in tiers. If you’re looking for modular implementation this can be helpful. However, it can be frustrating to try and get a single overview if you wanted to adopt two or more – which many developers will want to do. And tier-based pricing isn’t the most flexible.
The main issue with Pusher’s pricing is tiering. The nature of realtime messaging and streaming data means connections, required channels, and messages often fluctuate. Plus it’s never easy to estimate how much you’ll need upfront anyway – especially true for realtime uses such as HQ-style games or live event/sports apps.
With this pricing model if you exceed any one attribute of a tier you’ll likely be forced into another more expensive tier. For example, moving from Pro to Business hikes the price from $99 to $299 per month. A better way is usage-based pricing where you only ever pay for capacity you’ve actually used.
Then there’s Beams.
Again, Beams is based on tiers rather than usage. There’s quite a difference between 10,000 devices for $99/month and up to 50,000 devices for $399/month. If you need 11,000 devices it looks like you’d need to fork over another $300 for only 1,000 more devices, which doesn’t make much sense. It’s possible there’s room for flexibility if you get in touch with Pusher.
Finally there’s ChatKit.
Once again, the major problem lies in concrete tiering with little room for manoeuvre. Depending on where your customers reside data protection could be an issue with only 90-day retention the standard for business tiers.
Overall Pusher’s rigid pricing tiers don’t seem to encourage growth or provide a joined-up view of data streaming costs. That said, Pusher’s pricing is simple and easily understood.
To sum up, Fanout is a cheaper alternative to Pusher. However, the pricing schemes of both providers require users to look carefully at what their streaming needs are now, and in future, to make sure invoices remain free of unpleasant surprises.
Which provider is best for me?
‘Best’ is subjective here, depending on developer needs. Below is a recap of the major differences:
- In terms of streaming infrastructure Pusher’s network is more developed, with more data centers than Fanout.
- Pusher offers presence channels, Fanout doesn’t
- Pusher offers better – but by no means exhaustive – language and platform coverage, claiming support for 30+ SDKs.
- In terms of security features, Fanout’s network is marginally better secured, with features such as token-based authentication and JWT that Pusher partially supports, although it tries to make up with permissible channels. However the two companies adopt significantly different approaches and it is worth looking at the details to see which best fits your needs.
- Both offer flexible, usage-based pricing with the option of customized plans. Fanout works out marginally cheaper based on the use cases in this study.
To sum up, with many additional valuable features such as a chat engine, push notifications, presence and better support options, Pusher appears to have a technically-superior offering.
If you’re just looking to get something up and running, and don’t want an initial influx of potential users (who may just be testing the waters with your service) to cause you to exceed your plan too quickly, then Fanout will likely fit the bill.
Ultimately the choice is yours but hopefully this article helped you gain a better understanding of what you should look for in a realtime data streaming platform – and whether Pusher or Fanout can provide what you’re looking for.