What is XMPP and what are its top alternatives?
Top Alternatives to XMPP
MQTT
It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. ...
Firebase
Firebase is a cloud service designed to power real-time, collaborative applications. Simply add the Firebase library to your application to gain access to a shared data structure; any changes you make to that data are automatically synchronized with the Firebase cloud and with other clients within milliseconds. ...
WebRTC
It is a free, open project that enables web browsers with Real-Time Communications (RTC) capabilities via simple JavaScript APIs. The WebRTC components have been optimized to best serve this purpose. ...
Socket.IO
It enables real-time bidirectional event-based communication. It works on every platform, browser or device, focusing equally on reliability and speed. ...
SignalR
SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available. SignalR supports Web Sockets, and falls back to other compatible techniques for older browsers. SignalR includes APIs for connection management (for instance, connect and disconnect events), grouping connections, and authorization. ...
Slack
Imagine all your team communication in one place, instantly searchable, available wherever you go. That鈥檚 Slack. All your messages. All your files. And everything from Twitter, Dropbox, Google Docs, Asana, Trello, GitHub and dozens of other services. All together. ...
Kubernetes
Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. ...
Kafka
Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design. ...
XMPP alternatives & related posts
- Varying levels of Quality of Service to fit a range of1
- Very easy to configure and use with open source tools1
- Lightweight with a relatively small data footprint1
- Easy to configure in an unsecure manner1
related MQTT posts
- Realtime backend made easy357
- Fast and responsive261
- Easy setup233
- Real-time206
- JSON184
- Free126
- Backed by google120
- Angular adaptor80
- Reliable62
- Great customer support36
- Great documentation25
- Real-time synchronization22
- Mobile friendly19
- Rapid prototyping17
- Great security12
- Automatic scaling10
- Freakingly awesome9
- Super fast development8
- Chat8
- Angularfire is an amazing addition!8
- Awesome next-gen backend6
- Ios adaptor6
- Firebase hosting5
- Built in user auth/oauth5
- Very easy to use4
- Great3
- Speed of light3
- Brilliant for startups3
- It's made development super fast3
- Low battery consumption2
- The concurrent updates create a great experience2
- I can quickly create static web apps with no backend2
- Great all-round functionality2
- Easy Reactjs integration1
- Good Free Limits1
- .net1
- Faster workflow1
- Serverless1
- JS Offline and Sync suport1
- Easy to use1
- Large1
- Push notification1
- Can become expensive26
- No open source, you depend on external company14
- Scalability is not infinite14
- Not Flexible Enough9
- Cant filter queries5
- Very unstable server3
- Too many errors2
- No Relational Data2
related Firebase posts



























This is my stack in Application & Data
JavaScript PHP HTML5 jQuery Redis Amazon EC2 Ubuntu Sass Vue.js Firebase Laravel Lumen Amazon RDS GraphQL MariaDB
My Utilities Tools
Google Analytics Postman Elasticsearch
My Devops Tools
Git GitHub GitLab npm Visual Studio Code Kibana Sentry BrowserStack
My Business Tools
Slack
We are starting to work on a web-based platform aiming to connect artists (clients) and professional freelancers (service providers). In-app, timeline-based, real-time communication between users (& storing it), file transfers, and push notifications are essential core features. We are considering using Node.js, ExpressJS, React, MongoDB stack with Socket.IO & Apollo, or maybe using Real-Time Database and functionalities of Firebase.
WebRTC
- OpenSource2
- No Download2
- You can write anything around it, because it's a protoc1
related WebRTC posts
Hello. So, I wanted to make a decision on whether to use WebRTC or Amazon Chime for a conference call (meeting). My plan is to build an app with features like video broadcasting, and the ability for all the participants to talk and chat. I have used Agora's web SDK for video broadcasting, and Socket.IO for chat features. As I read the comparison between Amazon Chime and WebRTC, it further intrigues me on what I should use given my scenario? Is there any way that so many related technologies could be a hindrance to the other? Any advice would be appreciated. Thanks. Ritwik Neema
I am trying to implement video calling in a React Native app through Amazon Kinesis. But I was unlucky to find anything related to this on the web. Do you have any example code I can use? or any tutorial? If not, how easy is it to bridge the native library to RN? And what should I use WebRTC or Amazon Chime?? Thanks
- Real-time209
- Event-based communication141
- Node.js140
- Open source101
- WebSockets99
- Binary streaming26
- No internet dependency22
- Fallback to polling if WebSockets not supported9
- Large community7
- Ease of access and setup5
- Push notification4
- Bad documentation9
- Githubs that complement it are mostly deprecated4
- Doesn't work on React Native2
- Small community2
related Socket.IO posts
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.
We are starting to work on a web-based platform aiming to connect artists (clients) and professional freelancers (service providers). In-app, timeline-based, real-time communication between users (& storing it), file transfers, and push notifications are essential core features. We are considering using Node.js, ExpressJS, React, MongoDB stack with Socket.IO & Apollo, or maybe using Real-Time Database and functionalities of Firebase.
SignalR
- Supports .NET server16
- Real-time13
- Free11
- Fallback to SSE, forever frame, long polling10
- WebSockets9
- JSON7
- Simple6
- Open source4
- Cool4
- Ease of use1
- Requires jQuery1
- Expertise hard to get1
- Weak iOS and Android support1
related SignalR posts
- Easy to integrate with1.2K
- Excellent interface on multiple platforms876
- Free846
- Mobile friendly692
- People really enjoy using it688
- Great integrations329
- Flexible notification preferences314
- Unlimited users196
- Strong search and data archiving184
- Multi domain switching support154
- Easy to use80
- Beautiful39
- Hubot support27
- Unread/read control22
- Slackbot21
- Permalink for each messages18
- Text snippet with highlighting17
- Quote message easily15
- Per-room notification14
- Awesome integration support13
- IRC gateway12
- Star for each message / attached files12
- Good communication within a team11
- Dropbox Integration11
- Jira Integration10
- Slick, search is great10
- New Relic Integration9
- Great communication tool8
- Combine All Services Quickly8
- Asana Integration8
- Awesomeness7
- This tool understands developers7
- Google Drive Integration7
- Replaces email6
- BitBucket integration6
- XMPP gateway6
- Twitter Integration6
- Google Docs Integration6
- GREAT Customer Support / Quick Response to Feedback5
- Jenkins Integration5
- Guest and Restricted user control5
- Gathers all my communications in one place4
- Excellent multi platform internal communication tool4
- GitHub integration4
- Mention list view4
- Easy to start working with3
- Visual Studio Integration3
- Perfect implementation of chat + integrations3
- Easy3
- Easy to add a reaction3
- Clean UI3
- Timely while non intrusive3
- Great on-boarding3
- Threaded chat3
- Intuitive, easy to use, great integrations2
- Simplicity2
- Great interface2
- So much better than email2
- Message Actions2
- Great Channel Customization2
- It's basically an improved (although closed) IRC2
- Eases collaboration for geographically dispersed teams2
- Android app2
- Great API1
- Very customizable1
- API1
- Easy remote communication1
- Get less busy1
- Targetprocess integration1
- Better User Experience1
- Finally with terrible "threading"鈥擨 miss Flowdock1
- Archive Importing1
- Great Support Team1
- Complete with plenty of Electron BLOAT1
- Markdown1
- Multi work-space support1
- Flexible and Accessible1
- Travis CI integration1
- It's the coolest IM ever1
- I was 666 star :D1
- Community1
- Dev communication Made Easy1
- Integrates with just about everything1
- Easy to useL0
- Platforms0
- Can be distracting depending on how you use it12
- Requires some management for large teams6
- Limit messages history5
- Too expensive4
- You don't really own your messages4
- Too many notifications by default3
related Slack posts
Sentry has been essential to our development approach. Nobody likes errors or apps that crash. We use Sentry heavily during Node.js and React development. Our developers are able to see error reports, crashes, user's browsers, and more, all in one place. Sentry also seamlessly integrates with Asana, Slack, and GitHub.
Using Screenhero via Slack was getting to be pretty horrible. Video and sound quality was often times pretty bad and worst of all the service just wasn't reliable. We all had high hopes when the acquisition went through but ultimately, the product just didn't live up to expectations. We ended up trying Zoom after I had heard about it from some friends at other companies. We noticed the video/sound quality was better, and more importantly it was super reliable. The Slack integration was awesome (just type /zoom and it starts a call)
You can schedule recurring calls which is helpful. There's a G Suite (Google Calendar) integration which lets you add a Zoom call (w/dial in info + link to web/mobile) with the click of a button.
Meeting recordings (video and audio) are really nice, you get recordings stored in the cloud on the higher tier plans. One of our engineers, Jerome, actually built a cool little Slack integration using the Slack API and Zoom API so that every time a recording is processed, a link gets posted to the "event-recordings" channel. The iOS app is great too!
#WebAndVideoConferencing #videochat
Kubernetes
- Leading docker container management solution152
- Simple and powerful121
- Open source96
- Backed by google71
- The right abstractions55
- Scale services24
- Replication controller17
- Permission managment9
- Simple6
- Cheap5
- Supports autoscaling5
- Promotes modern/good infrascture practice3
- Reliable3
- No cloud platform lock-in3
- Self-healing3
- Open, powerful, stable3
- Scalable3
- Quick cloud setup2
- A self healing environment with rich metadata2
- Captain of Container Ship2
- Custom and extensibility1
- Expandable1
- Easy setup1
- Gke1
- Golang1
- Backed by Red Hat1
- Everything of CaaS1
- Runs on azure1
- Cloud Agnostic1
- Sfg1
- Poor workflow for development13
- Steep learning curve10
- Orchestrates only infrastructure5
- High resource requirements for on-prem clusters2
related Kubernetes posts











How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.
Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.
After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...
Kafka
- High-throughput116
- Distributed111
- Scalable84
- High-Performance77
- Durable62
- Publish-Subscribe34
- Simple-to-use17
- Open source13
- Written in Scala and java. Runs on JVM10
- Message broker + Streaming system6
- Avro schema integration4
- Robust2
- KSQL2
- Suport Multiple clients2
- Partioned, replayable log2
- Fun1
- Extremely good parallelism constructs1
- Flexible1
- Simple publisher / multi-subscriber model1
- Non-Java clients are second-class citizens25
- Needs Zookeeper25
- Operational difficulties7
- Terrible Packaging1
related Kafka posts










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:
- Our Algorithms Tour: https://algorithms-tour.stitchfix.com/
- Our blog: https://multithreaded.stitchfix.com/blog/
- Careers: https://multithreaded.stitchfix.com/careers/
#DataScience #DataStack #Data










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鈥攖his 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.