“I previously wrote a paid column on the architecture of SaaS products for Xiaobaotong, but due to starting a business, I didn’t have time to continue improving it, so it was put on hold. Now I will share the content of the column on the public account, with an expected update once a month. If you find it useful, please help by clicking ‘Read’ and sharing it.”
Below is the main content.
01
—
Introduction
Most of our network requests are based on the HTTP protocol. The advantage of the HTTP protocol is that it connects on demand, meaning a connection is established to send a network request only when network data is needed, which saves resources. However, the drawbacks are also evident; due to the on-demand connection and issues with IP addresses, only the client (the front end) can actively initiate requests to the server (the back end) to achieve data interaction.
If real-time data interaction is required between the client and server (for example, online collaboration), HTTP requests cannot be used. In this case, a long connection must be established between the client and server, which keeps the data exchange channel open for both parties for an extended period. This method is usually implemented based on SOCKET. In this article, we will briefly introduce these two data interaction methods.
02
—
HTTP
HTTP is a short connection, meaning that after data transmission is completed, the connection is closed. This prevents data from being shared between two HTTP requests, which is referred to as a “stateless protocol.” For example, our account login is an HTTP request; after a successful login, if we do not handle it technically, when you request an HTTP data interface that requires login information, the back-end server will not have access to the current login information and will return a permission denied message.
To address this situation with HTTP, web browsers cache session information, which is automatically carried with each HTTP request. In the app, since there is no such mechanism as in browsers, technical measures are needed to cache session information on the app side, and this information must be included with each HTTP request. Therefore, when you hear the technical term “session expired,” it actually means that the user’s login session has expired and needs to be re-logged.
As we mentioned earlier, HTTP is a short connection, which implies a “use it and leave” approach, resulting in relatively lower pressure on the server and more resource efficiency. The server is like the front desk of a café, standing up to serve when customers arrive and sitting down to rest when there are none.
Of course, HTTP also has its drawbacks. Besides the inability to perform real-time data interaction, since HTTP is stateless, each request requires additional information, typically the HTTP request header, session information, etc. Therefore, in reality, this increases the amount of data transmitted over the network.
03
—
SOCKET
Most business systems are sufficient with HTTP, but some application scenarios require real-time data interaction. For example, I once developed a feature to monitor the real-time location of vehicles equipped with GPS devices. The positioning device periodically uploads its location to the server, and we need to display the latest vehicle location on the map in real-time. In this case, the server is responsible for sensing data updates, meaning the client does not know when the vehicle’s location will be updated. The handling methods are generally divided into two types:
1. Continue using HTTP requests, but the client periodically requests the latest vehicle location information from the server. This method is technically called “polling” or “pulling data,” meaning the client continuously asks the server for the latest data. Clearly, this method is less efficient; if the number of users is not large, it may not be a significant issue.2. Use SOCKET, where the server directly pushes data to the client when there is an update, allowing the client to display the latest data. This method is called “server push.”
To illustrate these two methods, consider our e-commerce product, which may experience stock shortages. Earlier designs required users to periodically open the app to check for restocks, which is the polling method. Now, many e-commerce products provide restock notifications, informing users via SMS or app push notifications once restocking is complete. For users, periodically opening the app is clearly labor-intensive, while restock notifications enhance user experience.
SOCKET, translated as a socket, also requires a connection to be established, and similarly, only the client can initiate it (the server does not know the client’s IP). However, once the connection is established, if one party does not actively disconnect, the connection remains open, effectively creating a data exchange pipeline between the server and client. This allows the client and server to transmit data to each other at any time, similar to instant messaging.
Another advantage of SOCKET is that the data format can be customized, eliminating the need to include fixed content like HTTP, which increases data transmission efficiency. In fact, to ensure more reliable data transmission, a custom data transmission protocol can be developed based on SOCKET, which can improve efficiency and ensure security. However, there are drawbacks; maintaining SOCKET connections on the server consumes certain resources, and if the number of connections is very high, powerful servers and bandwidth resources are required to support it. This is also why IM software has very high technical development requirements.
05
—
How to Choose
The specific choice of technology for data interaction is a matter for technical development, but what we want to discuss here is the selection of product design solutions. When designing products, we need to consider reducing the difficulty of technical development and the cost of subsequent operations.。
For example, when we create SaaS products, we often have export functions. For reports that take a long time to export, we typically use an asynchronous method (the user submits an export request, and the file can only be downloaded after the background export task is completed, allowing the user to do other things in the meantime). If the system directly pushes a notification to the user once the export is complete, the experience is naturally very good. I have encountered product managers who require such notifications to be displayed on the system’s web interface, which limits technical implementation options to either polling or a long connection solution like SOCKET.
In fact, our product design can achieve a good experience without adopting this solution. For instance, we can utilize WeChat template messages or DingTalk message notifications. In this way, once the export task is completed, the server finds the corresponding user and sends a reminder to WeChat or DingTalk. This implementation has a lower technical cost (SOCKET requires coordination between front and back ends, while this only requires the back end), and it consumes fewer server resources, meaning lower server costs.
In reality, unless the scenario requires very high real-time performance, it is generally not recommended to use SOCKET. Below are some scenarios in products where SOCKET may be useful:
- Online collaboration: simultaneous collaboration by multiple users, such as online documents;
- Real-time monitoring: for example, the vehicle location monitoring I mentioned, which is commonly used in freight, logistics, and ride-hailing scenarios;
- Instant messaging: lightweight instant messaging can be implemented using SOCKET, but for IM software with a large number of users, more professional solutions are typically used, and the protocol usually opts for UDP (SOCKET is based on TCP protocol).