DEV Community

Custom validation with database in NestJS

Krzysztof Szala on March 27, 2021

NestJS is an outstanding web framework which supports natively TypeScript out of the box. Its maintainers and community provides great and large do...

Read full post

Svarup Desai • Oct 7 '22

one thing that not mentioned is that, we have to add in app.module.ts

@Module({
  imports: ...,
  controllers: [AppController],
  providers: [
    AppService,
    ...,
    // Line below added
    UserExistsRule,
  ],
})
export class AppModule {}

Johnny Xaiyalath • May 13

Thank you all of you

Scott Molinari • Mar 28 '21

Hey. Nice article. Two things.

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?

Scott

Krzysztof Szala • Mar 28 '21 • Edited

Hi Scott, thank you for your comment!

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

Regards

Scott Molinari • Mar 30 '21 • Edited

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!

Krzysztof Szala • Apr 2 '21 • Edited

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!

Mattias Fjellvang • Jan 5 '22

This is a great article and just what I was looking for. However, is there a way to provide the container (using useContainer(app.select(AppModule), { fallbackOnErrors: true });) in the app.module.ts instead of in the main.ts file? Because I'd like this to be testable, and if I define it inside app.module.ts, my e2e tests would not function with my custom decorators.

davidN96 • Apr 25 '21

Hey! Great article! Could you share a link to repo with code from this article? I'm newbie in Nest, I have a problem with database dependency injection. I'll be very thankful

Krzysztof Szala • Apr 27 '21

Thank you. I'll try to upload some repos, when I find some time. What kind of problems do you have with database DI? Maybe I can help here. Regards.

davidN96 • Apr 27 '21

Hey! Thank you for your response! Well, I've found the problem. I've accidentally imported useContainer from typeorm instead of class-validator (VSC hints). Now everything works great. Thank you for a great article!