1 person found this helpful
Web sockets are intended for persistent communication channels between the client and server as well as data exchange without polling. AJAX requests (XHR) only hold on to a connection for as long as the request lasts (although this is not strictly true -- browsers can hold connections open just in case an XHR is coming, but this is usually for a pretty short timeframe).
Both web sockets and AJAX are asynchronous, and this is by design. It's a good thing, too -- you don't want your entire app to freeze while waiting for data to come in. One benefit of web sockets which can make them a little faster is the fact that you don't have to reestablish the connection every time (which you do with AJAX). You're still going to be subject to network connectivity issues, bandwidth limitations, etc. with both. Also keep in mind that since a web socket maintains a persistent connection, you may run into server limitations as well, depending upon your configuration.
Web sockets are great for near real-time chat apps, or things like stock apps and the like. These apps have a constant stream of information being pushed by both the server and client, and here the benefits of a persistent connection without polling are really obvious. For simple CRUD-based apps, though, I'd seriously question the benefit of a web socket vs AJAX. The overhead of establishing a connection is generally on the order of ms, and the end-user isn't really going to notice this very much.
Some of the biggest contributors to how long a request will take are:
- Server capability to respond quickly (that is, if your server has to execute a 3s database query, the web socket and AJAX request are going to feel the same speed to the end-user.) If for some reason your server takes forever to set up a connection, you could argue that a persistent connection is faster, although I'd try to figure out first why it takes your server so long to set up a connection in the first place.
- Network connectivity and bandwidth limitations -- compression can help here if bandwidth is limited, and you should also have robust error handling so that requests can be retried if the network is fishy.
- Your app's ability to respond to and render the information quickly -- avoid long-running computations and such. A typical CRUD-based app shouldn't take very long at all to render information to the user, since the server's done most (if not all) of the work.
Now, as far as "delays" go, you can try to address them as follows:
- Don't wait for the data before presenting the UI. Then populate the UI when the data comes back. This lets your app respond quickly without the user feeling like their action hasn't been heard. You're still waiting for data, though.
- Anticipate the user's actions and prefetch the data. This is easier done in certain apps than others. But by anticipating the user's actions, you can fetch the data in advance and have it ready for presentation before the user actually asks for it. For example, let's say you have an app that displays a user's airline booking, but in a compact manner that needs to show other data on separate screens. Present an empty/"loading" UI first, request the basic data for the first screen, populate data when it arrives, then because the user might proceed to a related screen, start requesting the associated data just in case. Should the user navigate to one of the other attached screens, the data should hopefully already be present.
- Maintain a local data store that replicates data that is likely to be needed by the user. Much more advanced than solely anticipating the user's actions and only makes sense in certain applications (say a data entry app that can be offline for extended periods). This gets messy in a hurry, since sync also becomes an issue.
Now, all that said, it really depends upon what kind of app you're building. As such, it's hard to be any more specific. If you can share what your app is doing specifically, we might be able to give better advice.
This is absolutely everything I needed to know and more. We really don't need it. The app pulls data for display mainly in list views. We weren't sure if a persistent connection would make the response better but that's not the case. We didn't even consider the load of persistent connections on the server.
Thank you very much. I very impressed with the answer and much better educated for it.