-2

Apologies for the title, perhaps someone can suggest a better way to summarize my question.

Let's say I have a task/checklist application. On the front-end, I create a task. The eventual result is that the task exists in both the front-end and the database. I have these 2 approaches:

  1. I create a task in the front end by first sending a request to the backend, then awaiting for the request result. If the result is 200, then I go ahead and create the task in the front end. Now I have both the task in the front end (displayed to the user) and in the backend (saved).
  2. I create a task in the front end by first sending a request to the backed, then awaiting for the request result. The request then send back not only the status code, but the entire task object itself to the front end. I take the task object (deserialized) and display it to the user.

The considerations between the 2 are:

  1. With 2 I don't need to update the logic of creating the task in 2 locations (in the front-end to create and display and in the back-end to create and store) and there could be inconsistencies between what the user sees and what is stored if incorrectly created/updated.
  2. With 1 I have less network traffic. All the request needs to respond with is 200 and not the entire task object.
Improve this question

1 Answer 1

Reset to default
0

If just getting success status code is enough for you, it is OK. Use it and keep it simple. But in real world, all your method can not work like that.

Assume that you create a new item. After create this item, you need to go further(maybe redirecting another page) with this item Id. How can you handle this Id? In this case, just 200 status code is not enough for you. If you need any information like Id, then you can read data and turn it back as response. It can be entire data or part of them.

Considering Network Traffic and another resources is good. Try not to turn back unused data. If you need to read huge data, then parse it properly and send more than one request to the server. You just need to balance User Waiting Response Time and Network Traffic in this case.

Improve this answer
7
  • Thank you for the insight! One clarification: if I don't need to "go further" is it still valuable to send back the entire object as the response? Otherwise, I would need to maintain 2 locations where I create the object; backend and frontend. Commented Mar 9, 2019 at 0:22
  • I don't think so or I can't imagine your case. Assume that you create a thing and you don't need to go further. So, you can turn your things list page and let user do what he/she wants. If he/she want to see object details, then you can request to the server to get object details. Why are you storing object on front-end if you don't need to use it(no need to going further) Commented Mar 9, 2019 at 0:32
  • Ah! "don't need to go further" as in I don't necessarily need the information from the response. This may be bad practice on my part, but I'm generating Id on the front end, and sending that to the backend, so I wouldn't need that info from the response. The thing is then shown to the user, so I would need to store it on the front-end as well. Essentially, this case I would need to create the thing in 2 places if I don't get the thing from the response! Commented Mar 9, 2019 at 0:55
  • I'm generating Id on the front end is not bad practice. It is dangerous. How do you manage each object has different Id? Commented Mar 9, 2019 at 9:32
  • My _id_s are UUIDs randomly generated and are thus highly probable to be unique. They are sent to the backend. Sure someone could make a non-client API call with a conflicting UUID, but the backend will return a non-200 status code. I could definitely be naive, but thoughts on why that could be dangerous? Commented Mar 9, 2019 at 9:54

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.