You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that this can be an improvement for the backend check since it is implemented frontend side and even if a guy doesn't respect this constraint the system is still able to optimise (in fact the system doesn't consider timeslots that doesn't respect the constraint)
In my opinion it is not easy implement this constraint backend side, it is expensive. In fact we have to check for each timeslot created the old timeslots in the database. we have also to consider the case where the user insert timeslots before the current date.
So I think that the best approach is writing all constraints on the frontend site and on the API documentation. In fact the user can perform this actions but the system doesn't consider them.
P.S. another constraint is that the user cannot update the timeslots after a meeting is planed
The text was updated successfully, but these errors were encountered:
I think that this can be an improvement for the backend check since it is implemented frontend side and even if a guy doesn't respect this constraint the system is still able to optimise (in fact the system doesn't consider timeslots that doesn't respect the constraint)
In my opinion it is not easy implement this constraint backend side, it is expensive. In fact we have to check for each timeslot created the old timeslots in the database. we have also to consider the case where the user insert timeslots before the current date.
So I think that the best approach is writing all constraints on the frontend site and on the API documentation. In fact the user can perform this actions but the system doesn't consider them.
P.S. another constraint is that the user cannot update the timeslots after a meeting is planed
The text was updated successfully, but these errors were encountered: