Quali sono i vantaggi competitivi di Pusher rispetto a PubNub?

Ho costruito grandi applicazioni web di produzione usando sia Pusher che PubNub, e ho anche migrato applicazioni da uno all'altro. La più grande differenza tra i due servizi è il fatto che PubNub usa HTTP streaming/long-polling mentre Pusher usa WebSockets. WebSockets è chiaramente la migliore tecnologia a lungo termine, ma non è affidabile oggi in certi scenari. Fortunatamente, Pusher ha anche aggiunto un fallback HTTP long polling nel caso in cui WebSockets non funzioni.

Io andrò più in dettaglio qui sotto:

Strumenti di debug
Sia Pusher che PubNub forniscono alcuni strumenti di debug. Trovo che Pusher sia più facile da usare. Per esempio, in Pusher puoi semplicemente aprire la console di debug e guardare tutti i messaggi che passano. In PubNub, devi incollare il nome esatto del canale che vuoi ascoltare. Il che va bene se il nome del vostro canale è semplice, ma è un dolore enorme se il nome del vostro canale ha una lunga stringa di caratteri casuali. Perché dovreste fare una cosa del genere? Beh, questo mi porta a...

Sicurezza/canali privati
Sia PubNub che Pusher supportano l'invio di messaggi su canali criptati.

Pusher ha un semplice approccio all'autorizzazione chiamato canali privati (http://pusher.com/docs/client_api_guide/client_private_channels) che ti permette di autenticare che un utente ha accesso ad un particolare canale fornendo una chiave di autorizzazione firmata dalla tua chiave segreta. Questo permette di autenticare in base all'utente attualmente loggato, per esempio.

PubNub ha due approcci all'autorizzazione. È possibile 1) pagare una quota mensile extra (al momento di questa scrittura $149/mo) per la loro funzione Access Manager, che consente di concedere esplicitamente agli utenti il permesso di lettura/scrittura a canali specifici tramite la loro API Access Manager o 2) generare nomi di canali unici inserendo un token segreto imprevedibile nei vostri nomi di canale (sostenuto in questo problema github: https://github.com/pubnub/pubnub-api/issues/9)

Delega degli eventi
Pusher ha un bel modello di canale/evento dove è possibile iscriversi a un canale, ma poi legare callback a eventi specifici su quel canale. Ho scoperto che questo è un modo abbastanza naturale di implementare gli eventi dei messaggi. PubNub non ha nulla di simile. Invece, devi creare un canale separato per ogni evento o creare tu stesso la delega dell'evento.

Modifica: il CTO di PubNub ha detto che PubNub supporta un modello di eventi, ma ho avuto problemi a trovare qualsiasi documentazione su di esso o a capire come funziona, ma mi ha inviato questo link in riferimento ad esso: pubnub/javascript (https://github.com/pubnub/javascript/blob/master/examples/event-example/event-example.js)

Dimensione del messaggio
PubNub limita i messaggi a 1.800 byte - che potrebbe non essere sufficiente a seconda di ciò che stai inviando. Questo si è dimostrato problematico per me quando parte di ciò che sto spingendo sono dati inseriti dall'utente che hanno lunghezza variabile. Ti permettono di aumentare la dimensione massima a 7.2k per un costo mensile aggiuntivo ($149 al momento in cui sto scrivendo questo)

Per peggiorare le cose, la gemma ruby fallisce silenziosamente quando il messaggio è più lungo di così - che mi è costato ore di debug cercando di capire perché i miei messaggi non vengono ricevuti.

I limiti di Pusher sono di 10kb per messaggio come parte della loro normale offerta (Vedi: Qual è il limite di dimensione del messaggio quando si pubblica un messaggio?) Offrono messaggi di dimensioni maggiori per i piani aziendali.

Canali di presenza
Sia Pusher che Pubnub hanno canali di presenza, che potrebbero esservi utili se state implementando un sistema di chat, ecc. Non li ho ancora usati o necessari.

Sommario
In generale, ho trovato che Pusher ha una migliore documentazione/esempi, una migliore API e migliori strumenti di backend/debug. Mi piacciono molto i canali privati che Pusher offre, le dimensioni dei messaggi più grandi e la possibilità di inviare diversi eventi su un singolo canale e sottoscrivere solo eventi particolari. Ma vale la pena di valutare e prototipare con entrambi per capire quale soddisfa meglio le vostre esigenze particolari.