1. Background
On the eve of the Spring Festival in 2020, the project team planned a WeChat applet. The project is a red envelope lottery draw. Users complete the tasks in the mini program to get the number of lottery draws, then choose the red envelopes of their favorite styles for the lottery, and then award prizes based on the lottery situation. The project itself does not have too complicated functions, but because the project team has not been engaged in the development of small programs before, the development of the project has experienced twists and turns due to changes in requirements caused by policies. Fortunately, the project was finally completed and delivered, and many of them were encountered The problem is summarized here.
2. Function points
The figure roughly lists the main function points included in the project, and the related logic between the function points
The main process is: After the user enters the WeChat applet, obtain the prize data on the configuration page, follow the official account to obtain the number of draws, and go to the draw interface to perform the draw
3. Technical Points
3.1 Configure prizes
Core requirement: Provide a configuration page for configuring prizes and corresponding data
This functional module uses basic data to add, delete, modify, and check, and the more complicated is the design of the data structure.
The overall data is divided into three layers:
- Prize pool: collect all prize data
- Topic: It has independent attributes and collects all the red envelope data under the topic
- Red envelope: has independent attributes and stores all available links of the red envelope
Due to the limitations of the database and development time, functions such as relational tables or designing mutexes cannot be used. In order to minimize data anomalies caused by concurrency, the overall data is split into tables for storage in the data design phase.
// 奖池
"Prize-Pool": {
{
// 专题列表
"themeList": [
"b29369b5-e475-4bc3-9ce1-ddfd93486301"，
"b29369b5-e475-4bc3-9ce1-ddfd93486302"
],
"otherData": {
"xxx": "xxx"
}
}
}
// 专题（Theme + 专题key）
"Theme-b29369b5-e475-4bc3-9ce1-ddfd93486301": {
// 红包列表
"packetList": [
"1611578407299",
"1611578397794"
],
"key": "b29369b5-e475-4bc3-9ce1-ddfd93486301",
"background": "xxx",
"iconUrl": "xxx",
...
}
// 红包（Packet + 红包key）
"Packet-1611578407299": {
"linkList": [
"link1",
"link2"
],
"key": 1611578407299,
"title": "212121",
"imgUrl": "xxx",
...
}
After the lottery draws, you can 专题key + 红包keylocate specific red envelopes and linkListread and write a single red envelope to reduce the impact of concurrency.
3.2 Follow plus times
Core requirement: Determine whether the current user has followed a certain official account, and increase the number of draws based on the status
The judgment process is more complicated and there are many limitations
Restriction 1: Confirm user identity
Applets and micro-channel micro-channel public number, each corresponding to each user openId, openIdit can uniquely identify the user's identity in the current platform, but applets openIdand public numbers openIdare not the same.
When the Mini Program and the official account are bound to the same public platform, the public platform will generate one unionId, and the unionIduser's identity can be uniquely confirmed under the public platform.
Due to the difference between WeChat Mini Programs and Official Accounts, the corresponding Mini Program users openIdcannot be found through the Official Account when following the Official Account openId. Therefore, it is necessary to pass the unique unionIduser information associated with the Mini Program and the Official Account.
Limitation 2: Get UnionId
Applet by wx.getUserInfoobtaining the user unionIdthrough the public number access_tokenacquisition, access_tokentwo hours every failure, need to regularly refresh.
In batch acquisition unionId, some requests cannot get the returned data due to network factors, and it is necessary to repeatedly request to obtain the complete data.
Limitation 3: Dealing with environmental networks
WeChat only allows servers added ipto the official ipaccount whitelist to obtain user information. The whitelist server must be fixed . After the project is deployed, it will be deployed on multiple servers, and the external network corresponding to the server ipis not fixed, so you cannot fill in the whitelist. In the list.
Using the proxy method, the request is sent to a proxy server, and the proxy server is responsible for forwarding the request and exposing a fixed external network ipfor configuration on the WeChat official account .
In order to achieve the core requirements of this functional module, it can be completed through the following process:
- Get the list of users on the official account interface, and get the
openIdlist of users that have been followed - The official account interface is obtained in
openIdbatchesunionIdand stored in the database - If the applet
wx.getUserInfoobtains the user , it will be searchedunionIdin the database. If it isunionIdfound, it means it has been followed, otherwise it has not been followed. - Receive event notification after paying attention and
unionIdwrite to the database
3.3 Lottery
Core requirements: record the number of draws, carry out the logic of draws, and complete the distribution of prizes
The function is relatively simple:
- Record the completion of the one-time tasks and the completion of the daily tasks in the activity separately, the number of times will be increased, and the number will be reduced after the lottery.
- Configure the probability of winning, generate a random number to determine the size
- Record the winning result and return to the prize link
3.4 Others-Automatic reply to official account
Core requirement: WeChat public account automatic reply
The official account has its own automatic reply function, but the automatic reply will be invalid after binding the push server. The server needs to judge the user's behavior and reply based on the information pushed by WeChat
// 微信推送的是xml数据，需要进行解析
const {
ToUserName, // 开发者的openId
FromUserName, // 用户的openId
Event,
CreateTime,
MsgType } = await new Promise((resolve, reject) => {
Parser.parseString(this.req.body, (err, result) => {
if (err) reject(err)
resolve(result.xml)
})
})
// 回复，以简单的文字回复为例
xml = `
<xml>
<ToUserName><![CDATA[${
FromUserName}]]></ToUserName>
<FromUserName><![CDATA[${
ToUserName}]]></FromUserName>
<CreateTime>${
new Date().getTime()}</CreateTime>
<MsgType><![CDATA[text]]></MsgType>
<Content><![CDATA[${
content}]]></Content>
</xml>
`
return this.res.send(xml)
4. Review
4.1 Changes in prize requirements
The first major change: The prize pool prizes are stored in separate tables.
The previous demand for prizes is: data only needs to be configured and displayed, and each red envelope has a designated link, and the prize can be issued by returning to this link.
Since there is no data writing in this requirement, concurrency will not affect the data, so in order to speed up the progress, a simple design is adopted to store all data in one object.
Due to changes in requirements, data needs to be read and written concurrently, resulting in a redesign of the overall data structure, overturning most of the previous logic, 配置奖品and major changes to the module.
4.2 Attract attention
The second major change: Modify the overall requirements of the lottery.
The previous requirement for lottery draws was: you must pay attention to the official account to draw the lottery.
After the completion of the project development, during the small program release stage, the review failed and was rejected due to the induction of attention. The modification requirement is that a free lottery can be held. This version was approved at the initial review, and was subsequently rejected due to the existence of induced attention. The main logic was modified many times due to concerns about the official account, and finally it was changed to display the exchange group and completely abandoned the following logic.
4.3 Lottery system
The third major change: abandon the lottery and change to a gift.
The previous demand for the event was that prizes must be drawn only after being drawn.
After the project went online for a period of time, the mini program was officially blocked by WeChat due to a lottery-like behavior, and then changed to a daily limited gift, giving up the lottery logic.
4.4 User system
The fourth major change: Abandon user data.
The initial requirement for data is to record the data, and calculate the conversion rate of prizes and user attention after the event.
After the project was modified to the end, the attention to the system and the lottery system was abandoned, and the previous data is no longer meaningful. More deadly it is: due to a previous demand logic, causing the user data is unionIdstored as the only confirmed value, without public attention to user number does not exist unioinId, and finally forced to use openIdto uniquely identify and data migration.
4.5 Other
-
Login state migration
Since the backend has a login state, users who are not logged in cannot access the backend. In the early stage of the project design, the user first obtains the login status and then enters the mini program.
After a series of changes, the login status acquisition process becomes the first to enter the mini program and then to obtain the login status. This change did not align with all developers, and the default login state was used in the front-end development stage for convenience, so that the problem was not exposed in the testing stage.
After the project went online, the default login status expired and invalidated, resulting in abnormal user access.
-
The code is not rigorous
In the development process, there is a problem with fewer letters leading to an error, and the problem should be detected in the test link. However, due to the default login state, the problem was not exposed during the test, which eventually caused an online bug.
5. Summary
Unfixed demand
Problem: Due to the policy, the requirements have changed several times, resulting in confusion and inefficiency in the overall process.
Improvement: Perform detailed project evaluation before development to avoid frequent changes to the main requirement logic after development starts
Communication is not timely
Problem: When the content of a dependent module is changed, the change information is not synchronized.
Improvement: Determine the interaction process before development, and notify all relevant personnel when the process changes
Incomplete testing
Problem: There is no test function and personnel, and it is impossible to conduct a comprehensive test.
Improvement: Build a test system for unit testing, and perform more tests after the function is completed.