We Keep Coding

Implementing notifications to web app without using Ajax calls to server or so

Case scenario:
I have few 2k concurrent users access to the website with various devices but using their browsers. Once one of them create new topic, all others currently connected should receive a notification (basically I simple update little icon number in app upper right corner).
One way to accomplish this is to have web app keep requesting updates via ajax calls but that overload my slow server with numerous requests.
I use azure to host my web app (written in PHP). There are some services included in my hosting package such as Event Hub, Service Bus etc. What service could I use in order to have my backed talk to a "service" whenever there is a new post, and than to have that "service" talk to my clients (their browsers) and informing them about new notification or any type of data updates?

You're probably looking for websockets. A websocket sets up a connection between the page in the client's browser and your webserver. Through this connection you can push new topics to all connected clients.
It is advisable to decouple the websocket sending process from the request handling of the topic creation. For this you need a background worker which sends websocket notifications when triggered from a processing event.
You can implement this in PHP using ratchet.

Javascript that communicates with a Hosted API?

Basically I'm developing .NET API that allows a certain Javascript to access a Database through it. The database contains User Information and the API is the mediator between the client (running the javascript on their websites) and the database. The javascript simply gets the data from the DB and displays them.
My problem is, where do I host my API so that the client Javascripts can access it? What is this system called? I'm using Microsoft Azure SQL Databases to store the user information. How do I access my C# API from the client's javascripts? Do I need to host my API on Azure's API Hosting service? Very confused.
1) Client adds the Javascript and a HTML div to their website
2) The Javascript should access the API
3) API accesses the Database and gets the Data (Which is completed and it works)
4) Send the Data to the client and the javascript populates it
I just need to figure out how to make a connection between the API and the javascript on the client's website
Do I need to use THIS?

I would use ASP.NET Web.Api. It allows you to build a REST endpoint in C# that you can host on the Azure platform as well. You will be able to host it using the web sites features of Azure. Even though you want to build an API not a web site hosting it in a web site container will give you what you need:
Easy hosting solutions
Web endpoints for your client JavaScript to consume
C#.NET
Web endpoints close to your database. (Host them in the same data center)
Scalability
Monitoring
Ability to create a web site at the same address if you need to.
I haven't used Azure api management so I can't comment on that, but you will be able to get an ASP.NET Web.Api site up very quickly.

Internet of Things design for jersey and atmosphere

I have a fully working Jersey/Rest application server on an embedded device and am in the process of converting it to websockets with atmosphere-jersey to make it available through a firewall. I've just run into some design questions.
I have around 125 different rest call endpoints. I setup a websocket to a few of them and transferred data back and forth, similar to rest, but with live pushes. Since I built a socket with a subscriber for each endpoint, does this mean I'm actually maintaining a websocket on the browser side for each connecting endpoint? Or is the browser smart enough to hold a single socket open to the same domain and send requests back and forth to each endpoint? If I am maintaining a lot of websockets, then is there a particular strategy to do all communication with multiple endpoints, using a single websocket?
As well, my project is going to require an intermediary service to match up a login to a device of registered socket listeners. Is there a container that takes care of matching up logins to a websocket broker, that I could host with my own webservices (must be free)? Since all of my backend services look like rest, I don't want to have to subscribe each endpoint to the intermediary; so I'm wondering if I need to setup a single websocket broker to handle the traffic and push it out to the endpoints, or if the jersey-atmosphere service is smart enough to handle this?
Edit: added a design question:
In order to communicate between a web browser and a back end server using a single websocket interface; Is there a clean and easy way to generate a POJO for each receiving broker, or will I have to do a JSON conversion as the first step in each class that receives an object? If I build a javascript message with some sort of key to determine the broker, then I could map the key to a class and do a pojo generation for passing back the object to the handler: but it seems like this is a bit clunky and coupled.

Express web sockets and a central server

I'm creating an app where the server and the clients will run on the same local network. Is it possible to use web sockets, or rather more specifically, socket.io to have one central server and many clients that are running native apps
? The way I understand socket.io to work is that the clients read the web-pages that are served from the server but what happens when your clients become tablet devices running native apps instead of web pages in a browser?
The scenario I'm working with at the minute will have one central server containing a MEAN app and the clients (iPads) will make GET requests to the data available on the server. However, I'd also like there to be real-time functionality so if someone triggers a POST request on their iPad, the server acknowledges it and displays it in the server's client-side. The iPad apps will (ideally) be running native phonegap applications rather than accessing 192.168.1.1:9000 from their browser.
Is this technically possible to connect to the socket server from the native apps or would the devices have to send POST requests to a central server that's constantly listening for new 'messages'? I'm totally new to the whole real-time stuff so I'm just trying to wrap my head around it all.
Apologies if this isn't totally clear, it's a bit hard to describe with just text but I think you get the idea?

Correct me if I am wrong.
You have multiple iPads running native app. They send a POST request to your node JS server which is running in a computer in the same local network. Whenever the server receives a request from app, you want to display that a request has been received in your computer screen.
If my assumptions about the scenario is correct, then it is fairly easy to do. Here are the steps to do it.
Create a small webpage (front end). Load socket IO in the front end page like this -
<script type="text/javascript" src="YOUR_SERVER_IP/socket.io/socket.io.js"></script>
Then connect to server using var socket = io(). This should trigger connection event in your backend.
Handle all POST request from apps normally. Nothing special. Just add a small snippet in between. socket.emit('new_request', request_data). This sends new_request event to front end.
Handle the new_request in your front end using socket.on('new_request', function(request_data) { ... });. That's it. No need to add anything to your native app for realtime update.
The second step would be a little complicated as it is necessary to make socket variable available inside all POST requests. Since you chose node.js, I don't think you need any help with that.

Not totally clear on your project, but I'll try to give you some pointers.
An effective way to send data between native apps and a server is using a REST server. REST is based on HTTP requests and allows you to modify data on the server, which can connect to your database. The data returned is typically either JSON or XML formatted. See here for a brief intro: http://www.infoq.com/articles/rest-introduction
Android/iOS/etc have built in APIs for making HTTP requests. Your native app would send a request to the server, parse the response, and update your native UI accordingly. The same server can be used from a website using jQuery ajax HTTP requests.
Express.js is more suited to serving web pages and includes things like templating. Look into "restify" (see here: mcavage.me/node-restify/) if you just want to have a REST server that handles requests. Both run on top of node.js (nodejs.org).
As far as real-time communication, if you're developing for iOS look into APNS (Apple Push Notification Service). Apple maintains a persistent connection, and by going through their servers you can easily send messages to your app. The equivalent of this on Android is GCM (Google Cloud Messaging).
You can also do sockets directly if that's easier for you. Be careful with maintaining an open socket on a mobile device though, it can be a huge battery drain. Here's a library for connecting ObjC to Socket.IO using websockets, it may be useful for you: https://github.com/pkyeck/socket.IO-objc
Hope that helps!

To answer your question, it is definitely possible. Socket.io would serve as the central server that can essentially emit messages to all of the client. You can also make Socket.io listen for the messages from any of the clients and serve the emitted message to the rest of the clients.
Here's an example of how socket.io can be used. Simply clone, npm install, and run using 'node app.js'

All you have to do is to provide a valid server address when you connect your socket from the iPad clients:
var socket = io.connect( 'http://my.external.nodejs.server' );
Let us know if you need help with actual sending/receiving of socket events.

It is possible to connect to Websockets from your apps.
If you are using PhoneGap then you need a pluging that gives support to websockets in your app (the client) and then use websocket like normal way using Javascript see this.
If your app is native iOS look into this it could help you.

The primary use of the Sockets in your case is to be a bidirectional "pipe" between an app and server. There is no need of server sending the whole web-page to the native app. All what you need is to send some data from server to the client(app) in response to POST (or GET) request and then using this data on client side to update client's UI in real-time. If you are going to use moderate amount of devices (say tens of them), you may have connected all of them to the server permanently keeping individual socket connection open for every individual link server-to-app. Thus you may deliver data and update client's state in real time.
In fact web browsers also employ sockets to communicate to web servers. However as in general case there is no control on amount of concurrent clients in Internet, for the sake of limited networking resources conservation, servers do not keep sockets open for a long time, closing it just after the web-page was sent to client (or timeout has expired). That's how HTTP protocol works on the low level. The server waiting for the HTTP clients (browsers) by listening the 80 port, responding them by sending the whole web page content, then closing the connection and keep waiting for another requests on the same port.
In your case it's basically a good idea to use socket.io as it's a uniform implementation of sockets (ok WebSockets) on both client and server side. The good starting point is here

Allow two clients interact without server

Is it possible to allow two clients interact directly without a server?
I am referring to websites, for example is it possible to create a chat between two clients that are on the same website using only javascript on the client-side.
If not, what's the minimum server-side to make a chat work between active clients on a website? (eg: one PHP file and no database) ?
My idea:
Storing the conversation would be easily done using localStorage on each client, the problem is how to send some data from client1 to client2 without storing anything (or at most that message) in the database. Also, note that "past" conversations should not visible, so no storage needed for that.
Note that I don't want any nodeJS or websocket solutions, I want something as simple as possible. So, what's the minimum code and files to make a chat between online users?

The WebRTC APIs will allow JavaScript to initiate a direct browser-to-browser connection, but a server is still required to serve the page and coordinate session initiation.
The APIs are still rapidly evolving and only available in bleeding-edge browsers, so it's not yet ready for real production use.
However—to be honest—for what you're trying to do, the easiest option is Node and socket.io:
var http=require('http'), express=require('express'), sio = require('socket.io')
, app=express(), srv = http.createServer(app);
app.use(express.static(__dirname+'/static'));
sio.listen(srv);
srv.listen(80);
...and now you have a working websockets server in 5 lines. Put all your client-side stuff in the static folder and you're good to go.

HTML5 has got a new Web Sockets feature
With this the server intervention is almost nullified..The server and client communicate through the new protocols
ws - Web Sockets protocol
wss - Web Sockets Secure protocol (similar to https)
Live demo

No, It's not possible. If you want a chat box, you have to store the data in the server. And what connects the clients, like display the chat texts and the same things to every client, they come from the server.. So it's not possible like that. Well, even free chat boxes put the data of each sites in their servers.
As for your idea using localStorage, maybe it's possible (But still, using the new WebSocket protocol), but it doesn't work in the time dimension, right? if another user joins, they won't see what has been sent before.