Differences between webhook and websocket?

Question

I've always wanted to do a real-time chat.

I've done that years ago in PHP+Ajax+Mysql and broke my server.

Then I tried with Flash+ a text file. I gave up and haven't tried in 10 years. But recently I heard about webhooks and websockets.

And they both seem to be a way to do that but I don't really quite grasp the difference.

Anyone can explain?

Thanks!

Stony

Answer 1

Webhooks

Webhooks are for server to server communication. They work by one server telling another server that it wants data sent to a certain url when something happens.

This article talks about some uses of webhooks in popular services. This organization talks a lot about using them in the context of RESTful APIs.

Websockets

Websockets are (usually) for server to browser communication. The server hosts a websocket server, and clients can open a connection to that server. This is popular now mostly because it is faster and less resource-hogging than older ways of solving the problem, like long-polling/COMET.

It is possible to connect 2 servers using websockets, but that is not usually what they are used for.

The confusion

Even though one of these is (exclusively) server-server and one is (mostly) browser-server, these technologies are often discussed in the same places, almost like they are solving the same problems. If you look up the chain high enough, you see that they both solve the problem of "real time" communication, but they solve different aspects of this problem in very different ways.

One situation where there may be a direct comparison is if you are building an API that will be consumed by a third party server. In that situation, you could provide a webhook API or a websocket API. Both allow the third party to get updates quickly:

• If you choose webhooks, that third party will still have to figure out a way to push the changes you are telling them about to their client's browsers.
• If you provide a websocket API, the third party can just set up their site so each of their users connects directly to your websocket API, and their servers have to do less work.

Crassulaceous

Websockets are commonly used for client-server communication but are not limited to that. They can be used for server-server communication as well. – Clemenciaclemency

In both websocket and webhook does the socket stay open constantly? does hooking 10000s of servers resoruce hugging? – Sourdine

Websockets keep a socket open on both the client and the server for the duration of the conversation (this also makes servers stateful, which makes scaling more tricky). Webhooks require a socket to stay open on the server. On the client, the socket is only opened up for the request (just like any other HTTP request). Webhooks could be expensive both on the client (if you need to notify a lot of servers when something happens) or on the server (if you need to listen to updates from a lot of clients), but both just use HTTP, and the are a lot of solutions available for scaling HTTP services. – Crassulaceous

Answer 2

Here is some additional information for choosing between webhooks and websockets.

Server-to-server communications over websockets has become popular with a new generation of chatbot apps. Now, many chatbots run over websockets with provide a primary advantage of not requiring a public facing URL for internal, private bots. In this environment the following are some guidelines on when to consider using webhooks vs. websockets.

Websockets

• If your app is a browser app, use websockets because your app cannot receive webhooks.
• If your app is a server app receiving messages from a service over the Internet and you do not want to open your firewall, consider websockets. Some companies require information security review before opening such connections.

Webhooks

• If your server app app needs to make many subscriptions, either be prepared to handle the volume of open websocket connections to your server (see this article for 1M websocket connections), or switch to webhooks. Some popular chatbots have moved from websockets to webhooks to improve scalability.
• If your server app runs as a cloud function on (AWS Lambda, Google Cloud Functions, etc.), use webhooks because your app will not keep the websocket connection open.
• If your server app is running on the Heroku free tier, use webhooks because your Dyno will go to sleep and must sleep for 6 hours per day, unless you manually instruct your server to sleep.

Boutin

Answer 3

Webhooks

In webhook, we have client and webhook api provider. Client will usually do one time registration. In this registration client defines the events the client is interested in and the callback url that webhook provider sends updates. Whenever there are event updates, webhook provider will send post request to url with relevant information.

• Webhooks are mostly used in server to server communication. Your client makes a payment through stripe and stripe api let your application server that the payment is completed successfully
• api providers has to deal with retry policies in case of failures.
• if client exposes an endpoint to register with a webhook provider that has to be publicly accessible so you have to secure this endpoint.
• webhook represents a single event. A spike in events can produce a lot of noise and your server has to be capable of handling with them. What happens if you have a ton of webhooks from a bunch of different services all coming in at once? This could result in a degraded user experience or even full-blown timeouts.

Websockets

In websocket, you have client and server. The client sends an handshake http request to server. If server agrees to use websocket, then client and server upgrades their communication to a long-lived tcp connection. with this connection is established both the client and server can communicate bi-directionally. A common use case is chat apps.

• Websockets are mostly used in server-to-browser communication.
• Websocket creates bidirectional low latency communication. As the client and server maintain a single tcp connection, the latency is pretty low. On top of this, client and server can both exchange messages at the same time using the same channel.
• Because client do not need to send multiple request, you have reduced overhead of http requests.
• Clients are responsible for connections. they have to handle re connection if connection dies.
• server has to deal scalability challenges. Since clients are essentially establishing a single connection

Shayneshays