What is XMPP and what are its top alternatives?
XMPP, also known as Jabber, is an open-source communication protocol that enables real-time messaging, presence information, and contact list maintenance. It is decentralized and federated, allowing users to communicate across different servers. Key features of XMPP include security through end-to-end encryption, multi-platform compatibility, and support for various extensions. However, XMPP has limitations such as a lack of built-in video conferencing capabilities and a complex server setup process.
- Matrix: Matrix is an open network for secure, decentralized communication that offers real-time messaging, voice, and video calls. It supports end-to-end encryption, bridging capabilities, and integration with other communication platforms. Compared to XMPP, Matrix provides a more modern and seamless user experience but may require more resources for server infrastructure.
- Signal: Signal is a privacy-focused messaging app that offers end-to-end encryption, voice and video calls, and self-destructing messages. It provides a high level of security and privacy compared to XMPP but lacks the decentralization and server customization options of XMPP.
- Wire: Wire is a secure messaging platform that offers end-to-end encryption, voice and video calls, and file sharing. It provides a polished user interface and collaboration features but may not be as customizable as XMPP in terms of server setup and extensions.
- Rocket.Chat: Rocket.Chat is an open-source team communication platform that offers real-time messaging, video conferencing, and screen sharing. It supports self-hosting options for server deployment and customization but may require more technical knowledge compared to XMPP.
- Telegram: Telegram is a cloud-based messaging app with end-to-end encryption, self-destructing messages, and group chats. It provides a user-friendly interface and extensive bot integration but lacks the decentralized and federated nature of XMPP.
- Tox: Tox is a peer-to-peer messaging platform that offers end-to-end encryption, voice and video calls, and file sharing. It provides a high level of privacy and security but may not have as many built-in features and extensions as XMPP.
- Riot.im: Riot.im is a decentralized, open-source messaging app built on the Matrix protocol. It offers end-to-end encryption, cross-platform support, and integration with other communication platforms. Compared to XMPP, Riot.im provides a more streamlined user experience but may require more server resources.
- Zulip: Zulip is an open-source team chat platform that offers threaded conversations, file sharing, and integrations with other tools. It provides a unique conversation threading feature but may not be as customizable as XMPP in terms of server setup and extensions.
- Jitsi Meet: Jitsi Meet is an open-source video conferencing platform that supports end-to-end encryption, screen sharing, and chat functionality. It provides a user-friendly interface and integration with various communication platforms but may not offer as many features as XMPP for text messaging.
- Keybase: Keybase is a secure messaging and file sharing platform that offers end-to-end encryption, secure group chats, and integration with social media accounts. It provides a high level of security and privacy but may not have the same level of customization and extensibility as XMPP.
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’s 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 of3
- Lightweight with a relatively small data footprint2
- Very easy to configure and use with open source tools2
- Easy to configure in an unsecure manner1
related MQTT posts
Kindly suggest the best tool for generating 10Mn+ concurrent user load. The tool must support MQTT traffic, REST API, support to interfaces such as Kafka, websockets, persistence HTTP connection, auth type support to assess the support /coverage.
The tool can be integrated into CI pipelines like Azure Pipelines, GitHub, and Jenkins.
Hi Marc,
For the com part, depending of more details not provided, i'd use SSE, OR i'd run either Mosquitto or RabbitMQ running on Amazon EC2 instances and leverage MQTT or amqp 's subscribe/publish features with my users running mqtt or amqp clients (tcp or websockets) somehow. (publisher too.. you don't say how and who gets to update the document(s).
I find "a ton of end users", depending on how you define a ton (1k users ;) ?) and how frequent document updates are, that can mean a ton of ressources, can't cut it at some point, even using SSE
how many, how big, how persistant do the document(s) have to be ? Db-wise,can't say for lack of details and context, yeah could also be Redis, any RDBMS or nosql or even static json files stored on an Amazon S3 bucket .. anything really
Good luck!
- Realtime backend made easy371
- Fast and responsive270
- Easy setup242
- Real-time215
- JSON191
- Free134
- Backed by google128
- Angular adaptor83
- Reliable68
- Great customer support36
- Great documentation32
- Real-time synchronization25
- Mobile friendly21
- Rapid prototyping18
- Great security14
- Automatic scaling12
- Freakingly awesome11
- Chat8
- Angularfire is an amazing addition!8
- Super fast development8
- Built in user auth/oauth6
- Firebase hosting6
- Ios adaptor6
- Awesome next-gen backend6
- Speed of light4
- Very easy to use4
- Great3
- It's made development super fast3
- Brilliant for startups3
- Free hosting2
- Cloud functions2
- JS Offline and Sync suport2
- Low battery consumption2
- .net2
- The concurrent updates create a great experience2
- Push notification2
- I can quickly create static web apps with no backend2
- Great all-round functionality2
- Free authentication solution2
- Easy Reactjs integration1
- Google's support1
- Free SSL1
- CDN & cache out of the box1
- Easy to use1
- Large1
- Faster workflow1
- Serverless1
- Good Free Limits1
- Simple and easy1
- Can become expensive31
- No open source, you depend on external company16
- Scalability is not infinite15
- Not Flexible Enough9
- Cant filter queries7
- Very unstable server3
- No Relational Data3
- Too many errors2
- No offline sync2
related Firebase posts
Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.
My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.
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
WebRTC
- OpenSource3
- 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-time219
- Node.js143
- Event-based communication141
- Open source102
- WebSockets102
- Binary streaming26
- No internet dependency21
- Large community10
- Fallback to polling if WebSockets not supported9
- Push notification6
- Ease of access and setup5
- Test1
- Bad documentation12
- Githubs that complement it are mostly deprecated4
- Doesn't work on React Native3
- Small community2
- Websocket Errors2
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 server32
- Real-time25
- Free18
- Fallback to SSE, forever frame, long polling16
- WebSockets15
- Simple10
- Open source9
- Ease of use8
- JSON8
- Cool5
- Azure0
- Expertise hard to get2
- Requires jQuery2
- Weak iOS and Android support1
- Big differences between ASP.NET and Core versions1
related SignalR posts
We need to interact from several different Web applications (remote) to a client-side application (.exe in .NET Framework, Windows.Console under our controlled environment). From the web applications, we need to send and receive data and invoke methods to client-side .exe on javascript events like users onclick. SignalR is one of the .Net alternatives to do that, but it adds overhead for what we need. Is it better to add SignalR at both client-side application and remote web application, or use gRPC as it sounds lightest and is multilingual?
SignalR or gRPC are always sending and receiving data on the client-side (from browser to .exe and back to browser). And web application is used for graphical visualization of data to the user. There is no need for local .exe to send or interact with remote web API. Which architecture or framework do you suggest to use in this case?
- Easy to integrate with1.2K
- Excellent interface on multiple platforms876
- Free849
- Mobile friendly694
- People really enjoy using it690
- Great integrations331
- Flexible notification preferences315
- Unlimited users198
- Strong search and data archiving184
- Multi domain switching support155
- Easy to use82
- Beautiful40
- Hubot support27
- Unread/read control22
- Slackbot21
- Permalink for each messages19
- 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
- Asana Integration8
- Combine All Services Quickly8
- Awesomeness7
- This tool understands developers7
- Google Drive Integration7
- XMPP gateway7
- Replaces email6
- Twitter Integration6
- Google Docs Integration6
- BitBucket integration6
- GREAT Customer Support / Quick Response to Feedback5
- Jenkins Integration5
- Guest and Restricted user control5
- Gathers all my communications in one place4
- Clean UI4
- GitHub integration4
- Excellent multi platform internal communication tool4
- Mention list view4
- Perfect implementation of chat + integrations3
- Android app3
- Visual Studio Integration3
- Easy to start working with3
- Easy3
- Easy to add a reaction3
- Timely while non intrusive3
- Great on-boarding3
- Threaded chat3
- Eases collaboration for geographically dispersed teams2
- Message Actions2
- Simplicity2
- So much better than email2
- It's basically an improved (although closed) IRC2
- Great Channel Customization2
- Great interface2
- Intuitive, easy to use, great integrations2
- Markdown2
- API1
- Easy remote communication1
- Get less busy1
- Targetprocess integration1
- Better User Experience1
- Multi work-space support1
- Travis CI integration1
- It's the coolest IM ever1
- Dev communication Made Easy1
- Community1
- Integrates with just about everything1
- Great API1
- Very customizable1
- Great Support Team1
- Flexible and Accessible1
- Finally with terrible "threading"—I miss Flowdock1
- Archive Importing1
- Complete with plenty of Electron BLOAT1
- Watch1
- I was 666 star :D1
- Easy to useL0
- Platforms0
- Can be distracting depending on how you use it13
- Requires some management for large teams6
- Limit messages history6
- Too expensive5
- You don't really own your messages5
- Too many notifications by default4
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 solution164
- Simple and powerful128
- Open source106
- Backed by google76
- The right abstractions58
- Scale services25
- Replication controller20
- Permission managment11
- Supports autoscaling9
- Cheap8
- Simple8
- Self-healing6
- No cloud platform lock-in5
- Promotes modern/good infrascture practice5
- Open, powerful, stable5
- Reliable5
- Scalable4
- Quick cloud setup4
- Cloud Agnostic3
- Captain of Container Ship3
- A self healing environment with rich metadata3
- Runs on azure3
- Backed by Red Hat3
- Custom and extensibility3
- Sfg2
- Gke2
- Everything of CaaS2
- Golang2
- Easy setup2
- Expandable2
- Steep learning curve16
- Poor workflow for development15
- Orchestrates only infrastructure8
- High resource requirements for on-prem clusters4
- Too heavy for simple systems2
- Additional vendor lock-in (Docker)1
- More moving parts to secure1
- Additional Technology Overhead1
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...
- High-throughput126
- Distributed119
- Scalable92
- High-Performance86
- Durable66
- Publish-Subscribe38
- Simple-to-use19
- Open source18
- Written in Scala and java. Runs on JVM12
- Message broker + Streaming system9
- KSQL4
- Avro schema integration4
- Robust4
- Suport Multiple clients3
- Extremely good parallelism constructs2
- Partioned, replayable log2
- Simple publisher / multi-subscriber model1
- Fun1
- Flexible1
- Non-Java clients are second-class citizens32
- Needs Zookeeper29
- Operational difficulties9
- Terrible Packaging5
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—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.