I need to develop a realtime notification system. Load won't be high, about a dozen of events per hour. But I just want to make it scalable for future development.
My application is written entirely in PHP.
I have found different ways of implementing real-time applications. And I think the following architecture is quite simple and have a lot of benefits.
But I want to use the Faye library for implementing real time notifications, because it has fallbacks, and generally I am not going to use Websockets because my load is really low, and at first I will stick to the long-polling mechanism. Faye provides a convenient way for disabling and enabling different transport protocols.
Here is how my architecture is going to look
However I have one question regarding communicating back from a client.
Consider the following case.
Client loads a page through plain old HTTP request to a PHP app
Client side script opens a websocket/long polling connection
Another person sends notification via posting it through a simple AJAX request
This notification is saved to a database and assigned to a target recipient.
Notification is posted to a Redis database and consumed by Faye
Notification is sent to a client, everything is fine.
So far so good, but I need to some sort of back communication, for example when a client dismisses an event.
How should this be implemented, should I send this action back using Faye or this should be sent directly to the PHP application. In case of sending an event back using Faye I need to notify my PHP application that an event was seen and dismissed. Of course I can use the same database from a Ruby application as used by PHP app, but this makes these two application coupled.
Could you suggest a right way to implement this ?
Related
I am trying to implement a very simple self-hosted (docker) pubsub client update system using websockets or SSE for my PHP application.
I would like that a specific javascript action on my website triggers a php server-side update (via ajax) which should then lead to an update to all subscribed devices for the particular channel/topic. The subscribed devices should use javascript listening to one channel each.
Do you know any simple PHP ws libraries which are capable of that? Can SSE be triggered in that way and also utilize channels? How about in-built PHP socket function? Ideally I would like to stick to PHP solution in order not to deal with translations and in-between REST APIs.
After researching this for days and going through solutions like RabbitMQ, Redis, Kafka, RatchetPHP, ZeroMQ, socket.io, RPC, SSE and etc I am completely lost. I need some guidance on which way to go.
Among all possible solutions here is how I would do it:
Install a web socket server, preferably implemented in PHP, on you Linux system.
Your web clients register with the server and listen for messages like broadcast from the server.
Your ajax script registers also with the server and sends a broadcast to the server if all work is done.
The server passes the broadcast to all registered clients.
You could use my implementation of such a web socket server that comes with all the needed client
libraries for JavaScript as well as for PHP that implement broadcast and feedback.
See https://github.com/napengam/phpWebSocketServer
I have a project were I am required to add push notification for Cordova AngularJS Push Notification using PHP on server side which gives JSON array as output. I can implement chat etc using this, but I want to know how to implement it in push notification or accessing native app API. Firstly I thought using Javascript SetInterval, but it slow downs the app, and checks the API everytime...
For Cordova push notification you can take a look here:
http://phonegappro.com/tutorials/apache-cordova-phonegap-push-notification-tutorial-part-1/
Still, let's review some other methods of sending data to the client using Web APIs:
Long polling - keep the connection open on the server side with no or long timeout, and return a result when you want to send a push notification.
Use WebSockets - open a steady TCP connection to the server and transmit messages in both directions (unlike HTTP's request/response model).
Use PushManager - this is an experimental technology that is not yet supported on mobile devices, so I guess this is a no-go for you.
Use simple polling - every now and then poll the server for a new message.
Long polling and Web Sockets will overload the server if you'll have a lot of concurrently open connections, so I wouldn't go there. Also Web sockets are mostly used for communicating between clients (server passes the client info to both clients, then they can communicate on their own without the sever intermediating between them).
PushManager is too new a technology not yet supported in mobile.
For what you want (mobile I guess, as you want to use Cordova), and without knowing what you are actually trying to achieve, I would say go with #4. I understand you already tried it, but perhaps try to lower the polling rate to every 30 seconds or so.
I understand that while debugging it doesn't seem nice to send something from the server then wait the better part of a 30 seconds period until it appears on the client, but if you think of it from the user's view point you'll see that the user doesn't know when the server sends the data, so it does appear immediate.
However, if you're writing a chat client, then I would go with web-sockets, using the server to connect the two (or more) clients in the chat and letting them pass the messages directly. If you want the chat to be server backed, just periodically send the transcript to the server using simple AJAX.
DIY vs Hosted Realtime Data Stream Network Service
If you do not expect to have more than a few thousand clients using your app, the DIY (do it yourself) sockets technologies (WebSockets, Socket.io, etc) is feasible. Beyond a few thousand (many of our customers say in the range of 5 to 10 thousand) you will experience difficulty (and large expense on server resources and scalable code) scaling your service.
Using a hosted realtime data stream network service like PubNub, Pusher, Ably, etc will be less costly and complex and it will just work. With some of the hosted services (PubNub for sure - which I work for - full disclosure) provides the ability to publish the message in realtime and include a push payload (for GCM, APNS and MPNS) that will also send the push notification if the app is in the background or not running.
With PubNub BLOCKS, you can also implement server side code that runs in the PubNub Network to inspect, manipulate or process the message without having your server do the work. This means you could send the message to other third party services: translate message to another language, use AI services for whatever reason, send an SMS/email/etc and much much more.
I need to develop a web application with a chat feature, and I would like to know if there are any sophisticated ways to create a realtime web-application with a push engine.
I know jQuery, and I can handle to create a chat web-application which, in the client side, check every period for new messages, and show them, but I don't like this solution and I was wondering if there are any better ways to do it.
In my research I discovered the existence Ajax Push Engine project, and it looks like what I need, but when I was navigating in their website I found it not very well done and somehow incomplete, so I was wondring if there API is stable enough to be put in a production environment if not are there any other solutions?
Sorry if I made it long, any help/hint/link/suggestion would be very welcomed :)
EDIT
I would like to specify that I'm working with PHP in the server side
Here is an implementation in NodeJs.
http://dhotson.tumblr.com/post/271733389/a-simple-chat-server-in-node-js
I recently (year 2012) developed an application in ASP.NET MVC3 where I used SignalR for real-time messaging between server and client. At their own site, they describe SignalR like this:
ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is "real-time web" functionality? It's the ability to have your server-side code push content to the connected clients as it happens, in real-time.
... and they give the following example of what you can use SignalR for:
SignalR can be used to add any sort of "real-time" web functionality to your ASP.NET application. While chat is often used as an example, you can do a whole lot more. Any time a user refreshes a web page to see new data, or the page implements Ajax long polling to retrieve new data, is candidate for using SignalR.
Further, based on my experience, I believe it is very simple to set up, easy to use, and have a good github page with well-written documentation that gets you going in no time. I can highly recommend it :)
I'm new to websocket and realtime applications and I would need some clarifications.
I developed an application for a customer that involve some users and product data.
It is a PHP web application running on the internal apache server.
The client side of the app is based mainly on JQuery, and for some parts usable from tablet devices we used JQuery mobile / html5.
Now the customer is asking to add some messaging/notification feature in this way:
a user will be able to post a message about a product and the web console of the other users must be "showed" a realtime notification. We are thinking to add something for example in the header of the page to notify that new messages are present.
I made some research and as all the app is already built in PHP I was thinking to go for Ratchet. Is this a good idea?
If I understood this well, I will need to install on the server also the ratchet server components and use for client side integration something like AutobahnJS library; is it right?
Has anyone already built something like this?
Is there any problem communicating between Apache and Ratchet server?
That okie,
I tried use Ratchet/AutobahnJs Websocket, that's awesome. But I have (special?) problem :o in here.
In your case, I think you can use AJAX, it's simpler than Websocket. You can "zip" multi-notifications in to 1 response and request server every 5 seconds.
Yeah it's a good way to go about it, ajax leaves you with a lot of overheads. it's pretty simple to get going with ratchet and it will give you the ability to send notifications in real time, as well as the notifications it will allow you to edit the page as well, i.e change counters/ icons / message count etc, basically same as ajax only in realtime and no need to poll for new data.
It also means you'll be learning some new stuff which is always a bonus, for this alone i would do it.
let me introduce my story first. To develop a multiplayer network game in facebook, flash used to be a king but it consumes a lot of resources for client and I feel like it isn't worth for a card game. So I come with an idea that front-end will use Javascript (of course with jQuery) and backend with PHP. But for real-time communication, it isn't possible just with PHP and Javascript. It doesn't make sense to record every movement of players in MySQL and display back to another browsers. So I come with an idea with XMPP Services. XMPP services can even communicate browser to browser and display contents with Strophe and Javascript even without with PHP.
Finally, I've got every tools I need but I have few questions that I can't answer myself.
1) How XMPP server work between PHP and Javascript? I need to get/post user records from MySQL and calculate movements then forward results to intended user. There will be an Authentication system too so that's gonna be taken care by PHP as I'm not wrong.
2) This question is the title of this post.. Is it possible to run XMPP based PHP and Javascript Multiplayer Network Game in FaceBook?
Thanks in advance for all of your time and advices!
The connection would work using PHP sockets, and you could easily use Ajax to send data to PHP to send on to the XMPP server. There are also a number of libraries for communicating with XMPP servers using PHP. As for Facebook, it shouldn't have any effect on your script - if I remember correctly Facebook runs your app in its own sandbox so you shouldn't have to do anything special to get around the Facebook API.