From the documentation I could figure out that Push API and Server Sent Events both are half duplex but why two different technologies for the same functionality? Is there something more significant in Push API?
Asked
Active
Viewed 9,455 times
29
sideshowbarker
- 62,215
- 21
- 143
- 153
Rishul Matta
- 2,988
- 4
- 21
- 29
-
4I'm confused too but just found push-api team's mention about Server-Sent Events. https://github.com/w3c/push-api/issues/104#issuecomment-69745798 – Donghwan Kim Mar 29 '15 at 14:27
2 Answers
22
The Push API allows the server to send a notification to a client even when your site is not open, because it relies on service workers.
SSE (or WebSockets) work as long as the user is using your site.
There are some examples (with documentation) in the Web Push section of the ServiceWorker Cookbook that can help you understand this better.
Marco Castelluccio
- 8,715
- 2
- 27
- 45
9
You use Server Sent Events to connect directly to your website, it's fairly easy.
Web Push technology is much more complicated, a user's browser maintains one connection to the browser vendor's push server, which collects and delivers all pushes from websites (multiplexes them). Since the messages go through the third-party server, they should be encrypted. To use the Push API you (on the client side) get a browser-specific vendor's endpoint URL, generate a public encryption key, and send it back to your server for use. Then on your server when you want to push, you encrypt the message using the key and push it to the endpoint.
Firefox maintains an active connection to a push service in order to receive push messages as long as it is open.
This is the main advantage of Web Push - you can deliver the notifications just as user opens the browser, he won't have to visit your site. The disadvantage is that you'll need to get a permission from user for this subscription. Another disadvantage is that it's far from being widely supported currently.
user
- 16,328
- 6
- 89
- 89