Just a hobbyist programmer with an eye on new technologies. Currently helping Quasar and NestJS Frameworks, because....well.....because they're awesome! :-)
If the user exists in the database, you should get error with default message "User doesn't exist".
Did you possibly mean to write the error as "User already exists"?
Also, I feel validation is very often based on business rules. And as such, it would be a lot of running to the programmer to ask him or her to update decorators. How would one take rules from a database (created by business) and use them dynamically within the code? I think that solution would be a whole lot smarter. The same goes for authorization rules, don't you think?
Did you possibly mean to write the error as "User already exists"?
No, it tests if user exists in database, if it doesn't validator should return error, that "user doesn't exist". It can be useful, when you check for example user id for crud operations, and don't want to run any logic, if input data isn't valid.
Also, I feel validation is very often based on business rules. And as such, it would be a lot of running to the programmer to ask him or her to update decorators. How would one take rules from a database (created by business) and use them dynamically within the code? I think that solution would be a whole lot smarter. The same goes for authorization rules, don't you think?
To be honest, I'm not the biggest fan of storing business logic in the database. There are several reasons for that. I have some experience with it, and it never ends well. Business logic stored outside code base is much harder to test, and it isn't possible to test it with unit-test (as unit tests should be database independent). For me business logic changes only when code is changed. This is why we write unit tests, right? They test business logic. If there is no business logic in our services (like simple CRUD operations), unit tests look like testing mocked data.
Ok, you can store some data in DB, like for example – a user role, and list of access routes. But the business logic is still in the code base. Roles, and theirs access routes, are only input data, for authorization rules.
Not sure if that what I'm saying is clear and makes sense :D
Just a hobbyist programmer with an eye on new technologies. Currently helping Quasar and NestJS Frameworks, because....well.....because they're awesome! :-)
Ok. Looked again at the code. My bad on the message. I was thinking in terms of creation of the user (and the user being unique), whereas the code is talking about the retrieval of the user. :) What I was thinking as a validation would be on a create or update DTO.
I see what you are saying with testing, however, that's also the point I'm trying to make to some degree I believe. Unit tests should test that the validation system works, but the conditions of the validation are meta to the "unit". The conditions are and must be variable as business changes all the time and thus, those rules themselve don't need testing. The system/ unit should take a set of rules and run validation on that set of rules. What's in the rules doesn't matter, the proper validation does.
The "testing" of the rules would lie solely with the business, since they are setting them. And because the rules are metadata to the system, it has to be purely manual on their part. Or, it could be within integration testing, but that would also be insanely complex, depending on the validations needed. :D
The goal I'm shooting for is to have a system of validation (and authorization) that is mainly independent of the programmer. It would be designed for a larger system with complex business operations. I've seen it done from a user's perspective. I'm just not quite sure how to make it happen with Nest. But, your article gave me more insight into the topic. Thanks!
It's interesting point of view Scott, but I'll stand by my opinion, that validation rules belong to the code base, not to the storage ;) Anyway, thanks for great comments, appriciate that! Have a nice weekend!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey. Nice article. Two things.
Did you possibly mean to write the error as "User already exists"?
Also, I feel validation is very often based on business rules. And as such, it would be a lot of running to the programmer to ask him or her to update decorators. How would one take rules from a database (created by business) and use them dynamically within the code? I think that solution would be a whole lot smarter. The same goes for authorization rules, don't you think?
Scott
Hi Scott, thank you for your comment!
No, it tests if user exists in database, if it doesn't validator should return error, that "user doesn't exist". It can be useful, when you check for example user id for crud operations, and don't want to run any logic, if input data isn't valid.
To be honest, I'm not the biggest fan of storing business logic in the database. There are several reasons for that. I have some experience with it, and it never ends well. Business logic stored outside code base is much harder to test, and it isn't possible to test it with unit-test (as unit tests should be database independent). For me business logic changes only when code is changed. This is why we write unit tests, right? They test business logic. If there is no business logic in our services (like simple CRUD operations), unit tests look like testing mocked data.
Ok, you can store some data in DB, like for example – a user role, and list of access routes. But the business logic is still in the code base. Roles, and theirs access routes, are only input data, for authorization rules.
Not sure if that what I'm saying is clear and makes sense :D
Regards
Ok. Looked again at the code. My bad on the message. I was thinking in terms of creation of the user (and the user being unique), whereas the code is talking about the retrieval of the user. :) What I was thinking as a validation would be on a create or update DTO.
I see what you are saying with testing, however, that's also the point I'm trying to make to some degree I believe. Unit tests should test that the validation system works, but the conditions of the validation are meta to the "unit". The conditions are and must be variable as business changes all the time and thus, those rules themselve don't need testing. The system/ unit should take a set of rules and run validation on that set of rules. What's in the rules doesn't matter, the proper validation does.
The "testing" of the rules would lie solely with the business, since they are setting them. And because the rules are metadata to the system, it has to be purely manual on their part. Or, it could be within integration testing, but that would also be insanely complex, depending on the validations needed. :D
The goal I'm shooting for is to have a system of validation (and authorization) that is mainly independent of the programmer. It would be designed for a larger system with complex business operations. I've seen it done from a user's perspective. I'm just not quite sure how to make it happen with Nest. But, your article gave me more insight into the topic. Thanks!
It's interesting point of view Scott, but I'll stand by my opinion, that validation rules belong to the code base, not to the storage ;) Anyway, thanks for great comments, appriciate that! Have a nice weekend!