Alternatives to PubNub logo

Alternatives to PubNub

Pusher, Socket.IO, SendBird, Kafka, and Firebase are the most popular alternatives and competitors to PubNub.
124
141
+ 1
227

What is PubNub and what are its top alternatives?

PubNub makes it easy for you to add real-time capabilities to your apps, without worrying about the infrastructure. Build apps that allow your users to engage in real-time across mobile, browser, desktop and server.
PubNub is a tool in the Realtime Backend / API category of a tech stack.

PubNub alternatives & related posts

related Pusher posts

Pusher
Pusher
PubNub
PubNub
Google Cloud Pub/Sub
Google Cloud Pub/Sub

Which messaging service (Pusher vs. PubNub vs. Google Cloud Pub/Sub) to use for IoT?

See more

related Socket.IO posts

across_the_grid
across_the_grid
Full-stack web developer at Capmo GmbH · | 10 upvotes · 51.7K views
Socket.IO
Socket.IO
Node.js
Node.js
ExpressJS
ExpressJS

I use Socket.IO because the application has 2 frontend clients, which need to communicate in real-time. The backend-server handles the communication between these two clients via websockets. Socket.io is very easy to set up in Node.js and ExpressJS.

In the research project, the 1st client shows panoramic videos in a so called cave system (it is the VR setup of our research lab, which consists of three big screens, which are specially arranged, so the user experience the videos more immersive), the 2nd client controls the videos/locations of the 1st client.

See more
React
React
Redux
Redux
FeathersJS
FeathersJS
HTML5
HTML5
JavaScript
JavaScript
MongoDB
MongoDB
Redis
Redis
Socket.IO
Socket.IO
ES6
ES6

I have always been interested in building a real-time multiplayer game engine that could be massively scalable, and recently I decided to start working on a MMO version of the classic "snake" game. I wanted the entire #Stack to be based on ES6 JavaScript so for the #Backend I chose to use FeathersJS with MongoDB for game/user data storage, Redis for distributed mutex and pub/sub, and Socket.IO for real-time communication. For the #Frontend I used React with Redux.js, the FeathersJS client as well as HTML5 canvas to render the view.

See more

related Kafka posts

Eric Colson
Eric Colson
Chief Algorithms Officer at Stitch Fix · | 19 upvotes · 351.1K views
atStitch FixStitch Fix
Kafka
Kafka
PostgreSQL
PostgreSQL
Amazon S3
Amazon S3
Apache Spark
Apache Spark
Presto
Presto
Python
Python
R
R
PyTorch
PyTorch
Docker
Docker
Amazon EC2 Container Service
Amazon EC2 Container Service
#AWS
#Etl
#ML
#DataScience
#DataStack
#Data

The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.

Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).

At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.

For more info:

#DataScience #DataStack #Data

See more
John Kodumal
John Kodumal
CTO at LaunchDarkly · | 15 upvotes · 188.4K views
atLaunchDarklyLaunchDarkly
Amazon RDS
Amazon RDS
PostgreSQL
PostgreSQL
TimescaleDB
TimescaleDB
Patroni
Patroni
Consul
Consul
Amazon ElastiCache
Amazon ElastiCache
Amazon EC2
Amazon EC2
Redis
Redis
Amazon Kinesis
Amazon Kinesis
Kafka
Kafka

As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.

We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.

See more

related Firebase posts

fontumi
fontumi
Firebase
Firebase
Node.js
Node.js
FeathersJS
FeathersJS
Vue.js
Vue.js
Google Compute Engine
Google Compute Engine
Dialogflow
Dialogflow
Cloud Firestore
Cloud Firestore
Git
Git
GitHub
GitHub
Visual Studio Code
Visual Studio Code

Fontumi focuses on the development of telecommunications solutions. We have opted for technologies that allow agile development and great scalability.

Firebase and Node.js + FeathersJS are technologies that we have used on the server side. Vue.js is our main framework for clients.

Our latest products launched have been focused on the integration of AI systems for enriched conversations. Google Compute Engine , along with Dialogflow and Cloud Firestore have been important tools for this work.

Git + GitHub + Visual Studio Code is a killer stack.

See more
Aliadoc Team
Aliadoc Team
at aliadoc.com · | 5 upvotes · 126.8K views
atAliadocAliadoc
React
React
Create React App
Create React App
CloudFlare
CloudFlare
Firebase
Firebase
Cloud Functions for Firebase
Cloud Functions for Firebase
Google App Engine
Google App Engine
Google Cloud Storage
Google Cloud Storage
Serverless
Serverless
Visual Studio Code
Visual Studio Code
Bitbucket
Bitbucket
#Aliadoc

In #Aliadoc, we're exploring the crowdfunding option to get traction before launch. We are building a SaaS platform for website design customization.

For the Admin UI and website editor we use React and we're currently transitioning from a Create React App setup to a custom one because our needs have become more specific. We use CloudFlare as much as possible, it's a great service.

For routing dynamic resources and proxy tasks to feed websites to the editor we leverage CloudFlare Workers for improved responsiveness. We use Firebase for our hosting needs and user authentication while also using several Cloud Functions for Firebase to interact with other services along with Google App Engine and Google Cloud Storage, but also the Real Time Database is on the radar for collaborative website editing.

We generally hate configuration but honestly because of the stage of our project we lack resources for doing heavy sysops work. So we are basically just relying on Serverless technologies as much as we can to do all server side processing.

Visual Studio Code definitively makes programming a much easier and enjoyable task, we just love it. We combine it with Bitbucket for our source code control needs.

See more
Google Cloud Pub/Sub logo

Google Cloud Pub/Sub

204
88
1
204
88
+ 1
1
Global service for real-time and reliable messaging and streaming data
Google Cloud Pub/Sub logo
Google Cloud Pub/Sub
VS
PubNub logo
PubNub

related Google Cloud Pub/Sub posts

Pusher
Pusher
PubNub
PubNub
Google Cloud Pub/Sub
Google Cloud Pub/Sub

Which messaging service (Pusher vs. PubNub vs. Google Cloud Pub/Sub) to use for IoT?

See more
SignalR logo

SignalR

158
143
50
158
143
+ 1
50
A new library for ASP.NET developers that makes developing real-time web functionality easy.
SignalR logo
SignalR
VS
PubNub logo
PubNub
NATS logo

NATS

92
90
36
92
90
+ 1
36
Lightweight publish-subscribe & distributed queueing messaging system
NATS logo
NATS
VS
PubNub logo
PubNub
WCF logo

WCF

45
18
0
45
18
+ 1
0
A runtime and a set of APIs for building connected, service-oriented applications
    Be the first to leave a pro
    WCF logo
    WCF
    VS
    PubNub logo
    PubNub
    deepstream.io logo

    deepstream.io

    28
    55
    36
    28
    55
    + 1
    36
    A scalable server for realtime webapps
    deepstream.io logo
    deepstream.io
    VS
    PubNub logo
    PubNub
    Faye logo

    Faye

    22
    19
    23
    22
    19
    + 1
    23
    Simple pub/sub messaging for the web
    Faye logo
    Faye
    VS
    PubNub logo
    PubNub
    Horizon logo

    Horizon

    13
    34
    0
    13
    34
    + 1
    0
    A realtime, open-source JavaScript back end from RethinkDB
      Be the first to leave a pro
      Horizon logo
      Horizon
      VS
      PubNub logo
      PubNub
      Pulsar logo

      Pulsar

      11
      22
      1
      11
      22
      + 1
      1
      Distributed solution providing messaging and queuing for streaming data
      Pulsar logo
      Pulsar
      VS
      PubNub logo
      PubNub

      related Pulsar posts

      Marc Bollinger
      Marc Bollinger
      Infra & Data Eng Manager at Lumosity · | 4 upvotes · 80.8K views
      atLumosityLumosity
      Node.js
      Node.js
      Ruby
      Ruby
      Kafka
      Kafka
      Scala
      Scala
      Apache Storm
      Apache Storm
      Heron
      Heron
      Redis
      Redis
      Pulsar
      Pulsar

      Lumosity is home to the world's largest cognitive training database, a responsibility we take seriously. For most of the company's history, our analysis of user behavior and training data has been powered by an event stream--first a simple Node.js pub/sub app, then a heavyweight Ruby app with stronger durability. Both supported decent throughput and latency, but they lacked some major features supported by existing open-source alternatives: replaying existing messages (also lacking in most message queue-based solutions), scaling out many different readers for the same stream, the ability to leverage existing solutions for reading and writing, and possibly most importantly: the ability to hire someone externally who already had expertise.

      We ultimately migrated to Kafka in early- to mid-2016, citing both industry trends in companies we'd talked to with similar durability and throughput needs, the extremely strong documentation and community. We pored over Kyle Kingsbury's Jepsen post (https://aphyr.com/posts/293-jepsen-Kafka), as well as Jay Kreps' follow-up (http://blog.empathybox.com/post/62279088548/a-few-notes-on-kafka-and-jepsen), talked at length with Confluent folks and community members, and still wound up running parallel systems for quite a long time, but ultimately, we've been very, very happy. Understanding the internals and proper levers takes some commitment, but it's taken very little maintenance once configured. Since then, the Confluent Platform community has grown and grown; we've gone from doing most development using custom Scala consumers and producers to being 60/40 Kafka Streams/Connects.

      We originally looked into Storm / Heron , and we'd moved on from Redis pub/sub. Heron looks great, but we already had a programming model across services that was more akin to consuming a message consumers than required a topology of bolts, etc. Heron also had just come out while we were starting to migrate things, and the community momentum and direction of Kafka felt more substantial than the older Storm. If we were to start the process over again today, we might check out Pulsar , although the ecosystem is much younger.

      To find out more, read our 2017 engineering blog post about the migration!

      See more
      Gun logo

      Gun

      10
      40
      0
      10
      40
      + 1
      0
      Self-hosted Firebase.