Skip to main content
Software Engineering

Return to Question

Bumped by Community user
Bumped by Community user
deleted 14 characters in body
Source Link
Alvin
Alvin
  • 19
  • 3

I am designing a timesheet app for logging user tasks using React for frontend and Django REST Framework for backend. The database is PostgreSQL and I have a table for recording the tasks with 4 columns: date, start_time, duration, description.

I need a way to support the updating of a task after the user had created several. The problem is that each task is dependent on all the previous tasks, since its start_time will change if the duration of a task before it changes. So for example, suppose that task 1 has a start_time of 13:00 and a duration of 1 hour, task 2 has a start_time of 14:00 and a duration of 1 hour, and so on. If the user decided to update the duration of task 1 from 1 hour to 2 hours, that means the start_time of task 2 and all subsequent tasks must be increased by 1 hour.

I'm wondering what is the best way to implement such cascading updates in a REST API. First option is to make the API backend responsible for it, so whenever the React frontend sends out a PUT request for a task, the DRF backend will not only update that task but also all subsequent tasks as well. Second option is to offload everything to the React frontend, making it responsible for sending out multiple PUT requests, for the updated task as well as all subsequent tasks.

I would think the first option of letting the backend handles everything is a better design, since this problem is technically a form of database constraint. But not too sure if it is appropriate for a REST API to handle. What would be the best practice in this case?

I am designing a timesheet app for logging user tasks using React for frontend and Django REST Framework for backend. The database is PostgreSQL and I have a table for recording the tasks with 4 columns: date, start_time, duration, description.

I need a way to support the updating of a task after the user had created several. The problem is that each task is dependent on all the previous tasks, since its start_time will change if the duration of a task before it changes. So for example, suppose that task 1 has a start_time of 13:00 and a duration of 1 hour, task 2 has a start_time of 14:00 and a duration of 1 hour, and so on. If the user decided to update the duration of task 1 from 1 hour to 2 hours, that means the start_time of task 2 and all subsequent tasks must be increased by 1 hour.

I'm wondering what is the best way to implement such cascading updates in a REST API. First option is to make the API backend responsible for it, so whenever the React frontend sends out a PUT request for a task, the DRF backend will not only update that task but also all subsequent tasks as well. Second option is to offload everything to the React frontend, making it responsible for sending out multiple PUT requests, for the updated task as well as all subsequent tasks.

I would think the first option of letting the backend handles everything is a better design, since this problem is technically a form of database constraint. But not too sure if it is appropriate for a REST API to handle. What would be the best practice in this case?

I am designing a timesheet app for logging user tasks using React for frontend and Django REST Framework for backend. The database is PostgreSQL and I have a table for recording the tasks with 4 columns: date, start_time, duration, description.

I need a way to support the updating of a task after the user had created several. The problem is that each task is dependent on all the previous tasks, since its start_time will change if the duration of a task before it changes. So for example, suppose that task 1 has a start_time of 13:00 and a duration of 1 hour, task 2 has a start_time of 14:00 and a duration of 1 hour, and so on. If the user decided to update the duration of task 1 from 1 hour to 2 hours, that means the start_time of task 2 and all subsequent tasks must be increased by 1 hour.

I'm wondering what is the best way to implement such cascading updates. First option is to make the API backend responsible for it, so whenever the React frontend sends out a PUT request for a task, the DRF backend will not only update that task but also all subsequent tasks as well. Second option is to offload everything to the React frontend, making it responsible for sending out multiple PUT requests, for the updated task as well as all subsequent tasks.

I would think the first option of letting the backend handles everything is a better design, since this problem is technically a form of database constraint. But not too sure if it is appropriate for a REST API to handle. What would be the best practice in this case?

Source Link
Alvin
Alvin
  • 19
  • 3

Best Practice: Should cascading updates be handled by the frontend or the REST API?

I am designing a timesheet app for logging user tasks using React for frontend and Django REST Framework for backend. The database is PostgreSQL and I have a table for recording the tasks with 4 columns: date, start_time, duration, description.

I need a way to support the updating of a task after the user had created several. The problem is that each task is dependent on all the previous tasks, since its start_time will change if the duration of a task before it changes. So for example, suppose that task 1 has a start_time of 13:00 and a duration of 1 hour, task 2 has a start_time of 14:00 and a duration of 1 hour, and so on. If the user decided to update the duration of task 1 from 1 hour to 2 hours, that means the start_time of task 2 and all subsequent tasks must be increased by 1 hour.

I'm wondering what is the best way to implement such cascading updates in a REST API. First option is to make the API backend responsible for it, so whenever the React frontend sends out a PUT request for a task, the DRF backend will not only update that task but also all subsequent tasks as well. Second option is to offload everything to the React frontend, making it responsible for sending out multiple PUT requests, for the updated task as well as all subsequent tasks.

I would think the first option of letting the backend handles everything is a better design, since this problem is technically a form of database constraint. But not too sure if it is appropriate for a REST API to handle. What would be the best practice in this case?