With Pusher and Beacon push cloud services I can get live updates in all browsers. Even implement chat functionality.
Can't these cloud services replace the need of me learning XMPP/AMQP/Websockets/Comet to implement the same kind of live updates/feeds?
These services offer Infrastructure as a Service so that you don't have to worry about the underlying technology. That said the services do use the technology as a selling point e.g. Pusher very much use WebSockets to sell their service.
As well as Pusher there are similar services so I'd recommend checking out the real-time tech guide for others that haven't been mentioned (I work for Pusher).
Can't these cloud services replace the need of me learning XMPP/AMQP/Websockets/Comet to implement the same kind of live updates/feeds?
Yes. The point in these frameworks and services is to abstract away the underlying connection and protocols to provide you with a reasonable real-time communication pattern (simple messaging, pub-sub, evented pub-sub, RPC/RMI or DataSync) that works for the application functionality that you are looking to build.
Related
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.
I understand (somewhat) what are differences between monolithic , microservices .
And also what is SOA it is a service consumer/provider architecture and microservice is subset of SOA. and they use Restfull/SOAP APIs to communicate.
So when a a request something he/she does using Rest/SOAP API but how in a Monolithic architecture a client request through which API? I searched all the links/blogs on google, videos on youtube but still I am not clear about this.
Or may be my whole understanding is not correct.
Sounds like you are a bit confused, I would really recommend you picking up a book on the subject.
Monolithic vs micoservice application is more about how you package and deploy your application and in some sense how coupled modules/subsystems are. The extreme example: you always deploy the entire monolithic applications for the smallest possible change, and in the microservice example you just need to make the same change to one service.
Rest API and SOAP are protocols for how (http) messages are passed between client <-> server and has nothing to do with monolithic vs micro.
Monolithic application can of course have public http API's, and it might not be possible for a user (sending request) of that API to tell the architecture style of that application. And why would she care about that?
I think this is a nice start: https://martinfowler.com/articles/microservices.html
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.
I use OmniFocus a ton and I'd really like to be able to connect my data there to other things (Zapier, IFFFT, Beeminder, etc). There's a lot of support for putting data into OmniFocus through these services, but I can't find any support for getting data out of OmniFocus.
In thinking about this, I realized my question isn't really about OmniFocus but rather about building a connector to a service that I don't own. So this is my scenario:
I have data on some publicly accessible web service (in the case of OF, it's Dropbox)
I want to build and host some sort of application that accesses that data and parses it and then provides a REST API that other servers can then query.
Ideally I'd like to make this service available to others - this seems tricky because they have to somehow enable my application to read their data.
I'm a fairly experienced software dev but I have zero experience with web applications or cloud applications. I'm not looking for a super in-depth answer here, but more of a general sketch of how this would work (or a confirmation that this really isn't feasible).
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.