The front end brother writes the back end for the first time, collapse!

Let’s take a look at the back-end code written by my brother for the first time. What do you think?

Hello everyone, I am fishskin, today share my brother’s first time to write back-end code embarrassing incident, I hope you take warning.

Since we have committed iniquity

My elder brother small abba, at present big one, self-taught programming has a period of time, before the main front end to learn is given priority to, relatively good start.

But for some reason, he’s been talking about writing back-end code.

I say: your front end just learn not how long, urgent what?

Little Abba said: No one knows the front end better than me!

Good boy, I didn’t expect to see you in a few days, this guy is so proud now! It had to take his spirit down a notch and show him the horrors of the back end.

So I said: ok, I happen to be developing a new function [delete messages] recently, the function is very simple, allows users to delete their own already read messages. I’ll give you two weeks to practice and get familiar with the project

To my surprise, little Abba said, two weeks? Look down upon who, such a small function, I give you 3 days to fix!

I big surprise: now young people are so strong yao? Ok, I’ll wait for you!

Unexpectedly, less than 3 days, the small aba really submitted the code, let us take a look at his implementation ideas and code.

Implementation approach

Functional implementation includes the front end and the back end of two parts, think about it separately.

The front end

To realize the function of deleting user read messages, the front-end work is relatively simple, add a delete button, and add a click event to the button, click to call the back-end message delete interface.

Front-end code written by Little Abba:

<! -- Pseudocode -->
<button onClick={doDelete (message)}>delete</button>
<script>
  // Delete the message
  function doDelete(msg) {
    // The message ID exists and is read
    if(msg.id && msg.isRead) {
      // Call the back-end interfaceservice.deleteMsgById(msg.id); }}</script>
Copy the code

Looks like no problem, write also quite neat, code standard praise!

Let’s see what happens on the back end.

The back-end

What the back end needs to do is to accept the request sent from the front end, operate the database, delete the message with the specified ID in the database, and then return whether the deletion is successful to the front end.

Many programming languages can be used to write backends, such as Java, Go, etc. But since little Abba is the first time to do the back end, I feel bad for him, so let it use NodeJS (JavaScript syntax) to write.

Take a look at the back-end code written by Abba Junior:

// Delete the message interface
// @params msgId message ID
function deleteMsgById(msgId) {
  // Call the database delete function to get the result
  const res = db.deleteById(msgId);
  return res;
}
Copy the code

There are only a few lines of code, simple and clear, so it is no wonder that it took abba three days to write it.

I don’t know what you think of this code, like their first time to write code?

Think about it, is there anything wrong with the code he wrote?

To analyze problems

In fact, small abba this code problem is very big! Once online, the consequences are unimaginable!

There were three main problems, and I called little Abba over to give him a plate according to the seriousness of the problem from big to small.

1. No verification is performed

I said to abba: Take a closer look at your code. Is it missing validation logic?

Am I not in the front end to determine whether the message ID exists and whether the message has been read?

Me: What if instead of clicking the delete button in the browser, the user directly requests the interface and passes the message ID?

Little Abba was lost in thought.

This is a common mistake made by those writing the background for the first time, especially when both the front and back end are written by one person, thinking that it is enough to determine whether the parameters are legal in the front end. However, malicious users don’t care. They can send requests to your backend directly from outside the browser using various tools, passing random message ids, or even traversing all possible ids. If the backend does not do verification, once online, normal user messages may be deleted! The absolute highest level of accident!

Little Abba: I didn’t think it was so serious, so I made up the verification of the message status in the background, it seems not too good, right? After all, the user can pass any request parameter.

Me: Very clever, indeed, so we also need to make up the verification of the current logged-in user.

The complete code looks something like this:

// Delete the message interface
// @params msgId message ID
function deleteMsgById(msgId) {
  // Verify the validity of the parameter
  if(! mgsId) {return false;
  }
  // Check the latest message status from the database
  const msg = db.getMsgById(msgId);
  // Get current user information from session or middleware
  const user = getCurrentUser();
  // The message is unread or not for the user
  if(! msg.isRead || ! user || msg.userId ! == user.id) {return false;
  }
  // Call the database delete function to get the result
  return db.deleteById(msgId);
}
Copy the code

Little Abba: I remember, the back-end interface is the core of the business, must strengthen the verification!

Me: Good, let’s look at some other questions.

2. Hard to remove

Me: In your code, you call the delete function directly to delete the data, do you know what the problem is?

Little Abba: What’s the problem?

Me: Directly deleting data will lead to a lack of clues when the administrator needs to troubleshoot problems. For example, if a user sends a violation message and deletes the message after a period of time, the administrator can no longer find out his violation record.

Little Abba: That’s true. What about it? This data can’t be deleted?

Me: Soft delete is generally adopted, adding an extra field to the data table to indicate the deletion status, such as isDelete, where 0 indicates that the data table is not deleted, and 1 indicates that the data table is deleted. In normal cases, only the data whose isDelete = 0 is displayed to users. When deleting the data, change the value of the field from 0 to 1.

So the last part of the above code can be modified slightly:

// Delete the original code
db.deleteById(msgId)
// New code, soft delete (update)
db.updateById(msgId, {isDelete: 1})
Copy the code

So the back-end code is basically complete.

Of course, not all data tables need to be soft dropped, depending on the business scenario.

3. No false contact protection

Finally, there is a small problem in product experience. It is suggested that when users click delete, a pop-up box for second confirmation will be displayed. Otherwise, users will feel angry if they accidentally click the wrong button and try to find the message but can’t find it.

The more you do front-end development, the more you pay attention to these little details, and improving the user experience is very important!

---

Little Abba: Got it, got it! I love it 555.

I: have no matter, this is very normal, know a mistake can change, still good a bar.

Do many of you who are reading this article make these mistakes? Please develop good programming habits, check your code more!

By the way, when I heard that a “like” is more impressive!