We Keep Coding

Possible to connect to an azure event hub through a browser and websockets?

I'm trying to implement a web based chat program, my plan is to update an azure cosmos database with chat messages, then push an event to an azure event hub.
The missing element is for connected web browsers to receive these events.
I tried using the azure event hubs npm package (https://www.npmjs.com/package/#azure/event-hubs) but that looks like it's server side.
Is there a way to accomplish this without having to spin up some sort of server or service?

It sounds like you want to diectly connect EventHub via a browser with websocket, as I known, the only way to realize it is to use AMQP over WebSocket to connect EventHub.
There is a MSDN blog introduce this topic Connect to Azure Event Hub in browser ( using AMQP over WebSockets ), and the other blog of the same author introduce How to use AMQP protocol in Browser (JavaScript). And you can get rhea.js from its GitHub repo https://github.com/amqp/rhea/tree/master/dist.
Meanwhile, according to the information from the source codes of #azure/event-hubs, it seems to support the feature of AMQP over WebSocket in browser, as the figure below comes from the source code https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/eventhub/event-hubs/src/impl/eventHubClient.ts#L259.
And there is a sample code of websockets.ts for EventHubs, and it requires #azure/event-hubs version next in its package.json. I think you just need to use WebSocket in browser instead of WebSocket from import WebSocket from "ws"; in the sample, then you could make it works in browser.

ServiceWorker LifeTime & Push Notifications

i have a question regarding to ServiceWorkers. I know that those Workers may be terminated by the user agent. Will a so terminated ServiceWorker be able to still receive Push Notifications and wake up to them?
If not, are there any information about how long the service is allow to run usually? I'm targeting Chrome on Desktop as well as Chrome Mobile.
I'm curious about how much i can rely on the workers and how much i can integrate them in my further apps.
Edit: What i really did not expected: If i go to this example and manually stop the Service Worker (should be equal to termination trough user agent) and then submit a push notification, the service worker gets resumed.
Therefore i assume that Push Notifications can wake up a terminated service worker. Is there any limitation?

A terminated service worker is still capable of handling a push event. The browser will start up the appropriate service worker when it detects an incoming push notification from the Web Push server (e.g., Google Cloud Messaging). The incoming push message includes registration information, which allows the browser to figure out which specific service worker to start up.
There are some requirements to fulfill in order for the browser to receive the incoming push notification from the Web Push server.
On desktop operating systems, the actual browser process needs to be running. So, for example, if you're a Chrome on OS X user and you quit Chrome, you won't receive any push notifications until you start up Chrome again. (At which point, a bunch might all flow in at once.)
On Android, the connection with the Web Push server is handled via the operating system, and Chrome (and I believe Firefox) does not have to be "running" in order to process the incoming notification and start up the correct service worker.

Listening for events from a server, Chrome extension

I am creating a Chrome extension that will notify users when there is an update to their profile on a service I am running. What's the best way for a server to send updates to a notification?
Ideally I'd like to use something like Server-Sent events to push notifications to the extension. I believe the correct way would be to keep the extension open in the background to listen and act upon messages sent through Server-Sent events, but there aren't many resources on how to accomplish this.

Chrome extensions can access the GCM (Google Cloud Messaging) services directly through chrome.gcm API, it enables extensions to send and receive messages through GCM Service.
Take a look at chrome.gcm and Implementing GCM Client on Chrome, there are very detailed samples.

Are the Push Notifications APIs in Chrome and Firefox OS implementations of the same standard?

Are the Push Notifications APIs in Chrome and Firefox OS implementations of the same standard? If not, is any of them on the road to standardization?

Yes, the Push API that Chrome and Firefox both support is documented in the MDN Using the Push API how-to, which is the web-standard Push API, which in turn relies on web-standard Service Workers, including the showNotification(…) method for the web-standard Notification API.
The HTML5Rocks Push Notifications on the Open Web how-to gives details on using the Web Push API; as it outlines, the basic cross-browser steps (just to crib that how-to’s headings) are:
Register a Service Worker
Set up the initial state
Subscribe to Push Messaging
Set up a Service Worker push event listener
Send a push message
There are other steps that can vary depending on which browser the code is running in.

server-side data push for web services

I´m a web programmer and I'm experienced in regular synchronous and asynchronous web services. So the normal way to get data from a web server is to request it (pull it) or to establish a permanent connection.
Now I'm asking myself if there is any possibility to run this the other way round so that the server pushes new data to the client without a previous request of the client by using native technologies like HTML5 and Javascript.
Summarized: I'm searching for a way to realise a server side push system what works with any modern web browser (IE, FF, Chrome, Safari,...) by using regular technologies like HTML5 and Javascript without any plugins or additional software.
The client should just listen for new data as long as the web site is opened and the only connection from the server should happen if new data gets pushed. It must work even through NAT or Firewalls.
Well main reason is to save server load and data transfer with many connected clients. Please also mind that not each push will be a broadcast, single client push must also be available.
Is this somehow possible or still no way to handle it without extra software?
Thank you

Though it’s not implemented in all browsers yet, you can try using the standard Web Push API.
You can read more on it in the articles Using the Push API & Push Notifications on the Open Web.
The Push API is a W3C standard to let you enable users of your Web app to get push notifications at any time—even in the background; i.e., even when your Web app isn’t running in the foreground on the user’s device (or even when the browser’s not currently running on the user’s device).
It uses Service Workers to handle messages sent using common push services, and to allow your Web app to react to the push notifications it receives.
It exposes a new push event to scripts. Here’s a simple code example from the Push Notifications on the Open Web article that shows how to use that push event to show an actual notification.
self.addEventListener('push', function(event) {
console.log('Received a push message', event);
var title = 'Yay a message.';
var body = 'We have received a push message.';
var icon = '/images/icon-192x192.png';
var tag = 'simple-push-demo-notification-tag';
event.waitUntil(
self.registration.showNotification(title, {
body: body,
icon: icon,
tag: tag
})
);
});
Update 2016-02-12
The Microsoft Edge team recently moved the status of Web Push support in Edge to Roadmap Priority: High — We intend to begin development soon. Since Chrome and Firefox have already shipped support for it, that means
once Edge lands that support, you’ll be able to send standard push notifications to Edge, Chrome, and Firefox users of your Web apps.

There is WebSockets technology, it allows continuous full-duplex connection stream between a client and a server. More detailed here https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications.
WebSocket is standardized protocol and each server supports it.