Develop Reference

Advice on which technology to use for real time notifications

I have X amount of activity sensors connected to a server that inserts data to a database everytime a sensor is triggered. What I'm trying to do is create a web interface with a blue print of the facility (svg) and whenever a sensor is triggered, besides the db insert, I want it to show some sort of alert in my blue print. For that I need to keep an open connection to the server I think.
I was thinking of using web sockets, but it might be overkill since I only need to retrieve data from the server. But running an ajax call every second doesn't sound very efficient either. Are there any other alternatives?
Thank you

Some potential choices include:
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
Which actual transport you end up using will depend on the your requirements for browser support and what technology you are using on the server to handle these requests. The transport choice may also depend on your network topology - what types of load balancers you need to integrate with, proxies, etc.
There are many libraries available on both the client and server sides, many of which support more than one of these transports.
For example (not an exhaustive list):
socket.io for nodejs
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
SignalR for an asp/.net backend
WebSockets
Server-Sent Events
ForeverFrame
Long Polling
Atmosphere for a java backend
WebSockets
Server Side Events (SSE)
Long-Polling
Forever frame
JSONP
IMO - Websockets is NOT overkill for this type of problem and would lend itself nicely to this type of application.

Without specifically discussing frameworks or knowing what is running in the backend of your server(s), we have a few options to consider for the frontend:
Websockets
Websockets are designed for bidirectional communication, although it is kind of shocking how many users are surfing the web in a browser that doesn't support websockets. I always recommend a fallback for this, such as the other methods listed below.
SSE
SSE is an HTML5 spec and is still shaky at best. Try scrolling on a page while when an SSE event fires... It may be a little easier on the backend, put it sometimes hangs on the client side since it runs inside the same thread that the DOM is running in.
Long Polling
Keeps your connection open. It doesn't scale well with PHP, but performs swimmingly with Python+Twisted on the backend, or Node.Js
Good Old Ajax
Keep your requests small, and you still have a scalable solution. Yes, a full GET request is the most expensive, but is supported in just about every browser rolled out the past ten years. It is also worth noting that GET requests are easy to scale horizontally with more hardware.
In a perfect world:
You would break up your application into a few components, operating behind a reverse proxy such as Nginx. Then use Node.Js + Socket.IO handle the realtime aspects of your app.
Another option would be to use small Ajax requests, and offer websocket support for the browsers that support it. This is advice specifically for PHP in the backend.

WebSocket is certainly not overkill. On the contrary. With websockets, you have a bi-directional communication channel; this means, that the server can initiate communication whenever it seems fit (e.g. when sensor data changes).
In a previous project, I have used node.js together with socket.io, to monitor 50+ sensors. Data was updated in real-time in a browser. The data was visualized using smoothie.js.
Whenever a sensor value was updated, it was communicated to the browser. Some sensors only updated once a minute, others once a second, ...
Polling would have been overkill, because it would retrieve all data for all sensors, even from those that were not updated yet.

I had a similar problem and did a lot of research on this. As I understand it, there are three main options:
Short polling: Have an endpoint that your javascript client pings every second. This is the worst option, because the pings add latency up to one second to your communication, and depending on how you implement, the endpoint could query the database every second, adding unnecessary overhead.
Long polling: Have an endpoint that your javascript client pings that holds the connection until a) the event occurs or b) the connection times out. If the endpoint returns a response, the client gets the event information. If the endpoint does not return a response, no event has occurred, and the client sends a new request. This is a good option because the events can immediately trigger the response to the client, assuming you have an asynchronous interprocess communication layer (like 0MQ) to send the message without any sort of polling.
Websocket: Have your javascript client connect to a websocket server, which will send a message to your client immediately upon the event trigger.
I think a websocket is your best option, because it accommodates immediate communication of the event without all the request/response overhead. And most importantly, this is exactly what websockets are designed to do! As such, you will probably have to write the least amount of custom code with this solution.

There are two great commercial services that might work for you.
Firebase - a javascript hierarchical database and realtime
messaging/ synchronization platform, uses websockets and has other fallbacks
PubNub - a real time message passing and queue system, uses websockets

java script server async events

I have a web server which I want to send data to the client when the server detects a change in the data base. I want the client to receive the data without polling.
What is the best way to achieve this?
(I read a bit about SSE - server sent events, but not sure this is the way to go)
Thanks

Yes, Server-Sent Events is appropriate technology for listening to changes on the server.
If you're only listening, then SSE is better (faster, lightweight, HTTP-compatible) than a 2-way WebSocket.

If polling is not an option, you can think about the better technique, WebSockets, if your server supports it (and your target browser!).
One way or another, you need a connection opened by the client to the server, though.

The answer would vary depending on the freedom you have with client-side Javascript.
If your app gives you complete freedom, you could even set up your client to be a JMS listener and communicate JMS messages from client to server. For ex, you can use Apache Ajax.
Another option is to set up your web client to be redis client using, for ex, Webdis
As you have mentioned, Server-sent-events is an option too, so is WebSockets.
You need to choose based on your constraints.

Is it bad to use socket.io for most of the requests or should I only use it to push data to client?

Is it bad to replace AJAX routes (called with $.Ajax from jquery) such as:
GET /animals
GET /animals/[id]
POST /animals
With socket.io events (event binded on client and server so the client can have a response):
emit("animals:read")
emit("animals:read", {id:asdasd})
emit("animals:write", animalData)
or should I "only" use socket.io it to push data to client?
[EDIT]
I could see one problem if I don't use socket io for my POST route. The problem is that I can't easely use the client's socket to broadcast data:
Server:
on("animals:write", function(data){
saveAnimal(req.data)
socket.broadcast(...)
emit("animals:write", writenAnimal)
})
VS
app.post(function(req,res){
saveAnimal(data)
// cant broadcast :(
res.send(201,writenAnimal)
})
I will push data to clients in some other requests for sure, so all clients will have at least 1 socket.

IMHO socket.io should be used if you want real-time data provided for your website. Take for example Stackoverflow. It uses websocket to update in realtime your scores and update your notifications.
But if you really want to create application that is SEO-friendly ( I mean supporting http for serving your pages ) and more important if you are aware of the difficulties in managing sessions and permissions in socket.io, I think you'll prefer AJAX for your pages and socket.io for other realtime data.

I would use ajax for this, its http based data requests, nothing realtime.

If you don't want to push data to the client, I don't see why you would use socket.io instead of AJAX. I mean with AJAX you don't need to handle a session with the client and it would probably scaled better.
With socket.io, for every connected client you need some sort of object on the server paired up with that one client. It will use more memory on the server for no reason if permanent connections are unnecessary or unwanted.
Also, AJAX will be better if you want to re-use your code with other systems, it is working with a huge existing ecosystem of tools.
That being said, if you need WebSocket features like pushing the data to the client or doing some kind of broadcast, you might consider using socket.io instead of AJAX since it will be hard to achieve this with AJAX and socket.io offers those features.

Javascript remote events?

Is it possible to have a web service notify web clients when something occurs via HTTP request/response? Right now my client has to poll the server using HTTP Requests at an interval to check for updates, but it would be far more convenient if I could register a javascript function to the server from my client and have it be simply called when server state changes.
Note that the web service is written in Python and utilizes HTTP APIs (I think it uses cherrypy, if that's relevant).
If this is possible could someone point me to some tutorial that explains how to do this or give me a basic understanding of how this can be accomplished?

Look into Comet

You can't start a request from the server to the client. You can only poll the server (which you did), use a hidden iframe, use a plugin, or use the new HTML5 WebSockets which allows the server to send a message to the client.

If you are into Node.JS, look into socket.io and hook.io
https://github.com/hookio
https://socket.io

callback javascript

I write a browser game (php, javascript) and I do not know how to make a callback. necessary that the server itself
found a client and call the function (only had one)

Don't write a browsergame if you don't know the basics! Browsergames are way too complex to learn programming.
If you want to make the server notify a client about something you will need to keep a connection open (search keywords: COMET, long polling) as you cannot initiate connections from the server to clients.

For this I can suggest you using Firebase. It is a API that let you to add cloud Data management that your user clients do. You can use that communication to search for client.

If I understand your question, what you need is a socket. Since you're using PHP and Javascript, a WebSocket might be just what you're looking for. With WebSockets, the connection between the client and the server is persisted, so the server can just push data/messages to any or all of the clients connected to it at any point in time. Likewise, the any client connected to the server can push messages/data up to the server.
Here's a video that describes how it works a bit https://www.youtube.com/watch?v=oJxWhmt5m-o