

Chapter 7: Real-Time Communication - etcher
https://zapier.com/learn/apis/chapter-7-real-time-communication/?utm_campaign=Chapter%207%20Real-Time%20Communication&utm_medium=email&utm_source=blogblogposts

======
coreymgilmore
What about websockets? This is very similar to subscription webhooks, but also
different. Websockets have been gaining in popularity due to easy of use and
implementation and low overhead. Plus, a typical server can hold open
thousands of connections since many might just be waiting for an event to
send/receive.

~~~
denizozger
Agreed. With current browser support
([http://en.wikipedia.org/wiki/WebSocket#Browser_support](http://en.wikipedia.org/wiki/WebSocket#Browser_support))
and fallback libraries (like [http://socket.io/](http://socket.io/)), I
believe WebSockets are usually the best choice when it comes to real time
communications.

------
jkarneges
Webhooks are great, although most "client" applications as commonly known
(browsers, mobile) aren't able to act as servers in order to receive them.

One way around this problem is to route through some kind of bridge service.
We've done this with [http://webhookinbox.com/](http://webhookinbox.com/)
which can receive webhook calls on behalf of clients.

------
romey
Ah, at the title I thought this was going to be about WebRTC, something I'm
pretty excited about, even though it has a quite a ways to mature yet
([http://caniuse.com/rtcpeerconnection](http://caniuse.com/rtcpeerconnection)).

Interesting that they left out websockets. At this point Websockets seem to be
reasonably mature, and with Socket.io/Primus/etc are dead easy to use, and
allow for near-real-time 2 way communication. There do appear to be some
scaling issues past a certain level with websockets though, a topic I haven't
been able to find too much literature about.

As for webhooks, are these more geared towards Server-to-server communication,
like consuming an API on the back end? Is there any chance that in the future
browsers will begin listening on our ports too?

