What is the best infrastructure for OTT channels like telegram? - chat

We have a OTT application which deliver message to users over XMPP protocol. we using eJabberd to deliver messages. also we have group chats that user can use them with maximum of 200 users.
Now we want to build channels. some think like Telegram channels.
it seems similar application like Viber and Telegram using different infrastructure for channels.
Now the question is what is the best infrastructure for channels (server side and client side)?
where is our start point?

There is many approach you can use to build such system. A tool like ejabberd has been designed to build that type of system. It is scalable and fully extensible through a built in API. This would be a good bet as many OTT services are already built on top of ejabberd.

Related

Rest/Graphql apis and event driven architecture

I've been looking at the event driven architecture and it's seems it might be the right architecture for a project I'm working on.
But there is one thing I don't really get yet, what is the best practice/common pattern when your micro services are being consumed by front-end applications?
For my project, I have a web app and an iOS and Android app.
Let's take a simple case of a feature letting users create their profile.
Let's say I send the profile data via REST/GraphQL to the api endpoint which triggers microservices (running behind Kafka or Pulsar).
How can I get the result of the profile creation and then maybe use it on the next screen?
Cheers
websocket calls to Pulsar will do most of what you want https://pulsar.apache.org/docs/en/client-libraries-websocket/
You could also call Apache Pulsar via MQTT which is not too uncommon from cell phones.
Or use a REST gateway or microservice between the app and Pulsar services. I use Apache NiFi for that.

XMPP chat infrastructure recommendations

There is a chat project I plan to develop and currently stuck while deciding, which XMPP server and client to use.
Front-end will be implemented using Ionic 3+ framework (fixed requirement).
Main features:
private chat capability (1 on 1)
group chat capability (and ability to add users to existing chat)
online status visibility
offline message delivery (online user sends a message to offline user, and the offline user gets it after going online, etc)
full-time server-side chat history storage
I need to select:
a client library which is convenient to implement with Ionic 3+
a server which enables all the above requirements
Also, the chat messages should cross the network with at least some kind of encryption.
Currently, I have been playing with these server options:
eJabberd - most people recommend this option, but for me, a person, who is newbie at XMPP stuff, it looks like there will be quite a lot of hassle with configuration
openFire - easy to setup and use, but it uses Java VM, and some people argue, that it has problems with performance and memory management.
I also stumbled upon AstraChat - a commercial product, that looks similar to what I need - however, with fixed implementation of it's own public apps - no way to use it's code base.
As of front-end - I have only tried running the Ionic 1 tutorial locally using Strophe.js as the client in the front-end. Since I am developing the app with Ionic 3+ (TypeSript), it would be awesome to use some newer and TS compatible library - however, it is just a wish, not a requirement. :)
Maybe there are some better and more convenient non-XMPP implementations for this concept. Any thoughts are welcome!
eJabbered is very complex decision for your application.
openFire is also very complex and requires JVM
For your apllication I advise Prosody. It is simple and lightweight desicion.
https://en.wikipedia.org/wiki/Comparison_of_XMPP_server_software
But please think twice about using chat on XMPP protocol. This protocol is very difficult to learn and it has a variety of extensions(e. g. XEP) and you will be confused about documentation.
Alternative https://github.com/actorapp/actor-platform
but documentation is obsolete.

Difference among Comet servers and XMPP servers

In my next planned project I suppose to implement an online classroom website in which I want to share a black board (Say a simple text area) among the Tutor and the participating online students {These all are logined through the website}. Whatever the text Tutor writes over the Black board has to be seen by the other participants in Real-time.
I want to use Java as my development platform.
To implement this I started googling on PUSH technology. I read that XMPP implementation servers and XMPP libraries can be used to implement near-realtime applications like collaberative applications/mutiparty games/IM applications etc.,
But I also read about BlazeDS usage for real-time and low-lattency web applications.
My questions are,
what is the difference among these XMPP java based implementation and BlazeDS? Is not both the techs final goal is to achieve low-lattency web apps using PUSH technology?
What is the difference among Comet servers and XMPP Servers? Do they just differ in the way they implement the PUSH technology or any thing else?
I am confused. Please someone explain me these little more so that I will know what I do before I do the things and where to start on next in my project.
Thanks
To answer your first question: No, XMPP's goal is not simply to "achieve low-latency web apps using PUSH technology". XMPP far pre-dates the "realtime web", and is a much more extensive platform than basic comet/push servers.
Features in XMPP that won't typically be in plain push servers include:
Support for non-web clients (including existing desktop clients)
A choice of authentication methods from strong credential-based mechanisms such as SCRAM-SHA-1 to temporary anonymous accounts
Support for federation (communication with other XMPP servers)
Lots of chat-centric capabilities available (contact lists, offline messaging, file transfers) - this can be a bonus or worthless, but most features like these can be disabled in some XMPP servers.
If you are just looking for a component to push messages to website visitors in realtime, and you're using Java which BlazeDS integrates tightly with, then BlazeDS is probably your best choice.
If your push system is part of a larger realtime platform which may involve multiple clients (including non-web for example), multiple languages, and even possibly multiple servers (e.g. you could allow users to use existing XMPP accounts to receive updates) then XMPP is more than likely worth looking into.

How would services like yammer be using xmpp? does xmpp cross paths with a queue?

How would services like yammer be using xmpp? does xmpp cross paths with a queue? i.e. could one use rabbitmp instead of xmpp or are they completely different things?
Sorry about the late answer, but late than never.
I am more of a XMPP developer and have little experience with rabbitmq but yes you can use rabbitmq instead of XMPP if your application needs are satisfied by rabbitmq.
XMPP have exhaustive implementation of Multi-User Chat and PubSub which can be used if rabbitmq alone is not enough to satisfy your application need.
Can you expand "does xmpp cross paths with a queue"??

War room Message center

Looking for ideas on how to implement a kiosk style/full screen client that will display messages sent to it, in realtime or push based. Basically, think a 911 dispatch center call board. I was thinking a xmpp bot to display, and making a simple xmpp client that can only send messages to the bot.
This is for a very small emergency disaster agencies war room, and only needs to be able to display simple messages entered in from one of the computers in the building. Is XMPP a good solution for this?
An IM protocol like XMPP is an acceptable solution for this.
XMPP seems to fit the bill, it is mature and has many clients that support it so it would not be necessary to write a client, just set up a regular IM client to send to the "buddy" that is the big board.
Are you looking at the problem backwards? Describe what you want to do a little more THEN seek advice on protocols. It smells like you might be designing around a protocol rather than designing around your requirements.
This should be as simple as a single HTML page, running full screen, using Strophe.js and an XMPP account. Strophe is an easy-to-use XMPP library in Javascript.
Something like the basic.{html,js} example here should be pretty much what you want:
http://code.stanziq.com/cgit/strophe/strophejs/tree/
Sounds like a simple pubsub setup (XMPP will work for this) where the clients are all publishers and the War room is the only subscriber. This eliminates the need for rosters so it keeps the intial configuration pretty simple.
I don't know what language you prefer to use, but it would be rather simple in Smack using the pubsub API and any XMPP server you prefer that supports the pubsub extension. (You will need to build Smack from source though as that particular API is new and not in the release version yet.)