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

Answer 1

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 sever (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.

Answer 2

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.