I'm currently building a realtime application using Node. I'm using socket.io to power my real-time interactions, but have jQuery loaded, so I have AJAX available to me. I initially used socket.io for all my communication between the server and client.
I'm starting to think that AJAX might be better suited for certain cases like doing RESTful transactions asynchronously, because I don't have to write a separate message case in my socket to handle each new transaction as well as write the RESTful routing.
I'm wondering if I am on to something or if its best to use sockets for performance or something else I'm not thinking about.
Thanks!
Matt Mueller
Yes, WebSockets (RFC 6455) and Ajax are quite different and serve different purposes.
As you say, with Ajax you can do RESTful requests. This means that you can take advantage of existing HTTP-infrastructure like e.g. proxies to cache requests and use conditional get requests. Ajax request may be quite heavy-weight since every Ajax request contains HTTP headers and include cookies.
WebSockets is designed for low latency bi-directional communication. By design, WebSockets has very little overhead in each message. E.g. WebSockets messages doesn't have to include any HTTP Headers, and may in future be used for VoIP and streaming in both directions.
Another difference is that Ajax can be used with stateless servers. E.g. if you have your web load balanced with multiple servers, any server can handle an Ajax request, even after reboot (or upgrade). Websocket's are "connected" and use a stateful server, so it may be harder to use multiple servers with it.
There is also Server Sent Events, that are similar to WebSockets, in that the server can push data to the client (which can't be done with Ajax without hacks (e.g. comet)), and it can also handle automatic reconnections. But it's only for messages in one direction (server to client). See HTML5 Server-Side Event: EventSource vs. wrapped WebSocket.
Those are two completely different technologies and could be used together: with AJAX the request is initiated by the client, while with WebSockets the request is initiated by the server in order to push some data to the client.
Related
Is there any CDN provider able to offer some sort of WebSocket caching either via "Edge Workers" or other mechanism?
I would like that some WebSocket requests that we make to be able to serve them as close to the user as possible without us setting up our entire infrastructure in multiple datacenters.
No, there is no way to cache WebSocket messages - e.g. the protocol does not have any "addressable" resources as e.g. HTTP. HTTP has more built in design for caching in the protocol, e.g. GET requests are typically cacheable but not POST requests and you can add cache related headers to the requests, e.g. how long it can be cached and so on.
For this reason, I would recommend to use HTTP instead of WebSocket unless you have a use case where you really have to use WebSockets. With HTTP you have access to all CDN and proxy infrastructure that is available globally.
It is getting more and more common to use e.g. Server Sent Events, HTTP/2 streams or possibly GRPC for use cases where WebSockets was used before. The upcoming WebTransport protocol will probably be the replacement(?) - at least when most other traffic is HTTP/3.
Seconded, caching WebSocket messages is not possible/not recommended. I would encourage you to look into transforming your WebSocket messaging into a form of Edge Computing.
For instance:
Akamai offers EdgeWorkers.
CloudFlare offers Workers.
AWS offers Lambda.
This might offer you the ability to handle your workflow instead of relying on WebSockets.
/Mike (and yes, I work at Akamai)
I am working on a project which is basically a Customer Feedback Analysis Dashboard. There are few graphs on the dashboard and data for each graph is fetched from the server through API requests.
Right now the dashboard is updated every time the page is refreshed. I want it to be updated immediately when there is a new feedback in the system. I am confused, whether I use websockets to send data for each graph or just a flag and use that flag to fetch data through API requests.
Like, facebook/twitter does. They tell you about new posts/tweets and when you click that button your feed/wall gets updated.
If you want to "push" data from server to client and you want that data to show up in a timely fashion (e.g. within 10-20 seconds of when it was available on the server), then you will want to implement some sort of "push" solution where the server can efficiently push data to the client whenever there is new data to send.
There are several possible approaches:
webSockets
socket.io
Server-sent events
Mobile platform-specific push (Android and iOS)
For a general purpose solution that works within a browser, you will want to use one of the first three. socket.io is built on top of webSockets (it just adds more features) so architecturally, they are similar.
Server-sent events are fairly new (modern browsers only) and are only for one way communication (from server to client). webSockets can be used for communication either way.
I'd personally recommend socket.io because of the features it offers (such as automatic client reconnection) and a simplified messaging layer. You can see the feature difference between socket.io and webSockets here. With socket.io, the client makes a connection to the server when the web page is loaded and that connection is persistent. After the connection is established, then either client or server can send messages to the other at any time in a very efficient manner.
Other useful references:
Push notification | is websocket mandatory?
websocket vs rest API for real time data?
Why to use websocket and what is the advantage of using it?
What are the pitfalls of using Websockets in place of RESTful HTTP?
Ajax vs Socket.io
I'm extremely new to all of this, but from my understanding, websockets allow for a bidirectional transfer of information between browsers. Vert.x is a library that allows for asynchronous I/O. And sockJS is a JavaScript library that attempts to use websockets for communication, and provides fallback options otherwise.
But if I'm writing something in Java using vert.x, I don't quite understand how the pieces fit together. Does vert.x actually support websockets? Or do I need a combination of vert.x and sockJS to make that happen?
HTTP(s) is a stateless protocol, which means that once its job is done it will be idle till the next job is given.
So lets take an example of chat application, assume A is chatting with B using HTTP protocol. B has sent a message which is in server, now until A refreshes the browser, B's message will not appear. That's stateless behavior.
Coming to sockets, which is not stateless. Sockets use ws protocol which is always connected to the server. Taking the same example, now if B sends a message, A's socket will fetch and display to the browser, without the need to refresh. That's how sockets work.
To serve a webpage you need an http server. Similarly to use sockets, sockets server is needed. Which is provided by Vert.x. So Vert.x will start socket server, your browser will listen to that server using clientside sock.js file.
I built a realtime application that, thanks to Socket.IO, can serve a lot of different client types (C#, Java, Browser, ...)! I know that there are a lot of Socket.IO alternatives, but from my understanding, everything is more or less based on WebSockets. (I know that Socket.IO has fallbacks if WebSockets are not working, but that they are more less "inferior workarounds" so to speak...)
My question is: Is there any comparable real-time engine available that is NOT based on WebSockets, but can still serve all those different clients?
You don't say what your endpoints are. If one of the endpoints is a browser with purely the built-in capabilities of the browser and Javascript, then a webSocket is your only way to get a continuous connection from the browser to some other destination.
If a webSocket is not supported (in an older browser), then the other socket.io fallbacks (such as xhr-long-polling) are the next best alternatives. As the browser has limited communication capabilities, if you can't use a webSocket, then an ajax call is your only other generally supported option without requiring plug-ins on each browser (such as Flash or Java or something like that). socket.io already supports the next-best options that are available in a browser - you can't do better than that if you're talking about a standard browser with no custom plug-ins.
If your endpoints don't necessarily include a browser and you can use any language or library you want, then you can use plain TCP sockets and then use whatever protocol you want over a TCP socket.
The WebSocket protocol establishes a bidirectional communication channel between server and client; they kind of speak more naturally with each other. The server can just send something to the client and the other way around. In http it just goes in one direction, there's a request and a response and everything needs to be initiated with a request from the client.
From my experience, realtime webApps like a multiplayer game or a chat become easier to develop and it apparently creates less overhead than using http - but still you can do the same things more or less elegant with http as well (see e.g. long polling).
Look at gmail or other existing webApps, they all use http (so does Socket.io as a fallback) and it works quite well.
I have been programming in nodejs have looked at how to use both socket.io and ajax calls to the node server. Is socket.io designed to replace ajax? I am curious to know in which cases it is good to use socket.io and which ones ajax is nicer. Thanks for the input.
Well, one of the main thing web sockets (via socket.io) provides that ajax lacks is server push. So with ajax if you want to find out about new events on the server (a different user sent you a message, for example), you need to do server polling, meaning you send ajax requests in a relatively frequent periodic loop. Most of the time the server responds that there's nothing new, but occasionally when there is something new, the client can learn about it.
Web sockets allow the server to actively push notices to the client without polling. So if your application has any kind of information that needs to start on the server and just show up in the browser, web sockets are a better solution there.
Submitting data to the server in request/response model
ajax or web sockets essentially equivalent, traditional form POSTS also OK
Submitting events to the server in an event stream model
web sockets are best, can be emulated via ajax somewhat
Pushing events from server to browser
web sockets are best, can be emulated via ajax long polling, flash, etc (socket.io has several fallbacks it can try to use if real web sockets are not available).
older browsers, some mobile platforms
web socket support is not there, so ajax is your fallback