There is such a scenario where user-submitted data needs to be processed under the '/blog' route
Suppose you want to store three pieces of data into three keys and then write the code and it will look like this
function handlePostBlog(req, res){
resid_client.set( key1, data1, function(err, response){
resid_client.set(key2, data2, function(err,response){
resid_client.set(key3, data3, function(err, response){
if(response === 'ok'){
res.writeHead(200, ...)
res.end()
}
})
})
})
}I don’t care whether it looks good or not. . Although it looks better wrapped with promise, is there a problem with res.end() in the last callback to close the connection? Will this request be pending for a long time? How should we deal with this kind of place? Because you only need to set and do not need to return the result to the user, can you just close the connection directly with res.end() after receiving the request?
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
It depends on whether you want the return results of this HTTP request to be correlated with the results of the database operation, and whether the user interaction design tolerates the time spent on this operation.
When you design this '/blog' interface, you need to clearly indicate what it means when HTTP returns 200. If your business scenario only cares about data delivery to the backend and does not care about whether the backend is correctly stored in the database, then you can definitely end the HTTP request directly. If you want end users to get this exact submission result, you need to consider the interaction level. Design a good interaction effect, wait for 2-6 seconds, and the user experience will not be bad (referring to the AJAX request scenario, opening a new page scenario Still be cautious). Writing to redis three times takes almost no time, and is nothing compared to the link delay of the HTTP request itself.
Specific business scenarios need to be analyzed in detail. When encountering particularly time-consuming operations, it is also a solution to rotate the results after submitting the operation request at the front end.
See if there is any correlation between the page display and the database operation results. If there is a correlation, you can wait until the database operation is completed and return. It can also be returned directly in an asynchronous queue, and the result will be pushed after success. In the end, it all depends on your needs.