#logic of authorization

9 messages · Page 1 of 1 (latest)

cobalt garnet
#

hi, the the logic im handling inside the if, should be handled there in the controller, service or in a guard? thank you

logicnesrt.png
gritty prismBOT
#

:warning: Please do not screenshot code as it causes a number of issues:

  • Ease of assistance: if someone wants to copy your code and correct it, they cannot. Making it easy for people to help you is in your best interests.
  • Editorializing: it's common to try to make images small, which means you're likely to crop out code relevant to your issue
  • Accessibility: wide images can be hard to read on mobile devices, and are impossible for screen readers.
  • Legibility: you cannot read screenshots of code directly, instead you have to open them in an enlarged context.
  • Bandwidth usage/clutter: some of our members use metered connections, and it is wasteful for them to download images of a text.

For a small amount of code, please use a code-block.

edgy hatch
#

If it can be extracted into something reusable then a guard might be good, but your example looks like a fairly straightforward and one off task so probably not worth putting into a guard.

Where to put it is a style choice. I personally like to keep it so my controllers only focus on http related stuff (things to do with the body, params, req.user roles, etc) and the service is the place where things like database checks/updates or business logic things happen. So if it were me I'd move that try catch block into the service and just have the controller call that with the relevant arguments.

jolly crow
# cobalt garnet hi, the the logic im handling inside the if, should be handled there in the cont...

first of all i like to point 2 things
one is what scott mentioned, screenshots of code are horrible
two

@Delete(`delete/:${appointmentIdParam}`)
``` this this is the most cursed thing i have ever seen in a controller dear lord ![DISGUSTANG](https://cdn.discordapp.com/emojis/581531485937467404.webp?size=128 "DISGUSTANG") 

now to your actual question
i would put this in a guard since any request with invalid url params should be stopped before they are even started
preventing is better then having to fix the damage
#

suggest to do this instead

@Delete('delete/:id')
async DeleteApointment(@Param('id', ParseIntPipe) id: number) {
// ...
}
cobalt garnet
cobalt garnet
jolly crow
cobalt garnet