Let's talk about APP push and analyze how each end collaborates to complete the push task

[51CTO.com original article] Push function has become a must-have function in APP. With push, we can not only push popular information to users, but also push some information related to the user to users. So what are the two types of push? How should we implement the two types of push?

Does the picture above look familiar to you? When we open many apps, we will find such an interesting thing, that is, these apps will push various information to us, such as a certain news hotspot, a user's comment, collection and sharing of my article, and even some shopping mall apps will push delivery, return, discount notifications, etc. Let's talk about the relevant knowledge about push.

A simple light architecture for human message push

The above figure is a push lightweight architecture diagram for production environment. From the figure, we can see that first, our content editors select news, videos and other content to be pushed from the management background, and then the backend program passes these pushed content to the push server through SDK or HTTP API. After the push server receives these messages to be pushed, it goes through a series of processing and then sends them to the clients in the APP in turn. After the client in the APP receives the push message, it displays the push message in the status bar of our mobile phone, so that we get the push we see at the end.

Although the push program is a C/S program, most individuals or companies will not develop push programs by themselves, but instead use the existing push frameworks available on the market to implement the push function. Currently, the main push frameworks on the market are: Xiaomi Push, Baidu Push, Umeng Push, etc.

Message Producer & Message Consumer

We talked about a kind of push based on human intervention above. All messages to be pushed are selected by us manually, and are generally pushed to all APP users. However, for some special pushes, they can only be pushed to a certain user, such as shipping notifications, VIP expiration notifications, membership renewal notifications, etc. Because they are only for a certain user, at this time we can only use programs to replace humans to complete the push, but the implementation is the same, except that the content to be pushed is generated by the program. So how can we push it to a certain user?

In fact, in our push framework, each APP has a unique push identifier. For example, Xiaomi push is represented by regid. With this unique identifier, we can bind this unique identifier to our user UID when the user logs in to the APP, so that we can push various messages generated by the UID to him.

A lightweight and compact automatic message push architecture

We briefly discussed above how to associate users with push identifiers. Now let’s talk about how to implement a non-human message push architecture to push information related to the user.

In the above figure, we use redis subscription and publishing to realize the production and consumption of messages. The so-called redis subscription is to subscribe to the messages of a certain channel, and then when there is a message in this channel, the Redis server will send it over. The so-called redis publish message is to save various messages generated by the application to a channel on the Redis server. Here we just choose a slightly simpler implementation method. Of course, you can also use the MQ introduced earlier to implement it.

Disadvantages of push notifications

Since many apps now have push functions, our phones receive a lot of push notifications every day, so many users choose to turn off the push permissions of some unimportant apps. In this way, our push notifications cannot reach the user's app, and the meaning of push notifications no longer exists.

[51CTO original article, please indicate the original author and source as 51CTO.com when reprinting on partner sites]