Push? Pull? Websockets?
Published on 2016-07-20
Communicating with a backend - the communication between a server and a client - needs to be optimized to meet the users expectations of the application. This might seem rather vague but any application is met with a set of expectations specific to its user base and circumstances surrounding the typical use.
I'll go over some possible solutions here.
For the sake of the argument let's assume that the application in question has a client-server-based architecture and that the following contraints are true:
- The server holds the data
- There is more data than the client can store
- Only the server knows which data is correct (for a given client)
- The client is always interrested in the newest data
With these assumptions in play let's dig in to the problem. First of all the client will connect to the server which leaves two options: The client can make a request for the data or the server can hand over the data to the client. We'll refer to these as pull and push- both of these scenarios have some pros and cons.
Pulling data from the server
In scenarios where the client keeps a track of which data it needs it can ask the server to provide it. Imagine a messaging system where the client connects to the server and asks if there any new messages that has arrived since a given point in time - or even messages from a specific sender - this would require the client to keep a record of these time points and senders to be able to ask the right question.
Pulling data from the server is the most common way of transfering data between the client and the server - one advantage is that the server is known, it is static and everyone knows how to get in touch with it. The client(s) on the other hand is not nescecarily that well defined. There might be many more and they might behave in a way that makes it impossible to determine if they exist or even where they are let alone contact them directly. In network applications the clients network/location can change throughout the communication (devices connected though cellular networks, like mobile computers and/or smartphones) and it might not even be possible for the server to connect directly to the client due to routing and/or NAT.
Pushing data to the client
Push doesn't exist - well... That is a bold statement - but consider the facts mentioned above: The server can rarely even contact the client(s).
Push is the idea that the server can just hand out (push) some data to the client(s) and expect them to know what it means and what to do. There a some implemetations of this - for example both Apple and Google has push notifications enabled on their mobile operating systems.
Both these implementations allow the developers to have servers that send a (push) message to the app on the device. The app needs to have proper actions implemented to handle the message(s) it might receive. These setups hide a very important fact to the developers and/or users: It is not push. The operating system is constantly polling the servers of Apple/Google to pull any messages to the device - we might call this method virtual push - as far as the developer is involved it is push and that might be all that matters.
In order to have real push - or bi-directional data transfer in a traditional multi-client client-server setup a constant connection between the server and the client needs to be in place (for mobile devices this is not realistic due to power usage contraints eg. - which might've led to the birth of virtual push).
Using a websocket lets the client and server have a constant connection that the client can use to pull data (upon user navigation etc.) and the server can use to push data (when changes occur, messages arrive etc. - maybe from other clients connected).
If your web applications needs both push and pull and you're working with a modern browser as your target platform I strongly encourage you to check out some examples of websockets and their use.
Please be aware that websockets do require an open active connection for every client currently connected to the server. This will put extra stress on the server and might also be more difficult to debug and troubleshoot.